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
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
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
- 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
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=64568
José Fonseca changed:
What|Removed |Added
CC||bri...@vmware.com,
|
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
Assignee|mesa-dev@lists.freedesktop. |mar...@gmail.com
|org
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
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
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
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
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
> 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
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
>
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 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
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 --
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
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
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
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
---
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 |
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
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 ++
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
27 matches
Mail list logo
