Re: [Mesa-dev] [PATCH 2/2] radeonsi: Implement ddx/ddy on VI using ds_bpermute

On 16.04.2016 11:39, Tom Stellard wrote: > The ds_bpermute instruction allows threads to transfer data directly > to or from the vgprs of other threads. These instructions use the lds > hardware to transfer data, but do not read or write lds memory. > > DDX BEFORE:| DDX

[Mesa-dev] [Bug 94955] Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)

https://bugs.freedesktop.org/show_bug.cgi?id=94955 Roland Scheidegger changed: What|Removed |Added Resolution|--- |FIXED

[Mesa-dev] [PATCH 2/2] radeonsi: Implement ddx/ddy on VI using ds_bpermute

The ds_bpermute instruction allows threads to transfer data directly to or from the vgprs of other threads. These instructions use the lds hardware to transfer data, but do not read or write lds memory. DDX BEFORE:| DDX AFTER: |

Re: [Mesa-dev] [PATCH] svga: separate HUD counters for state objects

Reviewed-by: Charmaine Lee From: Brian Paul Sent: Friday, April 15, 2016 2:41 PM To: mesa-dev@lists.freedesktop.org Cc: Charmaine Lee Subject: [PATCH] svga: separate HUD counters for state objects Count

[Mesa-dev] [PATCH 1/2] radeonsi: Use llvm.amdgcn.mbcnt.* intrinsics instead of llvm.SI.tid

We're trying to move to more of the new style intrinsics with include the correct target name, and map directly to ISA instructions. --- src/gallium/drivers/radeonsi/si_shader.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [Bug 94168] Incorrect rendering when running Populous 3 on wine using DDraw->WineD3D->OpenGL wrapper [apitrace]

https://bugs.freedesktop.org/show_bug.cgi?id=94168 Grazvydas Ignotas changed: What|Removed |Added CC||nota...@gmail.com

[Mesa-dev] [Bug 94168] Incorrect rendering when running Populous 3 on wine using DDraw->WineD3D->OpenGL wrapper [apitrace]

https://bugs.freedesktop.org/show_bug.cgi?id=94168 --- Comment #6 from Grazvydas Ignotas --- I've put my HD 5770 in and can confirm r600g suffers from this too. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the

[Mesa-dev] [PATCH 1/7] util: add MAYBE_UNUSED for config dependent variables

This is mostly for variables that are only used in asserts and cause unused-but-set-variable warnings in release builds. Could just use UNUSED directly, but MAYBE_UNUSED should be less confusing and is similar to what the Linux kernel has. And yes __attribute__((unused)) can be used on variables

[Mesa-dev] [PATCH 3/7] gallium: fix warnings in release build

Mark variables MAYBE_UNUSED to avoid unused-but-set-variable warnings in release build. Signed-off-by: Grazvydas Ignotas --- I have no commit access, if this patch is ok, please someone push. src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c | 2 +-

[Mesa-dev] [PATCH 6/7] anv: fix warnings in release build

Mark variables MAYBE_UNUSED to avoid unused-but-set-variable warnings in release build. Signed-off-by: Grazvydas Ignotas --- I have no commit access, if this patch is ok, please someone push. src/intel/vulkan/anv_dump.c | 2 +-

[Mesa-dev] [PATCH 0/7] release build warning fixes

I guess almost everyone here builds mesa with asserts enabled, but many forget asserts are off by default, so ordinary users get thrown at quite a lot of warnings. This tries to improve the situation somewhat. Grazvydas Ignotas (7): util: add MAYBE_UNUSED for config dependent variables glsl:

[Mesa-dev] [PATCH 4/7] spirv: fix warning in release build

Mark variable MAYBE_UNUSED to avoid unused-but-set-variable warning in release build. Signed-off-by: Grazvydas Ignotas --- I have no commit access, if this patch is ok, please someone push. src/compiler/spirv/vtn_cfg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Mesa-dev] [PATCH 5/7] isl: fix warnings in release build

Mark variables MAYBE_UNUSED to avoid unused-but-set-variable warnings in release build. Signed-off-by: Grazvydas Ignotas --- I have no commit access, if this patch is ok, please someone push. src/intel/isl/isl.c | 2 +- src/intel/isl/isl_gen7.c | 2 +- 2 files changed,

[Mesa-dev] [PATCH 2/7] glsl: fix warning in release build

Mark variable MAYBE_UNUSED to avoid unused-but-set-variable warning in release build. Signed-off-by: Grazvydas Ignotas --- I have no commit access, if this patch is ok, please someone push. src/compiler/glsl/lower_buffer_access.cpp | 2 +- 1 file changed, 1 insertion(+), 1

[Mesa-dev] [PATCH 7/7] gallium: use unreachable instead of asserts

Avoids warnings in release builds. Signed-off-by: Grazvydas Ignotas --- I have no commit access, if this patch is ok, please someone push. src/gallium/auxiliary/gallivm/lp_bld_intr.c | 2 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 +- 2 files changed, 2

Re: [Mesa-dev] [PATCH] i965/fs: Don't allow OOB array access of images

Francisco Jerez writes: > Jason Ekstrand writes: > >> We have had a guard against OOB array access of images on IVB for a long >> time, but it can actually cause hangs on any GPU generation. This can >> happen due to getting an untyped SURFACE_STATE

[Mesa-dev] [Bug 94957] dEQP failures on llvmpipe

https://bugs.freedesktop.org/show_bug.cgi?id=94957 --- Comment #4 from Roland Scheidegger --- (In reply to Ilia Mirkin from comment #3) > I will start a fresh run with these parameters. A random blending test makes > it seem like it completely fails. I'd like to encourage you

[Mesa-dev] [Bug 94955] Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)

https://bugs.freedesktop.org/show_bug.cgi?id=94955 --- Comment #5 from Roland Scheidegger --- (In reply to Roland Scheidegger from comment #4) > I actually tried to give the replay a look, but the problem is that so far > I've always failed to get apitrace + valgrind + gdb to

[Mesa-dev] [Bug 94957] dEQP failures on llvmpipe

https://bugs.freedesktop.org/show_bug.cgi?id=94957 --- Comment #3 from Ilia Mirkin --- A random sampling of the texturing tests that failed seem to all pass with GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod I will start a fresh run with these parameters. A random

Re: [Mesa-dev] [PATCH] gallium/util: fix undefined shift to the last bit in u_bit_scan

Reviewed-by: Bas Nieuwenhuizen On Sat, Apr 16, 2016 at 2:13 AM, Marek Olšák wrote: > From: Marek Olšák > > --- > src/gallium/auxiliary/util/u_math.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [Mesa-dev] [PATCH] amdgpu/winsys: adjust IB size based on buffer wait time

On Fri, Apr 15, 2016 at 7:50 PM, Grigori Goronzy wrote: > Small IBs help to reduce stalls for workloads that require a lot of > synchronization. On the other hand, if there is no notable > synchronization, we can use a large IB size to slightly improve > performance in some

[Mesa-dev] [Bug 94957] dEQP failures on llvmpipe

https://bugs.freedesktop.org/show_bug.cgi?id=94957 --- Comment #2 from Roland Scheidegger --- Oh, linear mipmap filtering should work perfectly. For performance reasons though we cheat, which is likely why it fails. The cheats can be disabled via env var, preferably all 3 of

Re: [Mesa-dev] [PATCH] i965/fs: Don't allow OOB array access of images

Jason Ekstrand writes: > We have had a guard against OOB array access of images on IVB for a long > time, but it can actually cause hangs on any GPU generation. This can > happen due to getting an untyped SURFACE_STATE for a typed message or > vice-versa. Are you sure

[Mesa-dev] [Bug 94955] Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)

https://bugs.freedesktop.org/show_bug.cgi?id=94955 --- Comment #4 from Roland Scheidegger --- (In reply to Roland Scheidegger from comment #2) > > > ==32054== Conditional jump or move depends on uninitialised value(s) > > > ==32054==at 0x404002D: ??? > > > ==32054==by

[Mesa-dev] [Bug 94955] Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)

https://bugs.freedesktop.org/show_bug.cgi?id=94955 --- Comment #3 from Emil Velikov --- (In reply to David Lonie from comment #0) > (Regular 'make install' does this in the install dir for some reason: > > $ ls mesa-master-install/lib/libMesaGL.so* -lh

[Mesa-dev] [PATCH] gallium/util: fix undefined shift to the last bit in u_bit_scan

From: Marek Olšák --- src/gallium/auxiliary/util/u_math.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h index 0a82915..d983af3 100644 --- a/src/gallium/auxiliary/util/u_math.h

Re: [Mesa-dev] [PATCH] st/nine: correctly fold guards around define WINAPI

On 15 April 2016 at 22:11, Grazvydas Ignotas wrote: > On Fri, Apr 15, 2016 at 9:46 PM, Christian Schmidbauer > wrote: >> On 15/04/16 17:06, Emil Velikov wrote: >>> From: Emil Velikov >>> >>> The __i386__ and __x86-64__

Re: [Mesa-dev] [PATCH] gallium/util: fix u_bit_scan_consecutive_range for mask == 0xffffffff

On Sat, Apr 16, 2016 at 12:40 AM, Bas Nieuwenhuizen wrote: > On Sat, Apr 16, 2016 at 12:34 AM, Marek Olšák wrote: >> From: Marek Olšák >> >> The second ffs returns 0, yielding count == -1. >> --- >>

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

On 15 April 2016 at 19:58, Chuck Atkins wrote: > On Fri, Apr 15, 2016 at 2:07 PM, Emil Velikov > wrote: >> >> On 15 April 2016 at 16:36, Chuck Atkins wrote: >> > Instead of cascading support for various different

[Mesa-dev] [Bug 94957] dEQP failures on llvmpipe

https://bugs.freedesktop.org/show_bug.cgi?id=94957 --- Comment #1 from Ilia Mirkin --- This was, by the way, the result of running mesa master with LIBGL_ALWAYS_SOFTWARE=1 ./deqp-gles3 --deqp-visibility=hidden --deqp-caselist-file=<(grep -v 'mipmap_linear'

[Mesa-dev] [Bug 94957] dEQP failures on llvmpipe

https://bugs.freedesktop.org/show_bug.cgi?id=94957 Bug ID: 94957 Summary: dEQP failures on llvmpipe Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal

Re: [Mesa-dev] [PATCH v2 03/11] mesa/st: add helper to return pipe_endian based on pipe_format

On Fri, Apr 15, 2016 at 12:01 PM, Michel Dänzer wrote: > On 14.04.2016 21:18, Oded Gabbay wrote: >> Add a helper function which receives pipe_format value and returns a >> matching pipe_endian value. It is needed because almost every call to >> st_create_texture will use this

Re: [Mesa-dev] [PATCH v2 02/11] r600g: Move R600_BIG_ENDIAN to r600_pipe_common.h

For patches 1-2: Reviewed-by: Marek Olšák Feel free to push those two. Marek On Thu, Apr 14, 2016 at 2:18 PM, Oded Gabbay wrote: > I need to do this so I could use R600_BIG_ENDIAN in files which include > r600_pipe_common.h but not r600_pipe.h > >

[Mesa-dev] [PATCH] mesa: add tags file to gitignore

For ctags users like me. Signed-off-by: Grazvydas Ignotas --- I have no commit access, if this patch is ok, please someone push. .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index b4f88f7..7db5639 100644 --- a/.gitignore +++

Re: [Mesa-dev] [PATCH] gallium/radeon: fix Nine with its slightly shifted viewports

Reviewed-by: Axel Davy On 16/04/2016 00:44, Marek Olšák wrote: From: Marek Olšák just need to do the calculation in floating-point and then round things properly --- src/gallium/drivers/radeon/r600_viewport.c | 36 +- 1

[Mesa-dev] [PATCH] gallium/radeon: fix Nine with its slightly shifted viewports

From: Marek Olšák just need to do the calculation in floating-point and then round things properly --- src/gallium/drivers/radeon/r600_viewport.c | 36 +- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git

Re: [Mesa-dev] [PATCH] gallium/util: initialize pipe_framebuffer_state to zeros

Reviewed-by: Marek Olšák Marek On Fri, Apr 15, 2016 at 8:15 PM, Brian Paul wrote: > To silence a valgrind uninitialized memory warning. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94955 > Cc: "11.1 11.2"

Re: [Mesa-dev] [PATCH] gallium/util: fix u_bit_scan_consecutive_range for mask == 0xffffffff

On Sat, Apr 16, 2016 at 12:34 AM, Marek Olšák wrote: > From: Marek Olšák > > The second ffs returns 0, yielding count == -1. > --- > src/gallium/auxiliary/util/u_math.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git

[Mesa-dev] [PATCH] gallium/util: fix u_bit_scan_consecutive_range for mask == 0xffffffff

From: Marek Olšák The second ffs returns 0, yielding count == -1. --- src/gallium/auxiliary/util/u_math.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h index b4ac0db..2880eea 100644 ---

Re: [Mesa-dev] [PATCH 13/13] radeonsi: Use CE for all descriptors.

I've commented on some of the patches, but the series is: Reviewed-by: Marek Olšák I'd still like to have the preamble CE IB (explained in 00/13) implemented before this lands, so that context flushes are reasonably fast. Only the closed GL driver has been using it so far.

Re: [Mesa-dev] [PATCH] gallium/radeon: handle vertex shaders that disable clipping & viewport

The patch seems unneeded, as a lot of nine apps with the disabled clipping behaviour are working fine. It seems the bug is with the scissor bound computation: for power of two RT, nine is removing a small offset to the viewport for radeon to workaround a raterizer precision bug. The scissor

[Mesa-dev] [PATCH] svga: separate HUD counters for state objects

Count depth/stencil, blend, sampler, etc. state objects separately but just report the sum for the HUD. This change lets us use gdb to see the breakdown of state objects in more detail. Also, count sampler views too. --- src/gallium/drivers/svga/svga_context.h | 10 +-

Re: [Mesa-dev] [PATCH] st/nine: correctly fold guards around define WINAPI

On Fri, Apr 15, 2016 at 9:46 PM, Christian Schmidbauer wrote: > On 15/04/16 17:06, Emil Velikov wrote: >> From: Emil Velikov >> >> The __i386__ and __x86-64__ macros are gcc/clang specific, thus one does >> not need the __GNUC__ at the top.

Re: [Mesa-dev] Merging the Vulkan driver

On 04/05/2016 12:30 PM, Jason Ekstrand wrote: ... > If people step up with code review, I'm hoping that we can merge some > time this week or next. > > --Jason Ekstrand Woo! The Vulkan code is finally merged! ___ mesa-dev mailing list

Re: [Mesa-dev] [PATCH] util/list: Add list splicing functions

Reviewed-by: Mark Janes Jason Ekstrand writes: > This adds functions for splicing one list into another. These have > more-or-less the same API as the kernel list splicing functions. > --- > src/util/list.h | 22 ++ > 1 file

Re: [Mesa-dev] [PATCH] swr: ignore generated files in rasterizer

> On Apr 15, 2016, at 1:30 PM, Ilia Mirkin wrote: > > Signed-off-by: Ilia Mirkin > --- > src/gallium/drivers/swr/.gitignore | 7 +++ > 1 file changed, 7 insertions(+) > create mode 100644 src/gallium/drivers/swr/.gitignore > > diff --git

Re: [Mesa-dev] [PATCH 12/13] gallium/util: Add u_bit_scan_consecutive_range64.

On Thu, Apr 14, 2016 at 8:05 PM, Nicolai Hähnle wrote: > On 13.04.2016 20:35, Bas Nieuwenhuizen wrote: >> >> For use by radeonsi. >> >> Signed-off-by: Bas Nieuwenhuizen >> --- >> src/gallium/auxiliary/util/u_math.h | 8 >> 1 file changed,

Re: [Mesa-dev] [Mesa-stable] [PATCH] llvmpipe: (trivial) initialize src1_alpha var to NULL

On 04/15/2016 01:22 PM, srol...@vmware.com wrote: From: Roland Scheidegger The blend code would do a conditional assignment based on it, causing valgrind to complain. Since that variable was actually unused in this case, this doesn't fix anything but the warning. Bugzilla:

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #60 from higu...@gmx.net --- Created attachment 122976 --> https://bugs.freedesktop.org/attachment.cgi?id=122976=edit apitrace using radeon Using ubuntu 15.10 with oibaf PPA, we get the crash using the intel and the radeon drivers.

Re: [Mesa-dev] [PATCH] i965/fs: Don't allow OOB array access of images

Tested-by: Mark Janes Jason Ekstrand writes: > We have had a guard against OOB array access of images on IVB for a long > time, but it can actually cause hangs on any GPU generation. This can > happen due to getting an untyped SURFACE_STATE for a

[Mesa-dev] [PATCH] llvmpipe: (trivial) initialize src1_alpha var to NULL

From: Roland Scheidegger The blend code would do a conditional assignment based on it, causing valgrind to complain. Since that variable was actually unused in this case, this doesn't fix anything but the warning. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94955

Re: [Mesa-dev] [PATCH] util: Fix warning of invalid return value

Reviewed-by: Mark Janes Chad Versace writes: > _mesa_libgcrypt_init() returns NULL, but its return type is void. > > Cc: Mark Janes > --- > src/util/mesa-sha1.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >

[Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice (v2)

(Sorry about the bad line wraps in the first one) Instead of cascading support for various different implementations of GLX, all three options are now specified through the --enable-glx option: --enable-glx=dri : Enable the DRI-based GLX --enable-glx=xlib : Enable the

[Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice (v2)

Instead of cascading support for various different implementations of GLX, all three options are now specified through the --enable-glx option: --enable-glx=dri : Enable the DRI-based GLX --enable-glx=xlib : Enable the classic Xlib-based GLX --enable-glx=gallium-xlib :

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

On Fri, Apr 15, 2016 at 2:07 PM, Emil Velikov wrote: > On 15 April 2016 at 16:36, Chuck Atkins wrote: > > Instead of cascading support for various different implementations of > > GLX, all three options are now specified through the

Re: [Mesa-dev] [PATCH 0/2] more Android build fixes

On Fri, Apr 15, 2016 at 12:30 PM, Emil Velikov wrote: > On 14 April 2016 at 20:40, Rob Herring wrote: >> A couple more Android build fixes after rebasing to the current tip. >> >> Android master builds are still a bit broken because makefiles get >>

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

On 04/15/2016 12:44 PM, Emil Velikov wrote: On 15 April 2016 at 19:28, Brian Paul wrote: Having the top-level lib/ directory is definitely a convenience. But I'm not sure I know what you're asking. Hehe silly me. Let me try again. Why do we have three different versions

Re: [Mesa-dev] [PATCH] st/nine: correctly fold guards around define WINAPI

On 15/04/16 17:06, Emil Velikov wrote: > From: Emil Velikov > > The __i386__ and __x86-64__ macros are gcc/clang specific, thus one does > not need the __GNUC__ at the top. > > Additionally, having _M_IX86 and _M_X64 in the same block (and even use >

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

On 15 April 2016 at 19:28, Brian Paul wrote: > Having the top-level lib/ directory is definitely a convenience. But I'm > not sure I know what you're asking. > Hehe silly me. Let me try again. Why do we have three different versions across the different libGL.so files - 1.2

Re: [Mesa-dev] [PATCH] gallium/swr: allow swr use as a swrast dri driver

On 15 April 2016 at 19:26, Ilia Mirkin wrote: > I tested this out, and noticed that I still had to have > --with-gallium-drivers=swrast, or else swrast_dri.so didn't get > built/installed. With swrast,swr it seems to work (at least glxinfo > and glxgears produce expected

[Mesa-dev] [Bug 94955] Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)

https://bugs.freedesktop.org/show_bug.cgi?id=94955 --- Comment #2 from Roland Scheidegger --- (In reply to Brian Paul from comment #1) > (In reply to David Lonie from comment #0) > > ==32054== Conditional jump or move depends on uninitialised value(s) > > ==32054==at

[Mesa-dev] [PATCH] util: Fix warning of invalid return value

_mesa_libgcrypt_init() returns NULL, but its return type is void. Cc: Mark Janes --- src/util/mesa-sha1.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/util/mesa-sha1.c b/src/util/mesa-sha1.c index ca6b89b..b6a192f 100644 ---

Re: [Mesa-dev] [PATCH 03/13] winsys/amdgpu: add support for const IB

On Thu, Apr 14, 2016 at 3:34 AM, Bas Nieuwenhuizen wrote: > From: Marek Olšák > > v2: use the correct IB to update request (Bas Nieuwenhuizen) > --- > src/gallium/drivers/radeon/radeon_winsys.h | 18 +++ >

Re: [Mesa-dev] [PATCH 1/4] gallium/radeon: add clear_texture function

On 2016-04-15 19:23, Grigori Goronzy wrote: On 2016-04-15 18:38, Ilia Mirkin wrote: + } else { + union pipe_color_union color; + switch (util_format_get_blocksizebits(res->format)) { + case 128: + sf->format =

[Mesa-dev] [PATCH] swr: ignore generated files in rasterizer

Signed-off-by: Ilia Mirkin --- src/gallium/drivers/swr/.gitignore | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 src/gallium/drivers/swr/.gitignore diff --git a/src/gallium/drivers/swr/.gitignore b/src/gallium/drivers/swr/.gitignore new file mode 100644

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

On 04/15/2016 12:07 PM, Emil Velikov wrote: On 15 April 2016 at 16:36, Chuck Atkins wrote: Instead of cascading support for various different implementations of GLX, all three options are now specified through the --enable-glx option: Bth having the single switch

Re: [Mesa-dev] [PATCH] gallium/swr: allow swr use as a swrast dri driver

I tested this out, and noticed that I still had to have --with-gallium-drivers=swrast, or else swrast_dri.so didn't get built/installed. With swrast,swr it seems to work (at least glxinfo and glxgears produce expected results). Might be nice if just the swr bit of flipped on everything that was

[Mesa-dev] [PATCH] gallium/target-helpers: remove inline_wrapper_sw_helper.h

From: Emil Velikov Unused as of commit dddedbec0ed "{st,targets}/nine: use static/dynamic pipe-loader" Signed-off-by: Emil Velikov --- .../target-helpers/inline_wrapper_sw_helper.h | 42 -- 1 file changed, 42

Re: [Mesa-dev] [PATCH] gallium/swr: allow swr use as a swrast dri driver

On 15 April 2016 at 18:53, Tim Rowley wrote: > --- > configure.ac | 3 +++ > src/gallium/auxiliary/target-helpers/sw_helper.h | 15 +-- > src/gallium/drivers/swr/Automake.inc | 7 +++ >

Re: [Mesa-dev] [PATCH] gallium/util: initialize pipe_framebuffer_state to zeros

According to the p_state.h file, unsigned samples; /**< Number of samples in a no-attachment framebuffer */ unsigned layers; /**< Number of layers in a no-attachment framebuffer */ so since the fb has attachments here, I think those fields are unused. Cc'ing Edward since he added

Re: [Mesa-dev] [PATCH] gallium/util: initialize pipe_framebuffer_state to zeros

Should it instead properly initialize fb->samples/layers? On Fri, Apr 15, 2016 at 2:15 PM, Brian Paul wrote: > To silence a valgrind uninitialized memory warning. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94955 > Cc: "11.1 11.2"

Re: [Mesa-dev] [PATCH 00/13] Use the constant engine in radeonsi

On Thu, Apr 14, 2016 at 8:29 PM, Nicolai Hähnle wrote: > On 13.04.2016 20:34, Bas Nieuwenhuizen wrote: >> >> This series implements updating descriptors using the constant engine. >> This should result in a 0%-3% improvement for CPU bound applications, >> as we only have to

[Mesa-dev] [PATCH] gallium/util: initialize pipe_framebuffer_state to zeros

To silence a valgrind uninitialized memory warning. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94955 Cc: "11.1 11.2" --- src/gallium/auxiliary/util/u_blitter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

On 15 April 2016 at 16:36, Chuck Atkins wrote: > Instead of cascading support for various different implementations of > GLX, all three options are now specified through the --enable-glx > option: > Bth having the single switch looks a lot cleaner imho. Wondering if one

[Mesa-dev] [PATCH] gallium/swr: allow swr use as a swrast dri driver

--- configure.ac | 3 +++ src/gallium/auxiliary/target-helpers/sw_helper.h | 15 +-- src/gallium/drivers/swr/Automake.inc | 7 +++ src/gallium/targets/dri/Makefile.am | 1 + src/gallium/targets/pipe-loader/Makefile.am

[Mesa-dev] [Bug 94955] Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)

https://bugs.freedesktop.org/show_bug.cgi?id=94955 --- Comment #1 from Brian Paul --- (In reply to David Lonie from comment #0) > Created attachment 122975 [details] > apitrace > > There are some uninitialized variables in current master that are causing > some of the VTK

[Mesa-dev] [RFC] dynamic IB size tuning for radeonsi

Hi, apps that cause a lot of synchronization benefit from small IB sizes. The current IB size is a bit on the large side for this class of apps. On the other hand, if there isn't much synchronization going on, increasing the IB size can slightly improve performance, too. Here's a quick hack that

[Mesa-dev] [PATCH] amdgpu/winsys: adjust IB size based on buffer wait time

Small IBs help to reduce stalls for workloads that require a lot of synchronization. On the other hand, if there is no notable synchronization, we can use a large IB size to slightly improve performance in some cases. This introduces tuning of the IB size based on feedback on the average buffer

Re: [Mesa-dev] [PATCH v2 17/20] radeonsi: do not do two full flushes on every compute dispatch

For all patches that don't contain my Rb except 17: Reviewed-by: Marek Olšák SURFACE_SYNC & ACQUIRE_MEM only wait for VS and PS if any of the BASE_ENA flags are set (according to our closed driver code). They don't wait for CS. Flushing L2 doesn't wait for anything. Marek

Re: [Mesa-dev] [PATCH] gallium/swr: confine c++11 flag to swr driver

On 15 April 2016 at 00:30, Tim Rowley wrote: > --- a/src/gallium/drivers/swr/Makefile.am > +++ b/src/gallium/drivers/swr/Makefile.am > @@ -22,7 +22,7 @@ > include Makefile.sources > include $(top_srcdir)/src/gallium/Automake.inc > > -AM_CXXFLAGS =

[Mesa-dev] [Bug 94955] Uninitialized variables leads to random segfaults (valgrind log, apitrace attached)

https://bugs.freedesktop.org/show_bug.cgi?id=94955 Bug ID: 94955 Summary: Uninitialized variables leads to random segfaults (valgrind log, apitrace attached) Product: Mesa Version: git Hardware: All OS: All

Re: [Mesa-dev] [PATCH 0/2] more Android build fixes

On 14 April 2016 at 20:40, Rob Herring wrote: > A couple more Android build fixes after rebasing to the current tip. > > Android master builds are still a bit broken because makefiles get > processed by kati in a different order. To fix, we need to go thru and > eliminate all the

Re: [Mesa-dev] [PATCH 2/2] i965: add build rule for brw_nir_trig_workarounds.c on Android

On 14 April 2016 at 20:40, Rob Herring wrote: > Commit bfd17c76c126 ("i965: Port INTEL_PRECISE_TRIG=1 to NIR.") added a > generated file brw_nir_trig_workarounds.c which broke the Android build. > Add the necessary makefiles to the Android build. > > Cc: Kenneth Graunke

[Mesa-dev] [Bug 94086] Multiple conflicting libGL libraries installed

https://bugs.freedesktop.org/show_bug.cgi?id=94086 Chuck Atkins changed: What|Removed |Added Attachment #122938|0 |1 is

Re: [Mesa-dev] [PATCH 1/4] gallium/radeon: add clear_texture function

On 2016-04-15 18:38, Ilia Mirkin wrote: + } else { + union pipe_color_union color; + switch (util_format_get_blocksizebits(res->format)) { + case 128: + sf->format = PIPE_FORMAT_R32G32B32A32_UINT; Just as an FYI... this is

Re: [Mesa-dev] [PATCH 1/2] glsl: android: add back missing generated glcpp include path

On 14 April 2016 at 20:40, Rob Herring wrote: > Commit 4db8f15a2576 ("glsl: move the android build scripts a level up") > dropped a generated include path for glcpp. Add it back adjusting for the > new location. > > Cc: Emil Velikov > Signed-off-by:

Re: [Mesa-dev] [PATCH 2/2] configure: Add support for the Intel Vulkan driver

> > > Put x in front of everything: > > > Which reminds me - what are the advantages of it ? In the gallium > drivers (where this is derived from) and I've not seen any issues. > Mostly curious, I'm fine with or without the x. > It prevents empty string problems. If the variable is undefined or

Re: [Mesa-dev] Mesa (master): 29 new commits

Hi, It might also be worth testing the impact of IOMMU L1 on GTT throughput. Set IOMMU_L2INDX:L2_DEBUG_3 bit 31 (at any time) to disable the L1. On 2016-04-14 06:28, Christian König wrote: Yeah, thinking about this since I've seen Michels response this morning. The only major thing which

Re: [Mesa-dev] [PATCH 1/4] gallium/radeon: add clear_texture function

On Fri, Apr 15, 2016 at 12:33 PM, Jakob Sinclair wrote: > This patch adds the needed function for ARB_clear_texture. > The function itself is mostly based on the nouveau implementation. > > Signed-off-by: Jakob Sinclair > --- >

Re: [Mesa-dev] [PATCH 2/2] configure: Add support for the Intel Vulkan driver

On Fri, Apr 15, 2016 at 10:02 AM, Emil Velikov wrote: > On 14 April 2016 at 21:51, Kenneth Graunke wrote: > > On Thursday, April 14, 2016 1:06:25 PM PDT Jason Ekstrand wrote: > >> This adds a --with-vulkan-drivers option with one driver, "intel".

Re: [Mesa-dev] [PATCH 2/2] configure: Add support for the Intel Vulkan driver

On 14 April 2016 at 21:51, Kenneth Graunke wrote: > On Thursday, April 14, 2016 1:06:25 PM PDT Jason Ekstrand wrote: >> This adds a --with-vulkan-drivers option with one driver, "intel". In the >> future, we may add more drivers to this list. >> --- >> configure.ac | 66

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

On 04/15/2016 10:18 AM, Chuck Atkins wrote: The problem this is trying to solve is that they both get installed and create an ambiguous situation for which one get's used: libGL.so -> libGL.so.1.5.0 libGL.so.1 -> libGL.so.1.6.0 libGL.so.1.5.0 libGL.so.1.6.0 I could adjust it so that you can

[Mesa-dev] [PATCH 0/4] Implement ARB_clear_texture for radeon drivers

This series of patches implements ARB_clear_texture for r600 and radeonsi. I only tested this with the radeonsi driver and just assumed it would work on the r600 driver. If someone could test this with the r600 driver it would be wonderful. This implementation was mostly based on the nouveau

Re: [Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

On 04/15/2016 10:22 AM, Ilia Mirkin wrote: On Fri, Apr 15, 2016 at 12:18 PM, Chuck Atkins wrote: The problem this is trying to solve is that they both get installed and create an ambiguous situation for which one get's used: libGL.so -> libGL.so.1.5.0 libGL.so.1 ->

Re: [Mesa-dev] [PATCH 1/4] gallium/radeon: add clear_texture function

On 2016-04-15 18:38, Ilia Mirkin wrote: Just as an FYI... this is safe on nouveau because I control all the internals and know that this is safe to do. Please verify that it's similarly safe to change the surface format after creation on radeon - it might not be. (Esp for compressed

Re: [Mesa-dev] [PATCH 14/17] mesa/st: split the type_size calculation into it's own file

On 04/15/2016 10:30 AM, Rob Clark wrote: On Fri, Apr 15, 2016 at 11:06 AM, Brian Paul wrote: On 04/15/2016 08:49 AM, Rob Clark wrote: From: Rob Clark We'll want to re-use this for NIR. Signed-off-by: Rob Clark

Re: [Mesa-dev] [PATCH 1/4] gallium/radeon: add clear_texture function

On Fri, Apr 15, 2016 at 12:33 PM, Jakob Sinclair wrote: > This patch adds the needed function for ARB_clear_texture. > The function itself is mostly based on the nouveau implementation. > > Signed-off-by: Jakob Sinclair > --- >

[Mesa-dev] [PATCH 3/4] gallium/r600: enable ARB_clear_texture

Signed-off-by: Jakob Sinclair --- src/gallium/drivers/r600/r600_pipe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index c594f5c..7d1d6b2 100644 ---

[Mesa-dev] [PATCH 4/4] docs/GL3.txt: mark ARB_clear_texture as done for r600 and radeonsi

Tested with piglit. All ARB_clear_texture tests passed. Signed-off-by: Jakob Sinclair --- docs/GL3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index dc75cf8..654c856 100644 --- a/docs/GL3.txt +++

[Mesa-dev] [PATCH 1/4] gallium/radeon: add clear_texture function

This patch adds the needed function for ARB_clear_texture. The function itself is mostly based on the nouveau implementation. Signed-off-by: Jakob Sinclair --- src/gallium/drivers/radeon/r600_texture.c | 72 +++ 1 file changed, 72

  1   2   >