Re: [Mesa-dev] [PATCH v3 30/44] i965/fs: Handle nir shared variable store intrinsic

On 2015-12-01 04:45:05, Iago Toral wrote: > On Tue, 2015-12-01 at 00:19 -0800, Jordan Justen wrote: > > Signed-off-by: Jordan Justen > > --- > > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 52 > > > > 1 file changed, 52 insertions(+) >

[Mesa-dev] [PATCH] appveyor: Initial integration.

AppVeyor doesn't require an appveyor.yml in the repos (in fact it has some limitations as noted in comments below), but doing so has two great advantages over the web UI: - appveyor.yml can be revisioned together with the code, so instructions should always be in synch with the code -

[Mesa-dev] [PATCH] nv50/ir: allow immediate 0 to be loaded anywhere

There's a post-RA fixup to replace 0's with $r63 (or $r127 if too many regs are used), so just as nvc0, let an immediate 0 be loaded anywhere. Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 6 ++ 1 file changed, 6

[Mesa-dev] [PATCH 1/2] glapi: update scons for building enums.py

The commit "mesa: Switch to using the Khronos registry for generating enums." updated Makefile.am but no the SConscript file. --- src/mapi/glapi/gen/SConscript | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mapi/glapi/gen/SConscript b/src/mapi/glapi/gen/SConscript index

Re: [Mesa-dev] [PATCH 1/2] glapi: update scons for building enums.py

Brian Paul writes: > The commit "mesa: Switch to using the Khronos registry for generating > enums." updated Makefile.am but no the SConscript file. I just pushed a fix for this and hopefully the Android.mk at the same time. I'm working on a Travis build for scons as

Re: [Mesa-dev] [PATCH 2/2] glapi: work-around MSVC 65K string length limitation for enums.c

Brian Paul writes: > String literals cannot exceed 65535 characters for MSVC. Instead of > emiting a string, emit an array of characters. > --- > src/mapi/glapi/gen/gl_enums.py | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git

Re: [Mesa-dev] [PATCH] travis: Initial import of travis instructions.

On 28/11/15 21:06, Emil Velikov wrote: On 25 November 2015 at 07:20, Jose Fonseca wrote: BTW, I setup Mesa with Appveyor (like Travis for Windows) https://ci.appveyor.com/project/jrfonseca/mesa I'll try to get that going and commited too. As a person who has broken

Re: [Mesa-dev] [PATCH] travis: Add a test build with scons.

On 01/12/15 20:52, Eric Anholt wrote: Since I just broke the scons build, I figured I'd make Travis test that I don't break it again in the future. The script runs the builds in parallel across VMs, so it still takes just 5 minutes to turn around results. --- .travis.yml | 21

[Mesa-dev] Recent enums.c change breaks MSVC

Hi Eric, enums.c no longer compiles on MSVC because the enum_string_table[] string literal is too long. The MSVC limit is 65535 chars. The ugly work-around is to generate an array of characters: LONGSTRING static const char enum_string_table[] = { 'G', 'L', '_', 'N', 'O', '_', 'E', 'R',

[Mesa-dev] [PATCH v2] mesa/version: Update gl_extensions::Version during version override

On Tue, Dec 01, 2015 at 10:44:43AM -0800, Nanley Chery wrote: From: Nanley Chery Commit a16ffb743ced9fde80b2485dfc2d86ae74e86f25, which introduced gl_extensions::Version, updates the field when the context version is computed and when entering/exiting meta. Update this

[Mesa-dev] [PATCH v4] i965/fs: Handle nir shared variable store intrinsic

v4: * Apply similar optimization for shared variable stores as 0cb7d7b4b7c32246d4c4225a1d17d7ff79a7526d. This was causing a OpenGLES 3.1 CTS failure, but 867c436ca841b4196b4dde4786f5086c76b20dd7 fixes that. Signed-off-by: Jordan Justen Cc: Iago Toral Quiroga

Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).

On 12/01/2015 11:28 AM, Ilia Mirkin wrote: > On Tue, Dec 1, 2015 at 2:13 PM, Ian Romanick wrote: >> On 11/30/2015 04:41 PM, Ilia Mirkin wrote: >>> On Mon, Nov 30, 2015 at 7:15 PM, Matt Turner wrote: On Mon, Nov 30, 2015 at 3:51 PM, Ilia Mirkin

Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).

On Tue, Dec 1, 2015 at 4:24 PM, Ian Romanick wrote: >> which ends up in: >> >> EMIT: mov u32 $r4 0x (8) >> EMIT: set u32 $r1 ne $r1 $r4 (8) >> EMIT: set u32 $r2 ne $r2 $r4 (8) >> EMIT: set u32 $r3 ne $r3 $r4 (8) >> EMIT: set u32 $r0 ne $r0 $r4 (8) >> EMIT: or u32 $r1

Re: [Mesa-dev] [PATCH 2/2] glapi: work-around MSVC 65K string length limitation for enums.c

On 12/01/2015 12:04 PM, Brian Paul wrote: > String literals cannot exceed 65535 characters for MSVC. Instead of > emiting a string, emit an array of characters. > --- > src/mapi/glapi/gen/gl_enums.py | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git

[Mesa-dev] [Bug 92757] GL_ARB_sync objects are not properly synchronized across threads

https://bugs.freedesktop.org/show_bug.cgi?id=92757 --- Comment #3 from Steinar H. Gunderson --- Created attachment 120238 --> https://bugs.freedesktop.org/attachment.cgi?id=120238=edit Suggested patch Hi, I think the included patch should resolve the problem. I've run

[Mesa-dev] [Bug 93189] "./util/u_inlines.h", line 83: operands have incompatible types: void ":" int

https://bugs.freedesktop.org/show_bug.cgi?id=93189 --- Comment #6 from Matt Turner --- The point of the ternary magic is to make the macros typeless, like gcc's atomic ops built-ins (https://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html) The problem is that a

[Mesa-dev] [PATCH] travis: Add a test build with scons.

Since I just broke the scons build, I figured I'd make Travis test that I don't break it again in the future. The script runs the builds in parallel across VMs, so it still takes just 5 minutes to turn around results. --- .travis.yml | 21 +++-- 1 file changed, 15 insertions(+),

Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).

On Tue, Dec 1, 2015 at 4:24 PM, Ian Romanick wrote: >> So this is the test I came up with: >> >> FRAG >> DCL IN[0], GENERIC[0], PERSPECTIVE >> DCL OUT[0], COLOR >> DCL TEMP[0..4], LOCAL >> IMM[0] UINT32 { 0, 0, 0, 0 } >> 0: MOV TEMP[0], IN[0] >> 1: USNE TEMP[0], TEMP[0],

[Mesa-dev] [PATCH 2/2] glapi: work-around MSVC 65K string length limitation for enums.c

String literals cannot exceed 65535 characters for MSVC. Instead of emiting a string, emit an array of characters. --- src/mapi/glapi/gen/gl_enums.py | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/mapi/glapi/gen/gl_enums.py b/src/mapi/glapi/gen/gl_enums.py index

Re: [Mesa-dev] [PATCH] mesa: fix VIEWPORT_INDEX_PROVOKING_VERTEX and LAYER_PROVOKING_VERTEX queries

Am 01.12.2015 um 20:35 schrieb Brian Paul: > On 12/01/2015 12:07 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> These are implementation-dependent queries, but so far we just >> returned the >> value of whatever the current provoking vertex convention was set

Re: [Mesa-dev] [PATCH 34/53] r600/eg: workaround bug with tess shader and dynamic GPRs.

On 1 December 2015 at 20:46, Marek Olšák wrote: > Did the alternative workaround (reserving one SIMD as PS only) not work? > Well fglrx was doing this, so I decided to not diverge from that. Dave. ___ mesa-dev mailing list

Re: [Mesa-dev] [PATCH] nv50/ir: allow immediate 0 to be loaded anywhere

Same code as nvc0, looks fine. Reviewed-by: Samuel Pitoiset On 12/01/2015 09:04 PM, Ilia Mirkin wrote: There's a post-RA fixup to replace 0's with $r63 (or $r127 if too many regs are used), so just as nvc0, let an immediate 0 be loaded anywhere. Signed-off-by: Ilia

[Mesa-dev] [PATCH 2/2] Remove Sun CC specific code.

--- include/c99_compat.h | 6 -- src/gallium/auxiliary/util/u_cpu_detect.c | 10 +- src/gallium/include/pipe/p_compiler.h | 6 +- src/gallium/include/pipe/p_config.h | 4 src/glsl/ir_constant_expression.cpp | 8

[Mesa-dev] [PATCH 1/2] configure.ac: Refuse to build with Sun C compiler.

https://bugs.freedesktop.org/show_bug.cgi?id=93189 --- configure.ac | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configure.ac b/configure.ac index 4016871..b6680d0 100644 --- a/configure.ac +++ b/configure.ac @@ -197,6 +197,13 @@ if test "x$GCC" = xyes -a "x$acv_mesa_CLANG" = xno;

[Mesa-dev] [Bug 93189] "./util/u_inlines.h", line 83: operands have incompatible types: void ":" int

https://bugs.freedesktop.org/show_bug.cgi?id=93189 --- Comment #7 from Jose Fonseca --- It doesn't make sense to spend time on supporting platforms for which there are no active developers. Keeping Mesa compiling across GCC and MSVC is already quite time consuming. I

Re: [Mesa-dev] [PATCH v2] nv50/ir: do not call textureMask() for surface ops

On Tue, Dec 1, 2015 at 6:26 PM, Samuel Pitoiset wrote: > While we are it, apply the same change for Tesla. Does tesla even have surface ops? I don't see anything in envydis... Please don't add code that doesn't need to be there. -ilia

Re: [Mesa-dev] [PATCH 5/6] nir: Delete bany, ball, fany, fall.

On Mon, Nov 30, 2015 at 3:32 PM, Matt Turner wrote: > As in the previous patches, these can be implemented as > >any(v) -> any_nequal(v, false) >all(v) -> all_equal(v, true) > > and their removal simplifies the code in the next patch. > --- >

[Mesa-dev] [PATCH] nir: Optimize useless comparisons against true/false.

--- I add the true/false variables for clarity since there are some existing optimizations using ~0 where it actually has nothing to do with true. I could take it or leave it. We obviously can't use them for feq and friends. Maybe itrue/ifalse and ftrue/ffalse? src/glsl/nir/nir_opt_algebraic.py

Re: [Mesa-dev] [PATCH 2/2] Remove Sun CC specific code.

Both look good to me. Thanks. Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH shader-db] Set more env-var's in run.c

Simplify the instructions a bit by setting all the potentially needed environment variables in run.c itself. Made very trivially more complex by the fact that all of the gallium drivers are using u_debug stuff, so one env var contains potentially multiple flags. We don't want to clobber any

Re: [Mesa-dev] [PATCH] nv50/ir: do not call textureMask() for non-texture ops

On 11/29/2015 04:11 PM, Ilia Mirkin wrote: Under what circumstances can you get into this code and not be a texture op? This only happens with surface ops. In this example, it's related to sustp. I don't think we need to add that texture mask for surface ops because we don't do that for

Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).

On 12/01/2015 01:36 PM, Ilia Mirkin wrote: > On Tue, Dec 1, 2015 at 4:24 PM, Ian Romanick wrote: >>> So this is the test I came up with: >>> >>> FRAG >>> DCL IN[0], GENERIC[0], PERSPECTIVE >>> DCL OUT[0], COLOR >>> DCL TEMP[0..4], LOCAL >>> IMM[0] UINT32 { 0, 0, 0, 0 } >>>

Re: [Mesa-dev] [PATCH 1/2] configure.ac: Refuse to build with Sun C compiler.

On 12/ 1/15 03:07 PM, Jose Fonseca wrote: https://bugs.freedesktop.org/show_bug.cgi?id=93189 --- configure.ac | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configure.ac b/configure.ac index 4016871..b6680d0 100644 --- a/configure.ac +++ b/configure.ac @@ -197,6 +197,13 @@ if test

Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).

On Tue, Dec 1, 2015 at 6:17 PM, Ian Romanick wrote: > I think even if we add code to st_glsl_to_tgsi to recognize the > any_nequal(v, false) pattern, it will still be a net reduction on lines > of code. That'd be fine with me. I'm not trying to be difficult... but

Re: [Mesa-dev] [Mesa-stable] [PATCH] glsl: always re-validate program pipeline

On Tue, 2015-12-01 at 13:46 +0200, Tapani Pälli wrote: > On 12/01/2015 02:13 AM, Timothy Arceri wrote: > > Just because the validation passed the last time is was called > > doesn't > > automatically mean it will pass again the next time its called. > > This is a rather large hammer though :/

Re: [Mesa-dev] [PATCH] nv50/ir: do not call textureMask() for non-texture ops

On Tue, Dec 1, 2015 at 6:01 PM, Samuel Pitoiset wrote: > > > On 11/29/2015 04:11 PM, Ilia Mirkin wrote: >> >> Under what circumstances can you get into this code and not be a texture >> op? > > > This only happens with surface ops. In this example, it's related to

Re: [Mesa-dev] [PATCH 1/2] configure.ac: Refuse to build with Sun C compiler.

On Tue, Dec 1, 2015 at 3:07 PM, Jose Fonseca wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=93189 > --- > configure.ac | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/configure.ac b/configure.ac > index 4016871..b6680d0 100644 > --- a/configure.ac >

[Mesa-dev] [PATCH v2] nv50/ir: do not call textureMask() for surface ops

That texture mask thing doesn't seem to be needed for surface ops, so just as nve4+, let do that only for texture ops. This fixes a segfault with 'test_surface_st' from gallium/tests/trivial/compute.c on Fermi because this test uses sustp. While we are it, apply the same change for Tesla.

Re: [Mesa-dev] [PATCH 6/6] i965/vec4: Optimize predicate handling for any/all.

On Tue, Dec 1, 2015 at 11:07 AM, Ian Romanick wrote: > On 11/30/2015 03:32 PM, Matt Turner wrote: >> For a select whose condition is any(v), instead of emitting >> >>cmp.nz.f0(8)null<1>Dg1<0,4,1>D 0D >>mov(8) g7<1>.xUD 0xUD >>

[Mesa-dev] [PATCH] glsl_to_tgsi: Skip useless comparison instructions.

--- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index 7f58b44..89ad6cd 100644 ---

Re: [Mesa-dev] [PATCH] glsl_to_tgsi: Skip useless comparison instructions.

On Tue, Dec 1, 2015 at 8:12 PM, Matt Turner wrote: > --- > src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp >

Re: [Mesa-dev] [PATCH shader-db] Set more env-var's in run.c

On Tue, Dec 1, 2015 at 8:25 PM, Rob Clark wrote: > ST_DEBUG=precompile is defn needed.. otherwise *something* (not sure > if it is core or mesa-st) decides to not compile things yet.. Actually I don't need it for nouveau, and am fairly sure it's not needed for radeonsi. You

Re: [Mesa-dev] [PATCH shader-db] Set more env-var's in run.c

On Tue, Dec 1, 2015 at 8:00 PM, Matt Turner wrote: > On Tue, Dec 1, 2015 at 4:40 PM, Rob Clark wrote: >> Simplify the instructions a bit by setting all the potentially needed >> environment variables in run.c itself. >> >> Made very trivially more complex

[Mesa-dev] [PATCH] nvc0/ir: fold postfactor into immediate

SM20-SM50 can't emit a post-factor in the presence of a long immediate. Make sure to fold it in. Signed-off-by: Ilia Mirkin Cc: "11.0 11.1" --- src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 ++ 1 file changed, 6

Re: [Mesa-dev] [PATCH shader-db] Set more env-var's in run.c

On Tue, Dec 1, 2015 at 4:40 PM, Rob Clark wrote: > Simplify the instructions a bit by setting all the potentially needed > environment variables in run.c itself. > > Made very trivially more complex by the fact that all of the gallium > drivers are using u_debug stuff, so one

Re: [Mesa-dev] [PATCH] glsl_to_tgsi: Skip useless comparison instructions.

On Tue, Dec 1, 2015 at 5:17 PM, Ilia Mirkin wrote: > On Tue, Dec 1, 2015 at 8:12 PM, Matt Turner wrote: >> --- >> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 ++-- >> 1 file changed, 14 insertions(+), 2 deletions(-) >> >> diff --git

Re: [Mesa-dev] [PATCH shader-db] Set more env-var's in run.c

On Tue, Dec 1, 2015 at 8:28 PM, Ilia Mirkin wrote: > On Tue, Dec 1, 2015 at 8:25 PM, Rob Clark wrote: >> ST_DEBUG=precompile is defn needed.. otherwise *something* (not sure >> if it is core or mesa-st) decides to not compile things yet.. > > Actually I

Re: [Mesa-dev] [PATCH] clover: Check the return value of pipe_loader_probe() when probing for devices v2

On 30 November 2015 at 17:50, Tom Stellard wrote: > When probing for devices, clover will call pipe_loader_probe() twice. > The first time to retrieve the number of devices, and then second time > to retrieve the device structures. > > We currently assume that the return

Re: [Mesa-dev] [PATCH 0/3] misc janitorial

On 30 November 2015 at 22:06, Dave Airlie wrote: > On 1 December 2015 at 07:18, Emil Velikov wrote: >> On 30 November 2015 at 20:00, Ian Romanick wrote: >>> On 11/29/2015 07:21 AM, Emil Velikov wrote: Hi Giuseppe,

Re: [Mesa-dev] [PATCH 0.5/5] i965/gen9/fast-clear: Handle linear???SRGB conversion

On Wed, Nov 25, 2015 at 06:23:01PM +0100, Neil Roberts wrote: > If GL_FRAMEBUFFER_SRGB is enabled when writing to an SRGB-capable > framebuffer then the color will be converted from linear to SRGB > before being written. There is no chance for the hardware to do this > itself because it can't

Re: [Mesa-dev] [PATCH v2 5/6] mesa: Update _mesa_has_geometry_shaders

On Tue, Dec 01, 2015 at 04:03:22PM +, Lofstedt, Marta wrote: > > -Original Message- > > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On > > Behalf Of Lofstedt, Marta > > Sent: Tuesday, December 1, 2015 4:48 PM > > To: Emil Velikov; Marta Lofstedt > > Cc: ML mesa-dev >

Re: [Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

On 12/01/2015 10:43 AM, Roland Scheidegger wrote: Trying to fix some draw bugs with layer/vp outputs (and clipping), I was wondering if GL actually guarantees sane results if the layer/vp index isn't the same on all vertices. And sure it seems it does, albeit it's implementation-dependent.

Re: [Mesa-dev] [PATCH 06/12] mesa: Drop apparently typoed GL_ALL_CLIENT_ATTRIB_BITS.

On 11/30/2015 05:50 PM, Ian Romanick wrote: On 11/25/2015 07:10 PM, Eric Anholt wrote: GL_ALL_ATTRIB_BITS is a thing, and GL_CLIENT_ALL_ATTRIB_BITS, but I don't see GL_ALL_CLIENT_ATTRIB_BITS in my grepping of khronos XML, GL extension specs, GL 1.1, GL 2.2, and GL 4.4. Hm... it is in

Re: [Mesa-dev] [PATCH 3/5] i965/gen9: Resolve SRGB color buffers when GL_FRAMEBUFFER_SRGB enabled

On Wed, Nov 25, 2015 at 06:36:37PM +0100, Neil Roberts wrote: > SKL can't cope with the CCS buffer for SRGB buffers. Normally the > hardware won't see the SRGB formats because when GL_FRAMEBUFFER_SRGB > is disabled these get mapped to their linear equivalents. In order to > avoid relying on the

Re: [Mesa-dev] [Mesa-stable] [PATCH] automake: fix some occurrences of hardcoded -ldl and -lpthread

On 23 November 2015 at 03:22, Jonathan Gray wrote: > Correct some occurrences of -ldl and -lpthread to use > $(DLOPEN_LIBS) and $(PTHREAD_LIBS) respectively. > > Signed-off-by: Jonathan Gray > Cc: "11.0 11.1" > --- >

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure.ac: use pkg-config for libelf

Hi Jonathan, On 23 November 2015 at 03:24, Jonathan Gray wrote: > Use PKG_CHECK_MODULES to get the flags to link libelf. > > Signed-off-by: Jonathan Gray > Cc: "11.0 11.1" > --- > configure.ac | 4

Re: [Mesa-dev] [PATCH 0.5/5] i965/gen9/fast-clear: Handle linear???SRGB conversion

"Pohjolainen, Topi" writes: >> + /* Handle linear→SRGB conversion */ >> + if (brw->ctx.Color.sRGBEnabled && >> + _mesa_get_srgb_format_linear(mt->format) != mt->format) { > > Patch five disables fast clear for single-sampled if > brw->ctx.Color.sRGBEnabled

[Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

Trying to fix some draw bugs with layer/vp outputs (and clipping), I was wondering if GL actually guarantees sane results if the layer/vp index isn't the same on all vertices. And sure it seems it does, albeit it's implementation-dependent. Specifically (from gl 4.4 core, page 388) "viewport

Re: [Mesa-dev] [PATCH 0.5/5] i965/gen9/fast-clear: Handle linear???SRGB conversion

On Tue, Dec 01, 2015 at 05:27:19PM +, Neil Roberts wrote: > "Pohjolainen, Topi" writes: > > >> + /* Handle linear???SRGB conversion */ > >> + if (brw->ctx.Color.sRGBEnabled && > >> + _mesa_get_srgb_format_linear(mt->format) != mt->format) { > > > > Patch

Re: [Mesa-dev] [PATCH] i965: Increase BRW_MAX_UBO to 15.

That's interesting. Some d3d10 docs list this indeed as 15+1 (and that +1 is really needed too for the immediates, as you can have indirectly addressed immediates which are little more than ordinary uniforms for the hw). So does d3d11:

Re: [Mesa-dev] [PATCH v3] mesa: Update _mesa_has_geometry_shaders

On Tue, Dec 1, 2015 at 7:49 AM, Marta Lofstedt wrote: > From: Marta Lofstedt > > Updates the _mesa_has_geometry_shaders function to also look > for OpenGL ES 3.1 contexts that has OES_geometry_shader enabled. > --- >

Re: [Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

Irrespective of any spec lawyering you might do, we have some piglit tests which basically assume that things like gl_Layer = foo; gl_Position = ... EmitVertex(); gl_Position = ... EmitVertex(); will always work. I believe this was based on the theory that some applications actually do this,

Re: [Mesa-dev] [PATCH v2 5/6] mesa: Update _mesa_has_geometry_shaders

On Tue, Dec 01, 2015 at 04:41:22PM +, Emil Velikov wrote: > On 1 December 2015 at 16:03, Lofstedt, Marta wrote: > > >> > > - return _mesa_is_desktop_gl(ctx) && ctx->Version >= 32; > >> > > + return (_mesa_is_gles31(ctx) && > >> > > +

[Mesa-dev] [Bug 36651] mesa requires bison and flex to build but configure does not check for them

https://bugs.freedesktop.org/show_bug.cgi?id=36651 Alex Perez changed: What|Removed |Added Status|VERIFIED|REOPENED

[Mesa-dev] [Bug 93203] [softpipe] piglit gl30basic regression

https://bugs.freedesktop.org/show_bug.cgi?id=93203 Bug ID: 93203 Summary: [softpipe] piglit gl30basic regression Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords:

Re: [Mesa-dev] [PATCH shader-db] Set more env-var's in run.c

On Tuesday, December 01, 2015 07:40:54 PM Rob Clark wrote: > Simplify the instructions a bit by setting all the potentially needed > environment variables in run.c itself. > > Made very trivially more complex by the fact that all of the gallium > drivers are using u_debug stuff, so one env var

Re: [Mesa-dev] [PATCH 1/2] configure.ac: Refuse to build with Sun C compiler.

On 01/12/15 23:26, Vinson Lee wrote: On Tue, Dec 1, 2015 at 3:07 PM, Jose Fonseca wrote: https://bugs.freedesktop.org/show_bug.cgi?id=93189 --- configure.ac | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configure.ac b/configure.ac index 4016871..b6680d0

[Mesa-dev] [Bug 93187] Error: ffsll(long long) was previously declared "extern", not "inline".

https://bugs.freedesktop.org/show_bug.cgi?id=93187 Jose Fonseca changed: What|Removed |Added Status|NEW |RESOLVED

[Mesa-dev] [Bug 93188] "nir/nir.h", line 552: Error: Unexpected type name "nir_src" encountered.

https://bugs.freedesktop.org/show_bug.cgi?id=93188 --- Comment #3 from Jose Fonseca --- Though we still might want to avoid non-standard C++ constructs regardless. C++ is not a superset of C99 (though some portions are widely supported), so NIR needs to take care when

[Mesa-dev] [PATCH 1/2] i965: De-duplicate key_debug() function.

This appeared in brw_vs.c and brw_wm.c, should have appeared in brw_gs.c, and was soon going to have to be in brw_tcs.c and brw_tes.c as well. So, instead, move it to a central location (which has to know about both struct brw_context and perf_debug()). Signed-off-by: Kenneth Graunke

[Mesa-dev] [PATCH 2/2] i965: Add INTEL_DEBUG=perf information for GS recompiles.

Surprisingly, this didn't exist at all. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_gs.c | 58 ++ 1 file changed, 58 insertions(+) We could almost certainly clean this up, and I'm not opposed to that, I just wanted

Re: [Mesa-dev] [PATCH v4] i965/fs: Handle nir shared variable store intrinsic

Reviewed-by: Iago Toral Quiroga On Tue, 2015-12-01 at 14:35 -0800, Jordan Justen wrote: > v4: > * Apply similar optimization for shared variable stores as >0cb7d7b4b7c32246d4c4225a1d17d7ff79a7526d. This was causing a >OpenGLES 3.1 CTS failure, but >

[Mesa-dev] [Bug 93189] "./util/u_inlines.h", line 83: operands have incompatible types: void ":" int

https://bugs.freedesktop.org/show_bug.cgi?id=93189 Jose Fonseca changed: What|Removed |Added Status|NEW |RESOLVED

Re: [Mesa-dev] [PATCH 02/10] i965/vec4: Get rid of the nir_inputs array

On Wednesday, November 25, 2015 08:55:54 PM Jason Ekstrand wrote: > It's not really buying us anything at this point. It's just a way of > remapping one offset namespace onto another. We can just use the location > namespace the whole way through. > --- > src/mesa/drivers/dri/i965/brw_nir.c

[Mesa-dev] [Bug 93188] "nir/nir.h", line 552: Error: Unexpected type name "nir_src" encountered.

https://bugs.freedesktop.org/show_bug.cgi?id=93188 Jose Fonseca changed: What|Removed |Added Status|NEW |RESOLVED

[Mesa-dev] [PATCH] glsl: simplifiy interface matching

This makes the code easier to follow, should be more efficient and will make it easier to add matching via explicit locations in a follow up patch. --- src/glsl/link_interface_blocks.cpp | 145 +++-- 1 file changed, 41 insertions(+), 104 deletions(-) diff --git

Re: [Mesa-dev] [PATCH v3 30/44] i965/fs: Handle nir shared variable store intrinsic

On Tue, 2015-12-01 at 13:00 -0800, Jordan Justen wrote: > On 2015-12-01 04:45:05, Iago Toral wrote: > > On Tue, 2015-12-01 at 00:19 -0800, Jordan Justen wrote: > > > Signed-off-by: Jordan Justen > > > --- > > > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 52 > > >

Re: [Mesa-dev] [PATCH] travis: Initial import of travis instructions.

On 02.12.2015 07:06, Jose Fonseca wrote: > On 28/11/15 21:06, Emil Velikov wrote: >> On 25 November 2015 at 07:20, Jose Fonseca wrote: >> >>> BTW, I setup Mesa with Appveyor (like Travis for Windows) >>> >>>https://ci.appveyor.com/project/jrfonseca/mesa >>> >>> I'll try

[Mesa-dev] [PATCH 2/2] nv50/ir: make sure entire graph is reachable

The algorithm expects the entire CFG to be reachable, so make sure that we hit every node. Otherwise we will end up with uninitialized data, memory corruption, etc. Signed-off-by: Ilia Mirkin --- src/gallium/drivers/nouveau/codegen/nv50_ir_ssa.cpp | 1 + 1 file changed, 1

[Mesa-dev] [PATCH 1/2] nv50/ir: deal with loops with no breaks

For example if there are only returns, the break bb will not end up part of the CFG. However there will have been a prebreak already emitted for it, and when hitting the RET that comes after, we will try to insert the current (i.e. break) BB into the graph even though it will be unreachable. This

Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).

On 11/30/2015 03:51 PM, Ilia Mirkin wrote: > On Mon, Nov 30, 2015 at 6:38 PM, Matt Turner wrote: >> On Mon, Nov 30, 2015 at 3:34 PM, Ilia Mirkin wrote: >>> On Mon, Nov 30, 2015 at 6:32 PM, Matt Turner wrote: ---

[Mesa-dev] [Bug 36651] mesa requires bison and flex to build but configure does not check for them

https://bugs.freedesktop.org/show_bug.cgi?id=36651 Emil Velikov changed: What|Removed |Added Status|REOPENED|RESOLVED

[Mesa-dev] [PATCH] mesa: fix VIEWPORT_INDEX_PROVOKING_VERTEX and LAYER_PROVOKING_VERTEX queries

From: Roland Scheidegger These are implementation-dependent queries, but so far we just returned the value of whatever the current provoking vertex convention was set to, which was clearly wrong. Just make this a variable in the context constants like for other things which

Re: [Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

I don't think that will work with draw (can't see why it would), and don't plan on fixing it (at least not now). In d3d10, this of course would work (at least if you emit the layer per prim), because it requires the layer info to be taken from the provoking (first) vertex. But that doesn't seem to

[Mesa-dev] [PATCH] mesa/version: Update gl_extensions::Version during version override

From: Nanley Chery Commit a16ffb743ced9fde80b2485dfc2d86ae74e86f25, which introduced gl_extensions::Version, updates the field when the context version is computed and when entering/exiting meta. Update this field when the version is overridden as well. Cc: Marta

Re: [Mesa-dev] [PATCH v3] glsl: add support for GL_OES_geometry_shader

On 12/01/2015 06:49 AM, Marta Lofstedt wrote: > From: Marta Lofstedt > > This adds glsl support of GL_OES_geometry_shader for > OpenGL ES 3.1. > > Signed-off-by: Marta Lofstedt > --- > src/glsl/builtin_variables.cpp | 25

Re: [Mesa-dev] [PATCH 6/6] i965/vec4: Optimize predicate handling for any/all.

On 11/30/2015 03:32 PM, Matt Turner wrote: > For a select whose condition is any(v), instead of emitting > >cmp.nz.f0(8)null<1>Dg1<0,4,1>D 0D >mov(8) g7<1>.xUD 0xUD >(+f0.any4h) mov(8) g7<1>.xUD0xUD >cmp.nz.f0(8)null<1>D

Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).

On 11/30/2015 04:41 PM, Ilia Mirkin wrote: > On Mon, Nov 30, 2015 at 7:15 PM, Matt Turner wrote: >> On Mon, Nov 30, 2015 at 3:51 PM, Ilia Mirkin wrote: >>> On Mon, Nov 30, 2015 at 6:38 PM, Matt Turner wrote: On Mon, Nov 30, 2015

Re: [Mesa-dev] [PATCH 1/6] glsl: Switch opcode and avail parameters to binop().

The series is Reviewed-by: Ian Romanick Patch 1 could probably land right away, but the others should probably wait until Ilia relaxes his objection. I'd really like to have Ken or Jason also review patch 6. On 11/30/2015 03:32 PM, Matt Turner wrote: > To make it

Re: [Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).

On Tue, Dec 1, 2015 at 2:13 PM, Ian Romanick wrote: > On 11/30/2015 04:41 PM, Ilia Mirkin wrote: >> On Mon, Nov 30, 2015 at 7:15 PM, Matt Turner wrote: >>> On Mon, Nov 30, 2015 at 3:51 PM, Ilia Mirkin wrote: On Mon, Nov 30,

Re: [Mesa-dev] [PATCH 1/5] i965/gen9: Don't disallow fast clear for MSRT formats matching render

s/Don't disallow/Allow/ reads much, much better. The original wording made my head hurt. :) On 11/19/2015 07:25 AM, Neil Roberts wrote: > Previously fast clear was disallowed on Gen9 for MSRTs with the claim > that some formats don't work but we didn't understand why. On further > investigation

Re: [Mesa-dev] [PATCH] mesa: fix VIEWPORT_INDEX_PROVOKING_VERTEX and LAYER_PROVOKING_VERTEX queries

On 12/01/2015 12:07 PM, srol...@vmware.com wrote: From: Roland Scheidegger These are implementation-dependent queries, but so far we just returned the value of whatever the current provoking vertex convention was set to, which was clearly wrong. Just make this a variable in

Re: [Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

Thinking about this, are there really apps out there which get it wrong? piglits can be fixed easily. If some app did that seemingly wrong, it might have been due to the bogus query. That is, if it switched to first provoking vertex convention, then asked for the provoking vertex layer, it would

Re: [Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

As I recall, I wanted to fix the piglits when doing GS or ARB_viewport_array for nv50. I believe Ian shot it down. This was ~1-2 years ago, so I don't remember the specifics. -ilia On Tue, Dec 1, 2015 at 2:37 PM, Roland Scheidegger wrote: > Thinking about this, are there

[Mesa-dev] [Bug 93189] "./util/u_inlines.h", line 83: operands have incompatible types: void ":" int

https://bugs.freedesktop.org/show_bug.cgi?id=93189 --- Comment #5 from Ian Romanick --- (In reply to Jose Fonseca from comment #2) > Vinson, Alan, > > > If Oracle itself has no interest on building Mesa with Solaris Sudio > component, let's save everybody's time by making

Re: [Mesa-dev] [PATCH 0/2] Improve emitted code for copies of large buffer-backed variables

Series Reviewed-by: Jordan Justen On 2015-11-23 04:53:07, Iago Toral Quiroga wrote: > Fixes linking issues when copying large variables backed by buffers (ubos, > ssbos, etc). > In these cases, lower_ubo_reference would split the rhs into loads for all > the elements

Re: [Mesa-dev] [PATCH 07/53] r600: move clip misc and streamout stream updates to a single place

On Mon, Nov 30, 2015 at 8:20 AM, Dave Airlie wrote: > From: Dave Airlie > > This will be updated in a macro later. > > Signed-off-by: Dave Airlie > --- > src/gallium/drivers/r600/r600_state_common.c | 17 +++-- > 1 file

Re: [Mesa-dev] [PATCH 08/53] r600: add SET_NULL_SHADER macro.

On Mon, Nov 30, 2015 at 8:20 AM, Dave Airlie wrote: > From: Dave Airlie > > This is used to set a hw shader to NULL. > > Signed-off-by: Dave Airlie > --- > src/gallium/drivers/r600/r600_state_common.c | 9 +++-- > 1 file changed, 7

Re: [Mesa-dev] [PATCH 09/53] r600: use macros for updating the various stages.

On Mon, Nov 30, 2015 at 8:20 AM, Dave Airlie wrote: > From: Dave Airlie > > These macros will make things easier to see when tess > is added to the mix. > > Signed-off-by: Dave Airlie > --- >

[Mesa-dev] [PATCH v3 02/44] i965: Adjust gen check in can_do_pipelined_register_writes

From: Francisco Jerez Allow for pipelined register writes for gen < 7. v2: * Split from another patch and adjust comment (jljusten) Reviewed-by: Jordan Justen --- src/mesa/drivers/dri/i965/intel_extensions.c | 7 +-- 1 file changed, 5

  1   2   >