This is roughly a backport of Eric's commit 0967c362.
We avoided assigning a slot in the VUE map for gl_ClipVertex, but left
the bit set in outputs_written, producing horrible confusion further
down the pipe.
Mostly fixes rendering in source games, and probably in Freespace 2 SCP.
Signed-off-by:
Reviewed-by: Jordan Justen
Tested-by: Jordan Justen
On Fri, Apr 26, 2013 at 4:52 PM, Chris Forbes wrote:
> Interpolation modes other than perspective-barycentric-pixel-center (and
> their associated coefficients in the WM payload) only exist in Gen6 and
> later.
>
> Unfortunately, if a varying
On 04/26/2013 04:52 PM, Chris Forbes wrote:
Interpolation modes other than perspective-barycentric-pixel-center (and
their associated coefficients in the WM payload) only exist in Gen6 and
later.
Unfortunately, if a varying was declared as `centroid`, we would blindly
read the nonexistant values
Hi Jordan
Ouch. It does indeed break the steam client, horribly.
Need to go digging a little more.
-- Chris
On Sat, Apr 27, 2013 at 5:15 PM, Jordan Justen wrote:
> Chris,
>
> Similar to my attempt to backport 0967c362, I'm seeing issues with the
> steam client on gm45 with this. Does steam loo
So it is, oops!
Brain got onto `untangle this from Paul's VUE map changes` and did its
own thing...
On Sat, Apr 27, 2013 at 4:13 PM, Paul Berry wrote:
> On 26 April 2013 18:20, Chris Forbes wrote:
>>
>> This is roughly a backport of Paul's commit 0967c362.
>
>
> Actually commit 0967c362 is Eric
Chris,
Similar to my attempt to backport 0967c362, I'm seeing issues with the
steam client on gm45 with this. Does steam look okay for you on your
9.1 patches with ILK?
-Jordan
On Fri, Apr 26, 2013 at 6:20 PM, Chris Forbes wrote:
> This is roughly a backport of Paul's commit 0967c362.
>
> We av
We were crashing if one of the buffers wasn't set, we should
just treat it as an overflow. It's useful when using so
statistics because it allows one to figure out how much data
would be generated by so without actually writing any of it.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/
Fixes a crash when one of the so targets is null.
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_draw_arrays.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
b/src/gallium/drivers/llvmpipe/lp_draw_arrays
On 26 April 2013 16:52, Chris Forbes wrote:
> Interpolation modes other than perspective-barycentric-pixel-center (and
> their associated coefficients in the WM payload) only exist in Gen6 and
> later.
>
> Unfortunately, if a varying was declared as `centroid`, we would blindly
> read the nonexis
On 26 April 2013 18:20, Chris Forbes wrote:
> This is roughly a backport of Paul's commit 0967c362.
>
Actually commit 0967c362 is Eric's.
In any case, this patch is:
Reviewed-by: Paul Berry
>
> We avoided assigning a slot in the VUE map for gl_ClipVertex, but left
> the bit set in outputs_w
we weren't adding the soa offsets when constructing the indices
for the gather functions. That meant that we were always returning
the data in the first vertex/primitive/pixel in the SoA structure
and not correctly fetching from all structures.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary
* Haiku recently got DEP support which can result in the
OS locking down execution in non-exec flagged memory.
---
src/mesa/main/execmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/execmem.c b/src/mesa/main/execmem.c
index bb9c70a..5f31966 100644
--- a/src
Interpolation modes other than perspective-barycentric-pixel-center (and
their associated coefficients in the WM payload) only exist in Gen6 and
later.
Unfortunately, if a varying was declared as `centroid`, we would blindly
read the nonexistant values, and so produce all manner of bad behavior
--
This is roughly a backport of Paul's commit 0967c362.
We avoided assigning a slot in the VUE map for gl_ClipVertex, but left
the bit set in outputs_written, producing horrible confusion further
down the pipe.
Mostly fixes rendering in source games, and probably in Freespace 2 SCP.
Signed-off-by:
These two patches fix up rendering in CS:S and TF2.
The first fixes horrible confusion if the VS wrote gl_ClipVertex (which
Source's shaders *all* do). (based on Paul's patch which fixes this in master)
The second fixes broken varying interpolation if the shader asked for centroid
interpolation
Interpolation modes other than perspective-barycentric-pixel-center (and
their associated coefficients in the WM payload) only exist in Gen6 and
later.
Unfortunately, if a varying was declared as `centroid`, we would blindly
read the nonexistant values, and so produce all manner of bad behavior
--
On Fri, Apr 26, 2013 at 1:21 PM, Tom Stellard wrote:
> From: Tom Stellard
For the series:
Reviewed-by: Alex Deucher
>
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c
> b
On 04/26/2013 04:11 PM, Roland Scheidegger wrote:
Am 27.04.2013 00:03, schrieb Brian Paul:
---
src/gallium/drivers/llvmpipe/lp_query.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_query.c
b/src/gallium/drivers/llvmpipe/lp_query
Am 27.04.2013 00:03, schrieb Brian Paul:
> ---
> src/gallium/drivers/llvmpipe/lp_query.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_query.c
> b/src/gallium/drivers/llvmpipe/lp_query.c
> index 96e1e3f..fcb5c6a 100644
> --- a/
---
src/gallium/drivers/llvmpipe/lp_query.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_query.c
b/src/gallium/drivers/llvmpipe/lp_query.c
index 96e1e3f..fcb5c6a 100644
--- a/src/gallium/drivers/llvmpipe/lp_query.c
+++ b/src/gallium
On the mesa-users list, Burlen Loring reported a speed-up with 16 cores
and his test/app.
---
src/gallium/drivers/llvmpipe/lp_limits.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_limits.h
b/src/gallium/drivers/llvmpipe/lp_limits.h
inde
Hi. We are seeing a leak of things created in XMesaCreateVisual, as called
from fakeglx.c. I don't see anywhere that XMesaDestroyVisual is called. I see
a free() in destroy_visuals_on_display, but I don't know how often that is
called. Are these visuals intended to be kept around?
The visua
Signed-off-by: Adam Jackson
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index ec05026..524a8e7 100644
--- a/src/gallium/auxiliary/
From: Tom Stellard
---
lib/Target/R600/R600ControlFlowFinalizer.cpp | 2 +-
test/CodeGen/R600/cf_end.ll | 7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/Target/R600/R600ControlFlowFinalizer.cpp
b/lib/Target/R600/R600ControlFlowFinalizer.cpp
index
From: Tom Stellard
The EOP bit was not being encoded.
---
lib/Target/R600/R600Instructions.td | 1 +
test/CodeGen/R600/cf_end.ll | 6 ++
2 files changed, 7 insertions(+)
create mode 100644 test/CodeGen/R600/cf_end.ll
diff --git a/lib/Target/R600/R600Instructions.td
b/lib/Target/R6
Am 26.04.2013 21:55, schrieb Brian Paul:
> Before, we'd incorrectly generate an error if we we tried to
> replace a non-4x4 block near the edge of a NPOT compressed texture.
> For example, if the dest image was 15 texels wide and xoffset=12
> and width=3 we'd incorrectly generate GL_INVALID_OPERATI
Before, we'd incorrectly generate an error if we we tried to
replace a non-4x4 block near the edge of a NPOT compressed texture.
For example, if the dest image was 15 texels wide and xoffset=12
and width=3 we'd incorrectly generate GL_INVALID_OPERATION.
Verified with new tests added to piglit s3tc
From: Roland Scheidegger
Eliminating this we no longer need to copy between linear and swizzled layout.
This is probably not quite ideal since it's a bit more work for now, could do
some optimizations by moving depth testing outside the fragment shader loop
(but tricky for early depth test as we
From: Tom Stellard
We are already emitting a EVENT_TYPE_CACHE_FLUSH_AND_INV_EVENT packet
when this flush flag is set, so flushing the dest caches with a
SURFACE_SYNC should not be necessary.
The motivation for this change is that emitting a SURFACE_SYNC packet with
the CB bits set was causing co
From: Tom Stellard
Only Cayman has a separate compute ring, but it has some hw bugs, so to
be safe we will stick with the GFX.
---
src/gallium/drivers/r600/evergreen_compute.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/s
From: Tom Stellard
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 189ffac..8f19dfc 100644
--- a/src/gallium/drivers/r600/evergr
From: Roland Scheidegger
Eliminating this we no longer need to copy between linear and swizzled layout.
This is probably not quite ideal since it's a bit more work for now, could do
some optimizations by moving depth testing outside the fragment shader loop
(but tricky for early depth test as we
On 04/25/2013 01:20 PM, Eric Anholt wrote:
---
src/mesa/drivers/dri/intel/intel_fbo.c | 56 +++-
1 file changed, 34 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 9fcee14..15d3918
On 04/25/2013 01:12 PM, Eric Anholt wrote:
It appears that Z16 on Intel hardware is in fact slower than Z24, so
people are getting surprisingly hurt when trying to use Z16 as a
performance-versus-precision tradeoff, or when they're targeting GLES2 and
that's all you get.
GL 3.0+ have Z16 on the
On 04/25/2013 11:15 AM, Paul Berry wrote:
The number of samples is already available in the miptree data
structure, so there's no need to pass it in.
I suspect this may fix a subtle bug because in one case
(intel_renderbuffer_update_wrapper) we were always passing zero for
num_samples, even thou
On 04/25/2013 11:51 AM, Matt Turner wrote:
Three-source instructions have a vertical stride overloaded to 4, which
prevents directly using vec4 uniforms as arguments. Instead we need to
insert a MOV instruction to do the replication for the three-source
instruction.
With this in place, we can us
On 04/25/2013 09:06 PM, Eric Anholt wrote:
Improves GLB2.7 performance on my HSW by 0.671455% +/- 0.225037% (n=62).
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b
On Thu, Apr 25, 2013 at 03:41:01PM -0700, Eric Anholt wrote:
> Improves GLB2.7 trex performance 1.01985% +/- 0.721366% on my IVB (n=10)
> and by 3.38771% +/- 0.584241% (n=15) on my HSW, due to a 32x32 ARGB
> cubemap going from untiled to tiled.
> ---
> src/mesa/drivers/dri/intel/intel_mipmap_t
For the series:
Tested-by: Aaron Watry
Config:
./configure --with-dri-drivers=radeon --with-gallium-drivers=r600
--enable-texture-float --enable-opencl --enable-gles1 --enable-gles2
--enable-xvmc --enable-vdpau --enable-r600-llvm-compiler
--with-egl-platforms=x11,drm --enable-glx-tls
On Thu, A
On Fri, Apr 26, 2013 at 9:26 AM, Christian König
wrote:
> From: Christian König
>
> That is just not supported by the hardware.
>
> v2: fix compare
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_pipe.c|2 +-
> src/gallium/drivers/r6
From: Christian König
That is just not supported by the hardware.
v2: fix compare
Signed-off-by: Christian König
---
src/gallium/drivers/r600/r600_pipe.c|2 +-
src/gallium/drivers/r600/r600_pipe.h|3 +++
src/gallium/drivers/r600/r600_uvd.c | 14 ++
src/galliu
On Fri, Apr 26, 2013 at 5:51 AM, Christian König
wrote:
> From: Christian König
>
> That is just not supported by the hardware.
>
> Signed-off-by: Christian König
> ---
> src/gallium/drivers/r600/r600_pipe.c|2 +-
> src/gallium/drivers/r600/r600_pipe.h|3 +++
> src/gallium/drive
On 04/25/2013 01:02 PM, Matt Turner wrote:
Added in e1364530 but never used.
---
configure.ac |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 50e60f6..55ea13d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1899,7 +1899,6 @@ if test "
Am 26.04.2013 10:56, schrieb Jose Fonseca:
- Original Message -
On Fri, Apr 26, 2013 at 4:48 PM, Jose Fonseca wrote:
- Original Message -
Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
uses anonymous unions which this disables.
It doesn't look too diff
On Fre, 2013-04-26 at 11:51 +0200, Christian König wrote:
> From: Christian König
>
> That is just not supported by the hardware.
>
> Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthus
From: Christian König
That is just not supported by the hardware.
Signed-off-by: Christian König
---
src/gallium/drivers/r600/r600_pipe.c|2 +-
src/gallium/drivers/r600/r600_pipe.h|3 +++
src/gallium/drivers/r600/r600_uvd.c | 14 ++
src/gallium/drivers/radeon/
On Fri, Apr 26, 2013 at 04:26:05PM +0800, Chia-I Wu wrote:
> I just pushed the driver to master, under the name ilo. The driver is
> still new and has many bugs or known issues, but I will continue
> improving it.
FYI, you can use:
Section "Device"
Identifier "Device0"
Driver "In
Do not propagate a copy if source and destination are identical.
Otherwise code like
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].xyzw
is changed to
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].wzyx
This fixes Piglit test shaders/glsl-copy-propagation-self-2 for drivers
Do not propagate a copy if source and destination are identical.
Otherwise code like
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].xyzw
is changed to
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].wzyx
This fixes Piglit test shaders/glsl-copy-propagation-self-2 for gallium
From: Christian König
Signed-off-by: Christian König
---
src/gallium/drivers/r600/r600_uvd.c |4 +-
src/gallium/drivers/radeon/radeon_uvd.c | 66 +--
src/gallium/drivers/radeon/radeon_uvd.h |6 +--
src/gallium/drivers/radeonsi/radeonsi_uvd.c |
- Original Message -
> On Fri, Apr 26, 2013 at 4:48 PM, Jose Fonseca wrote:
> >
> >
> > - Original Message -
> >> Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
> >> uses anonymous unions which this disables.
> >>
> >> It doesn't look too difficult to fix, ju
Wayland pixmaps were removed by commit wayland-e20a0f1 before the release
of wayland-1.0. Support was dropped from mesa-9.0.1 by commit
mesa-009d452.
This patch removes a vestigial remnant of Wayland pixmaps: a declaration
in eglplatform.h.
Signed-off-by: Chad Versace
---
include/EGL/eglplatfo
On Sat, Apr 20, 2013 at 1:06 AM, Chia-I Wu wrote:
> On Thu, Apr 18, 2013 at 2:29 PM, Chia-I Wu wrote:
>> Hi list,
>>
>> Per the discussion, i965g is confusing and misleading. Instead of
>> preventing the confusions via
>>
>> --with-gallium-drivers=i965g-unofficial or
>> --with-gallium-driver
On Fri, Apr 26, 2013 at 4:48 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
>> uses anonymous unions which this disables.
>>
>> It doesn't look too difficult to fix, just wondering if there was a
>> reason for usi
Am 26.04.2013 08:48, schrieb Jose Fonseca:
- Original Message -
Building on RHEL6 tinderbox, we get -std=c99, and the radeon uvd code
uses anonymous unions which this disables.
It doesn't look too difficult to fix, just wondering if there was a
reason for using anon unions in the first
From: Christopher James Halse Rogers
---
src/gallium/drivers/nouveau/nouveau_screen.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
b/src/gallium/drivers/nouveau/nouveau_screen.c
index e1d4ca5..1f0aa72 100644
--- a/s
From: Christopher James Halse Rogers
Enabled based on kernel drm support for dma-buf.
v2: Detect dma-buf support from st/dri rather than adding a PIPE_CAP_PRIME
---
src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
src/gallium/drivers/nouveau/nouveau_screen.c | 6 +
src/galliu
This reworks the DRI Image v7 support to remove winsys-specific
code from the pipe drivers. In return, this will incorrectly
enable v7 support when the kernel drm has prime support but
the driver does not.
___
mesa-dev mailing list
mesa-dev@lists.freedes
58 matches
Mail list logo
