Re: [Mesa-dev] [PATCH] radeonsi: don't call of u_prims_for_vertices for patches and rectangles

On 10.12.2015 06:58, Marek Olšák wrote: > From: Marek Olšák > > Both caused a crash due to a division by zero in that function. > This is an alternative fix. > > Cc: 11.0 11.1 > --- > src/gallium/drivers/radeonsi/si_state_draw.c | 14

[Mesa-dev] [PATCH] mesa/shader: return correct attribute location for double matrix arrays

From: Dave Airlie If we have a dmat2[4], then dmat2[0] is at 17, dmat2[1] at 19, dmat2[2] at 21 etc. The old code was returning 17,18,19. I think this code is also wrong for float matricies as well. This partly fixes: GL41-CTS.vertex_attrib_64bit.limits_test ---

[Mesa-dev] [PATCH 06/15] i965/fs: Get rid of the param_size array

--- src/mesa/drivers/dri/i965/brw_fs.cpp | 1 - src/mesa/drivers/dri/i965/brw_fs.h | 2 -- src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 9 - src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 --- 4 files changed, 15 deletions(-) diff --git

[Mesa-dev] [PATCH 08/15] i965/vec4: Use MOV_INDIRECT instead of reladdr for indirect push constants

This commit moves us to an instruction based model rather than a register-based model for indirects. This is more accurate anyway as we have to emit instructions to resolve the reladdr. It's also a lot simpler because it gets rid of the recursive reladdr problem by design. One side-effect of

[Mesa-dev] [PATCH 14/15] i965/fs: Rename demote_pull_constants to lower_constant_loads

--- src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++-- src/mesa/drivers/dri/i965/brw_fs.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index a2ec03e..f3cf129 100644 ---

[Mesa-dev] [PATCH 03/15] i965/fs: Use MOV_INDIRECT for all indirect uniform loads

Instead of using reladdr, this commit changes the FS backend to emit a MOV_INDIRECT whenever we need an indirect uniform load. We also have to rework some of the other bits of the backend to handle this new form of uniform load. The obvious change is that demote_pull_constants now acts more like

[Mesa-dev] [PATCH 01/15] nir: Add another index to load_uniform to specify the range read

--- src/glsl/nir/nir_intrinsics.h | 7 +-- src/glsl/nir/nir_lower_io.c | 5 + 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/src/glsl/nir/nir_intrinsics.h b/src/glsl/nir/nir_intrinsics.h index 63df21e..c329a82 100644 --- a/src/glsl/nir/nir_intrinsics.h +++

[Mesa-dev] [PATCH 11/15] i965/fs: Don't force MASK_DISABLE on INDIRECT_MOV instructions

It should work fine without it and the visitor can set it if it wants. --- src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp index c25da07..d86eee1

[Mesa-dev] [PATCH 13/15] i965/fs: Add support for MOV_INDIRECT on pre-Broadwell hardware

While we're at it, we also add support for the possibility that the indirect is, in fact, a constant. This shouldn't happen in the common case (if it does, that means NIR failed to constant-fold something), but it's possible so we should handle it. --- src/mesa/drivers/dri/i965/brw_fs.cpp

[Mesa-dev] [PATCH 07/15] i965/vec4: Inline get_pull_constant_offset

It's not really doing enough anymore to justify a helper function. --- src/mesa/drivers/dri/i965/brw_vec4.h | 2 -- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 37 ++ 2 files changed, 14 insertions(+), 25 deletions(-) diff --git

[Mesa-dev] [PATCH 02/15] i965/fs: Use UD type for offsets in VARYING_PULL_CONSTANT_LOAD

This is to prevent shader-db regressions from D <-> UD conversions in deref add+mul chains caused by using MOV_INDIRECT. --- src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp

[Mesa-dev] [PATCH 05/15] i965/fs: Stop relying on param_size in assign_constant_locations

Now that we have MOV_INDIRECT opcodes, we have all of the size information we need directly in the opcode. With a little restructuring of the algorithm used in assign_constant_locations we don't need param_size anymore. The big thing to watch out for now, however, is that you can have two ranges

[Mesa-dev] [PATCH 10/15] i965/fs: Add support for doing MOV_INDIRECT on uniforms

--- src/mesa/drivers/dri/i965/brw_fs.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index 9b06ed2..de33c1d 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++

[Mesa-dev] [PATCH 09/15] i965/vec4: Get rid of the uniform_size array

--- src/mesa/drivers/dri/i965/brw_vec4.cpp| 8 src/mesa/drivers/dri/i965/brw_vec4.h | 2 -- src/mesa/drivers/dri/i965/brw_vec4_nir.cpp| 9 - src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp| 11 ---

[Mesa-dev] [PATCH 15/15] i965/fs: Push small uniform arrays

Unfortunately, this also means that we need to use a slightly different algorithm for assign_constant_locations. The old algorithm worked based on the assumption that each read of a uniform value read exactly one float. If it encountered a MOV_INDIRECT, it would immediately bail and push the

[Mesa-dev] [PATCH 12/15] i965/fs: Fix regs_read() for MOV_INDIRECT with a non-zero subnr

The subnr field is in bytes so we don't need to multiply by type_sz. --- src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index de33c1d..9eaf8d0 100644 ---

[Mesa-dev] [PATCH 04/15] i965/fs: Get rid of reladdr

We aren't using it anymore. --- src/mesa/drivers/dri/i965/brw_fs.cpp | 7 +-- src/mesa/drivers/dri/i965/brw_ir_fs.h | 5 + 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index 7cc03c5..786c5fb

[Mesa-dev] [RFC] i965/vec4: Add support for SHADER_OPCODE_MOV_INDIRECT

This is an initial implementation of the MOV_INDIRECT opcode in the vec4 backend. Unfortunately, I haven't had a chance to test it in the wild yet, but I think review would still be good. In particular, the approach I took to handling swizzles. Unfortunately, the only indirect MOV instructions

Re: [Mesa-dev] [PATCH 1/4] winsys/radeon: clear the buffer cache on allocation failure and try again

On 10.12.2015 06:58, Marek Olšák wrote: > From: Marek Olšák The series is Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X

Re: [Mesa-dev] [PATCH v3 05/12] nir/lower_io: Get rid of load/store_foo_indirect

On Tue, Dec 8, 2015 at 6:25 PM, Kenneth Graunke wrote: > On Tuesday, December 08, 2015 01:46:22 PM Jason Ekstrand wrote: >> diff --git a/src/glsl/nir/nir_lower_io.c b/src/glsl/nir/nir_lower_io.c >> index f64ac69..a2723d5 100644 >> --- a/src/glsl/nir/nir_lower_io.c >> +++

Re: [Mesa-dev] [PATCH] mesa/shader: return correct attribute location for double matrix arrays

On Thu, 2015-12-10 at 13:41 +1000, Dave Airlie wrote: > From: Dave Airlie > > If we have a dmat2[4], then dmat2[0] is at 17, dmat2[1] at 19, > dmat2[2] at 21 etc. The old code was returning 17,18,19. > > I think this code is also wrong for float matricies as well. Would be

Re: [Mesa-dev] [PATCH] mesa/shader: return correct attribute location for double matrix arrays

On 12/10/2015 05:41 AM, Dave Airlie wrote: From: Dave Airlie If we have a dmat2[4], then dmat2[0] is at 17, dmat2[1] at 19, dmat2[2] at 21 etc. The old code was returning 17,18,19. I think this code is also wrong for float matricies as well. This partly fixes:

[Mesa-dev] [PATCH 00/15] i965: Rework uniform handling in the back-end

This series is kind-of two series in one. First, we rework the way we do uniform handling all throughout both backends. In particular, we stop using reladdr and, instead, start using MOV_INDIRECT. Doing this allows us some nice simplifications: First, we no longer have the recursive reladdr

Re: [Mesa-dev] [RFC] i965/vec4: Add support for SHADER_OPCODE_MOV_INDIRECT

On Wed, Dec 9, 2015 at 9:36 PM, Jason Ekstrand wrote: > This is an initial implementation of the MOV_INDIRECT opcode in the vec4 > backend. Unfortunately, I haven't had a chance to test it in the wild yet, > but I think review would still be good. In particular, the

Re: [Mesa-dev] [PATCH] radeonsi: also print hexadecimal values for register fields in the IB parser

On 10.12.2015 07:54, Marek Olšák wrote: > From: Marek Olšák > > --- > src/gallium/drivers/radeonsi/si_debug.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/src/gallium/drivers/radeonsi/si_debug.c >

[Mesa-dev] [PATCH] draw: fix clipping with linear interpolated values and gl_ClipVertex

From: Roland Scheidegger Discovered this when working on other clip code, apparently didn't work correctly - the combination of linear interpolated values and using gl_ClipVertex produced wrong values (failing all such combinations in piglits glsl-1.30 interpolation tests).

Re: [Mesa-dev] [RFC PATCH 5/5] i965: Skip execution size adjustment for instructions of width 4

On Wed, 2015-12-09 at 08:10 -0800, Jason Ekstrand wrote: > > On Dec 9, 2015 4:16 AM, "Iago Toral Quiroga" > wrote: > > > > This code in brw_set_dest adjusts the execution size of any > instruction > > with a dst.width < 8. However, we don't want to do this with > instructions

Re: [Mesa-dev] [RFC PATCH 5/5] i965: Skip execution size adjustment for instructions of width 4

On Dec 9, 2015 11:47 PM, "Iago Toral" wrote: > > On Wed, 2015-12-09 at 08:10 -0800, Jason Ekstrand wrote: > > > > On Dec 9, 2015 4:16 AM, "Iago Toral Quiroga" > > wrote: > > > > > > This code in brw_set_dest adjusts the execution size of any > > instruction

Re: [Mesa-dev] [PATCH 3/5] i965: Check base format to determine whether to use tiled memcpy

Reviewed-by: Jason Ekstrand On Thu, Nov 19, 2015 at 7:25 AM, Neil Roberts wrote: > The tiled memcpy doesn't work for copying from RGBX to RGBA because it > doesn't override the alpha component to 1.0. Commit 2cebaac479d4 added > a check to disable

Re: [Mesa-dev] [PATCH 3/8] glsl: use dual slot helper in the linker code.

On 9 December 2015 at 21:39, Timothy Arceri wrote: > On Wed, 2015-12-09 at 16:06 +1000, Dave Airlie wrote: >> From: Dave Airlie >> >> Signed-off-by: Dave Airlie > > Great timing :) I was going to have to look into fixing this stuff

<    1   2