Thank for fixing this !
Both patches are reviewed-by: vljn at ovi.com
- Mail original -
> De : Tom Stellard
> À : llvm-comm...@cs.uiuc.edu
> Cc : mesa-dev@lists.freedesktop.org; Tom Stellard
> Envoyé le : Mercredi 15 mai 2013 1h03
> Objet : [Mesa-dev] [PATCH 2/2] R600: Fix encoding fo
From: Tom Stellard
The SROA and function inliner passes are espically important, because
they optimize away unsupported features: functions and indirect
private memory access.
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
src/gallium/drivers/radeon/radeon_llvm_util.c | 16 ++
From: Tom Stellard
The SROA and function inliner passes are espically important, because
they optimize away unsupported features: functions and indirect
private memory access.
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
src/gallium/drivers/radeon/radeon_llvm_util.c | 16 ++
From: Tom Stellard
https://bugs.freedesktop.org/show_bug.cgi?id=64193
https://bugs.freedesktop.org/show_bug.cgi?id=64257
https://bugs.freedesktop.org/show_bug.cgi?id=64320
NOTE: This is a candidate for the 3.3 branch.
---
lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp | 7 +++
test/Cod
From: Tom Stellard
---
Patches 1 and 2 are separate, so that patch number 2 can be applied cleanly
to the 3.3 branch.
lib/Target/R600/MCTargetDesc/AMDGPUMCTargetDesc.cpp | 2 +-
lib/Target/R600/MCTargetDesc/AMDGPUMCTargetDesc.h | 3 ++-
lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp |
On Wed, May 15, 2013 at 2:03 AM, Marek Olšák wrote:
> Some Gallium drivers were crashing, because the array was not large enough.
>
> NOTE: This is a candidate for the stable branches.
> ---
> src/mesa/main/bufferobj.c | 10 ++
> src/mesa/main/config.h |
From: Tom Stellard
---
src/gallium/state_trackers/clover/api/context.cpp | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/context.cpp
b/src/gallium/state_trackers/clover/api/context.cpp
index 3717441..e0fed31 100644
--- a/sr
Eric Anholt writes:
> We keep having to pass the attachments around with our gl_renderbuffers
> because that's the only way to find what the gl_renderbuffer actually
> refers to. This is a step toward removing that (though drivers still need
> the Zoffset as well).
Note that I think state_track
Looks good to me. Thanks for the quick turnaround.
Jose
- Original Message -
> The indices are not consecutive when using the geometry shader,
> which means we were extracting non existing values. Create
> an array of linear indices and always use it instead of the passed
> indices. Found
The indices are not consecutive when using the geometry shader,
which means we were extracting non existing values. Create
an array of linear indices and always use it instead of the passed
indices. Found by Jose.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_llvm.c |6 --
On 13 May 2013 12:02, Ian Romanick wrote:
> I've just picked over a bunch of commits to the 9.1 branch. There are a
> few commits (some fairly old) that wouldn't pick cleanly. Hopefully
> someone that knows that code can either resolve the conflicts or add the
> commit IDs to bin/.cherry-ignore
On 05/10/2013 11:37 PM, Eric Anholt wrote:
This is the opportunity that radeon and intel drivers rely on for flushing
render targets that may get reused as textures. Before EGL, that only
happened for GL_TEXTURE attachments.
Fixes piglits:
KHR_gl_renderbuffer_image/renderbuffer-texture
OES_EGL_
On Fri, 2013-05-10 at 03:42 +0200, Marek Olšák wrote:
> There were 2 issues with it:
> 1) The texture format which should be used for texturing was only set
>in gl_texture_image::TexFormat, which wasn't used for sampler views.
> 2) Textures are sometimes reallocated under some circumstances
>
> LGTM, though is the difference to the non-llvm path now on purpose?
Ah, yes, that's a good catch. I'll fix that
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
This looks a good way to address the problem. Thanks.
I didn't know you were already looking at this and I was in a rush to fix the
regression, I went ahead and pushed a temporary workaround. You'll need to
rebase or revert my workaround -- eitherway it will be trivial.
Jose
- Original M
On Sun, May 12, 2013 at 08:37:17PM -0700, Vinson Lee wrote:
> Signed-off-by: Vinson Lee
> ---
Thanks Vinson, I've pushed this patch.
> src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld
Alternative fix:
http://lists.freedesktop.org/archives/mesa-dev/2013-May/039360.html
In any case, the fix must be a candidate for the stable branches.
Marek
On Tue, May 14, 2013 at 10:39 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Some drivers change the default for Const.MaxUniformBufferB
Some Gallium drivers were crashing, because the array was not large enough.
NOTE: This is a candidate for the stable branches.
---
src/mesa/main/bufferobj.c | 10 ++
src/mesa/main/config.h |2 ++
src/mesa/main/mtypes.h |3 ++-
src/mes
https://bugs.freedesktop.org/show_bug.cgi?id=64590
Priority: medium
Bug ID: 64590
Assignee: mesa-dev@lists.freedesktop.org
Summary: broken compilation on gallivm/lp_bld_debug.cpp no
matching function for call to
'll
https://bugs.freedesktop.org/show_bug.cgi?id=64568
José Fonseca changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |mar...@gmail.com
|org
https://bugs.freedesktop.org/show_bug.cgi?id=64568
--- Comment #2 from José Fonseca ---
> 614ee25077b7ffafeb87b22563d01856824fb4bc is the first bad commit
> commit 614ee25077b7ffafeb87b22563d01856824fb4bc
> Author: Marek Olšák
> Date: Thu May 2 02:38:43 2013 +0200
>
> st/mesa: initialize
https://bugs.freedesktop.org/show_bug.cgi?id=64568
José Fonseca changed:
What|Removed |Added
CC||bri...@vmware.com,
|
> From 8aa41148651150eb19332436c76fe490d4b54b1e Mon Sep 17 00:00:00 2001
> From: Vincent Lejeune
> Date: Sun, 12 May 2013 16:29:50 +0200
> Subject: [PATCH 1/2] R600: Rename 128 bit registers.
>
> Almost all instructions that takes a 128 bits reg as input (fetch, export...)
> have the abilities
- Original Message -
> Le dimanche 12 mai 2013 20:37:17 Vinson Lee a écrit :
> > Signed-off-by: Vinson Lee
> > ---
> > src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_d
Am 14.05.2013 05:09, schrieb Zack Rusin:
> the number of vertices to fetch doesn't necessarily equal the
> total number of input vertices, e.g. we might want to fetch
> a single vertex but then draw it twice. Lets use the correct
> number of input vertices in the statistics.
>
> Signed-off-by: Zac
From: Dave Airlie
Some drivers change the default for Const.MaxUniformBufferBindings,
the current code allocates them before the point drivers would ever get
a chance to do such modifications.
Instead allocate them, and if the driver requires it can later reallocate
them to there larger side.
I
On Mon, 2013-05-13 at 16:53 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Note: this is a candidate for the 9.1 branch
>
> Signed-off-by: Alex Deucher
For the series:
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libr
27 matches
Mail list logo
