[Mesa-dev] [PATCH v2]: gallium DRI Image v7 support

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

[Mesa-dev] [PATCH 1/2] gallium/dri: Allow drivers to support DRI Image v7 (v2)

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

[Mesa-dev] [PATCH 2/2] nouveau: Support DRI Image v7

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

Re: [Mesa-dev] uvd code break with C99 compile

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

Re: [Mesa-dev] uvd code break with C99 compile

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

Re: [Mesa-dev] renaming i965g

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

[Mesa-dev] [PATCH] include/egl: Remove declaration of wl_egl_pixmap

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

Re: [Mesa-dev] uvd code break with C99 compile

- 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

[Mesa-dev] [PATCH] radeon/uvd: stop using anonymous unions

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 |

[Mesa-dev] [PATCH 1/2] mesa/st: Don't copy propagate from swizzles.

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

[Mesa-dev] [PATCH 2/2] mesa/program: Don't copy propagate from swizzles.

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

Re: [Mesa-dev] renaming i965g

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

[Mesa-dev] [PATCH] r600/uvd: stop advertising MPEG4 on UVD 2.x chips

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/

Re: [Mesa-dev] [PATCH] r600/uvd: stop advertising MPEG4 on UVD 2.x chips

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

Re: [Mesa-dev] uvd code break with C99 compile

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

Re: [Mesa-dev] [PATCH 1/6] configure.ac: Remove unused HAVE_PIPE_LOADER_XLIB macro.

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 "

Re: [Mesa-dev] [PATCH] r600/uvd: stop advertising MPEG4 on UVD 2.x chips

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

[Mesa-dev] [PATCH] r600/uvd: stop advertising MPEG4 on UVD 2.x chips v2

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

Re: [Mesa-dev] [PATCH] r600/uvd: stop advertising MPEG4 on UVD 2.x chips v2

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

Re: [Mesa-dev] [PATCH 1/6] configure.ac: Remove unused HAVE_PIPE_LOADER_XLIB macro.

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

Re: [Mesa-dev] [PATCH] intel: Be more conservative in disabling tiling to save memory.

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

Re: [Mesa-dev] [PATCH] i965/fs: Allow LRPs with uniform registers.

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

Re: [Mesa-dev] [PATCH 1/2] i965/vs: Add a function to fix-up uniform arguments for 3-src insts.

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

Re: [Mesa-dev] [PATCH] i965: Stop passing num_samples to intel_miptree_alloc_hiz().

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

Re: [Mesa-dev] [PATCH] i965: Disable Z16 on contexts that don't require it.

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

Re: [Mesa-dev] [PATCH 2/3] intel: Report FBO incompleteness causes through GL_ARB_debug_output.

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

[Mesa-dev] [PATCH] llvmpipe: get rid of depth swizzling.

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

[Mesa-dev] [PATCH 1/3] r600g/compute: Fix build error in debug code

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

[Mesa-dev] [PATCH 2/3] r600g/compute: Use the GFX ring for compute

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

[Mesa-dev] [PATCH 3/3] r600g: Don't set the dest cache bits on surface sync for R600_CONTEXT_FLUSH_AND_INV

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

[Mesa-dev] [PATCH] llvmpipe: get rid of depth swizzling.

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

[Mesa-dev] [PATCH] mesa: fix the compressed TexSubImage size checking code

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

Re: [Mesa-dev] [PATCH] mesa: fix the compressed TexSubImage size checking code

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

[Mesa-dev] [PATCH 1/2] R600: Fix encoding of CF_END_{EG, R600} instructions

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

[Mesa-dev] [PATCH 2/2] R600: Use correct CF_END instruction on Northern Island GPUs

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

[Mesa-dev] [PATCH] gallivm: Fix altivec intrinsics for 8xi16 add/sub

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/

[Mesa-dev] visual leak?

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

[Mesa-dev] [PATCH 1/2] llvmpipe: bump LP_MAX_THREADS to 16

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

[Mesa-dev] [PATCH 2/2] llvmpipe: replace LP_MAX_THREADS with screen->num_threads in query code

--- 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

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: replace LP_MAX_THREADS with screen->num_threads in query code

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/

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: replace LP_MAX_THREADS with screen->num_threads in query code

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

Re: [Mesa-dev] [PATCH 1/3] r600g/compute: Fix build error in debug code

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

[Mesa-dev] [PATCH] i965/fs: Don't try to use bogus interpolation modes pre-Gen6.

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 --

[Mesa-dev] [PATCH 9.1] Fix source games rendering issues on ILK

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

[Mesa-dev] [PATCH 9.1 1/2] i965/vs: Fix Gen4/5 VUE map inconsistency with gl_ClipVertex

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:

[Mesa-dev] [PATCH 9.1 2/2] i965/fs: Don't try to use bogus interpolation modes pre-Gen6.

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 --

[Mesa-dev] [PATCH] mesa: Make Haiku use mmap vs simple malloc for exec memory

* 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

[Mesa-dev] [PATCH] gallivm: fix indirect addressing of temps in soa mode

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

Re: [Mesa-dev] [PATCH 9.1 1/2] i965/vs: Fix Gen4/5 VUE map inconsistency with gl_ClipVertex

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

Re: [Mesa-dev] [PATCH] i965/fs: Don't try to use bogus interpolation modes pre-Gen6.

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

[Mesa-dev] [PATCH 2/2] llvmpipe: stop crashing when one of the so targets is null

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

[Mesa-dev] [PATCH 1/2] draw/so: indicate overflow when buffer is missing

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/

Re: [Mesa-dev] [PATCH 9.1 1/2] i965/vs: Fix Gen4/5 VUE map inconsistency with gl_ClipVertex

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

Re: [Mesa-dev] [PATCH 9.1 1/2] i965/vs: Fix Gen4/5 VUE map inconsistency with gl_ClipVertex

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

Re: [Mesa-dev] [PATCH 9.1 1/2] i965/vs: Fix Gen4/5 VUE map inconsistency with gl_ClipVertex

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

Re: [Mesa-dev] [PATCH] i965/fs: Don't try to use bogus interpolation modes pre-Gen6.

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

Re: [Mesa-dev] [PATCH] i965/fs: Don't try to use bogus interpolation modes pre-Gen6.

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

[Mesa-dev] [PATCH V2 9.1] i965/vs: Fix Gen4/5 VUE map inconsistency with gl_ClipVertex

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: