Re: [Mesa-dev] [PATCH] glsl: properly setting var-data.binding if explicit_binding is true

On 26/04/15 00:08, Timothy Arceri wrote: On Sat, 2015-04-25 at 18:46 +0200, Alejandro Piñeiro wrote: There was a typo on commit c0cd5b, doing it when explicit_binding was false. This prevented to use any binding point different to 0. --- Taking into account the explanation on the header

[Mesa-dev] [PATCH] glsl: properly setting var-data.binding if explicit_binding is true

There was a typo on commit c0cd5b, doing it when explicit_binding was false. This prevented to use any binding point different to 0. --- Taking into account the explanation on the header about the variable binding (ast.h:553) /** * Binding specified via GL_ARB_shading_language_420pack's

Re: [Mesa-dev] [PATCH v2] glsl: properly setting var-data.binding if explicit_binding is true

On 30/04/15 03:15, Timothy Arceri wrote: On Tue, 2015-04-28 at 10:07 +0200, Alejandro Piñeiro wrote: There was a typo on commit c0cd5b, doing it when explicit_binding was false. This prevented to use any binding point different to 0. Cc: 10.4, 10.5 mesa-sta...@lists.freedesktop.org

[Mesa-dev] [PATCH v2] glsl: properly setting var-data.binding if explicit_binding is true

There was a typo on commit c0cd5b, doing it when explicit_binding was false. This prevented to use any binding point different to 0. Cc: 10.4, 10.5 mesa-sta...@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90175 --- Piglit test to catch this error proposed here:

[Mesa-dev] [PATCH] glsl: set the binding value regardless explicit_binding

Since commit c0cd5b var-data.binding was set only when explicit_binding was false, thas was wrong, should be a test to true. This prevented to use any binding point different to 0. In any case, that if statement is not needed. Right now mesa requires all atomic counters to have an explicit

Re: [Mesa-dev] [PATCH v3] glsl: set the binding value regardless explicit_binding

Sorry, forgot to include the version number of the patch. On 11/05/15 12:37, Alejandro Piñeiro wrote: Since commit c0cd5b var-data.binding was set only when explicit_binding was false, thas was wrong, should be a test to true. This prevented to use any binding point different to 0. In any

Re: [Mesa-dev] [PATCH] glsl: set the binding value regardless explicit_binding

On 14/05/15 13:40, Timothy Arceri wrote: On Wed, 2015-05-13 at 09:58 -0700, Ian Romanick wrote: On 05/11/2015 03:37 AM, Alejandro Piñeiro wrote: Since commit c0cd5b var-data.binding was set only when explicit_binding was false, thas was wrong, should be a test to true. This prevented to use

Re: [Mesa-dev] [PATCH] glsl: set the binding value regardless explicit_binding

On 14/05/15 20:38, Ian Romanick wrote: On 05/14/2015 04:30 AM, Timothy Arceri wrote: On Wed, 2015-05-13 at 09:58 -0700, Ian Romanick wrote: On 05/11/2015 03:37 AM, Alejandro Piñeiro wrote: Since commit c0cd5b var-data.binding was set only when explicit_binding was false, thas was wrong

Re: [Mesa-dev] [PATCH v3] glsl: set the binding value regardless explicit_binding

On 12/05/15 23:17, Timothy Arceri wrote: On Mon, 2015-05-11 at 12:37 +0200, Alejandro Piñeiro wrote: Since commit c0cd5b var-data.binding was set only when explicit_binding was false, thas was wrong, should be a test to true. This prevented to use any binding point different to 0. In any

Re: [Mesa-dev] [Mesa-stable] [PATCH] glsl: set the binding value regardless explicit_binding

On 03/06/15 13:17, Emil Velikov wrote: Hello gents, On 21 May 2015 at 14:03, Timothy Arceri t_arc...@yahoo.com.au wrote: On Thu, 2015-05-21 at 12:22 +0200, Alejandro Piñeiro wrote: On 20/05/15 23:39, Timothy Arceri wrote: On Thu, 2015-05-14 at 22:49 +0200, Alejandro Piñeiro wrote: On 14

Re: [Mesa-dev] [PATCH 08/78] i965/nir/vec4: Add setup for system values

On 30/06/15 01:34, Jason Ekstrand wrote: On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev el...@igalia.com wrote: From: Alejandro Piñeiro apinhe...@igalia.com Similar to other variable setups, system values will initialize the corresponding register inside a 'nir_system_values' map

Re: [Mesa-dev] [PATCH 61/78] i965/nir/vec4: Add skeleton implementation of nir_emit_texture()

, Jun 26, 2015 at 1:07 AM, Eduardo Lima Mitev el...@igalia.com wrote: From: Alejandro Piñeiro apinhe...@igalia.com This sets up the basic structure and placeholders for the implementation of texture operations, which will be added incrementally in subsequent patches. Apart from helping split

Re: [Mesa-dev] [Mesa-stable] [PATCH] glsl: set the binding value regardless explicit_binding

On 20/05/15 23:39, Timothy Arceri wrote: On Thu, 2015-05-14 at 22:49 +0200, Alejandro Piñeiro wrote: On 14/05/15 20:38, Ian Romanick wrote: I think I see what's happening. I don't think I understood atomic.buffer_index well enough when I removed it. :( In binding=3 case, what value does

[Mesa-dev] [PATCH] i965/nir/fs: removed unneeded support for global variables

As functions are inlined, and nir_lower_global_vars_to_local gets run, all global variables are lowered to local variables. --- Jason Enkstrand already confirmed that global support is not needed on the bug open for the nir/vec4 support: https://bugs.freedesktop.org/show_bug.cgi?id=89580#c9 So

Re: [Mesa-dev] [PATCH 07/78] i965/vec4: Overload make_reg_for_system_value() to allow reuse in NIR-vec4 pass

On 30/06/15 01:27, Jason Ekstrand wrote: On Fri, Jun 26, 2015 at 1:06 AM, Eduardo Lima Mitev el...@igalia.com wrote: From: Alejandro Piñeiro apinhe...@igalia.com The new virtual method is more flexible, it has a signature: dst_reg *make_reg_for_system_value(int location, const glsl_type

Re: [Mesa-dev] [PATCH v3 66/78] i965/nir/vec4: Add implementation of nir_emit_texture()

On 28/07/15 23:49, Jason Ekstrand wrote: On Mon, Jul 27, 2015 at 3:37 PM, Alejandro Piñeiro apinhe...@igalia.com wrote: Uses the nir structure to get all the info needed (sources, dest reg, etc), and then it uses the common vec4_visitor::emit_texture to emit the final code. --- v3

[Mesa-dev] [PATCH v3 65/78] i965/ir/vec4: Refactor visit(ir_texture *ir)

Splitted in two. The emission is moved to a new vec4_visitor method, vec4_visitor::emit_texture, ir order to be reused on the nir path. --- v3: removed shadow_compare and has_nonconstant_offset booleans, as pointed on the v2 review. src/mesa/drivers/dri/i965/brw_vec4.h | 14 +

[Mesa-dev] [PATCH v3 66/78] i965/nir/vec4: Add implementation of nir_emit_texture()

Uses the nir structure to get all the info needed (sources, dest reg, etc), and then it uses the common vec4_visitor::emit_texture to emit the final code. --- v3: added glsl_type_for_nir_alu_type helper as suggested (it could be reused on fs too in the future). Setting with more detail the number

[Mesa-dev] Atomic counters doesn't work for a binding point different to zero (was Re: [PATCH] glsl: set the binding value regardless explicit_binding)

/nir_lower_atomics.c#L65 [2] https://github.com/Igalia/mesa/blob/master/src/glsl/nir/glsl_to_nir.cpp#L330 -- Alejandro Piñeiro (apinhe...@igalia.com) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2] glsl: fix atomic buffer index for bindings other than 0

in the unused var-data.index to avoid the extra memory of putting back the atmoic buffer index field. V2: store buffer index in var-data.index and uniform slot in var-data.location to avoid issues when linking more than 2 shaders. Also some small tidy ups. Cc: Alejandro Piñeiro apinhe...@igalia.com

Re: [Mesa-dev] [PATCH 61/78] i965/nir/vec4: Add skeleton implementation of nir_emit_texture()

/glsl_types.h) have. BR [1] https://github.com/Igalia/mesa/commit/e81ce150ef931e50b6cb1aae0b42a79f448863f5 [2] https://bugs.freedesktop.org/show_bug.cgi?id=89580#c7 --Jason On Fri, Jun 26, 2015 at 1:07 AM, Eduardo Lima Mitev el...@igalia.com wrote: From: Alejandro Piñeiro apinhe...@igalia.com

Re: [Mesa-dev] [PATCH 61/78] i965/nir/vec4: Add skeleton implementation of nir_emit_texture()

On 13/07/15 14:05, Jason Ekstrand wrote: On Mon, Jul 13, 2015 at 3:00 AM, Alejandro Piñeiro apinhe...@igalia.com wrote: On 01/07/15 01:37, Jason Ekstrand wrote: If we can avoid duplication in the texturing code, that would be really nice. Could we do this as a refactor of the old code

Re: [Mesa-dev] [PATCH] i965/nir/fs: removed unneeded support for global variables

Ping. Any possibility of a patch review? FWIW, the patch itself is pretty small. On 26/06/15 13:47, Alejandro Piñeiro wrote: As functions are inlined, and nir_lower_global_vars_to_local gets run, all global variables are lowered to local variables. --- Jason Enkstrand already confirmed

Re: [Mesa-dev] [PATCH 61/78] i965/nir/vec4: Add skeleton implementation of nir_emit_texture()

of the helper function and the cpp renaming. That sounds ok or should we go on independently of Francisco's work? BR -- Alejandro Piñeiro (apinhe...@igalia.com) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman

Re: [Mesa-dev] [PATCH] i965/vec4: check opcode on vec4_instruction::reads_flag(channel)

On 23/10/15 17:46, Kenneth Graunke wrote: > On Friday, October 23, 2015 04:04:35 PM Alejandro Piñeiro wrote: >> Commit f17b78 added an alternative reads_flag(channel) that returned >> if the instruction was reading a specific channel flag. By mistake it >> only took into

[Mesa-dev] [PATCH] i965/vec4: check opcode on vec4_instruction::reads_flag(channel)

Commit f17b78 added an alternative reads_flag(channel) that returned if the instruction was reading a specific channel flag. By mistake it only took into account the predicate, but when the opcode is VS_OPCODE_UNPACK_FLAGS_SIMD4X2 there isn't any predicate, but the flag are used. That mistake

[Mesa-dev] [PATCH] i965: check inst->predicate when clearing flag_live at dead code eliminate

Detected by Matt Turner while reviewing commit a59359ecd22154cc2b3f88bb8c599f21af8a3934 --- src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 2 +- src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [PATCH] i965/vec4: select predicate based on writemask for sel emissions

Equivalent to commit 4eebeb but with sel operations. In this case we select the PredCtrl based on the writemask. This change allows cmod propagation to optimize out several instructions. Shader-db numbers: total instructions in shared programs: 6235835 -> 6228008 (-0.13%) instructions in

Re: [Mesa-dev] Patchwork admin rights

>> >> Thanks, >> >> Sam > Done -- I updated your permissions, along with Antia and Iago. > > I looked for Alejandro and Eduardo, but I couldn't find accounts for them. Just created an account now. Didn't need it yet, but probably it would be good to create an account

Re: [Mesa-dev] [PATCH] i965/vec4: select predicate based on writemask for sel emissions

On 04/11/15 20:13, Matt Turner wrote: > On Fri, Oct 23, 2015 at 7:17 AM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> Equivalent to commit 4eebeb but with sel operations. In this case > That commit sha doesn't exist. I suspect you meant commit 8ac3b525c. Y

Re: [Mesa-dev] [PATCH] i965/vec4: select predicate based on writemask for sel emissions

On 04/11/15 23:49, Matt Turner wrote: > On Wed, Nov 4, 2015 at 1:01 PM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> On 04/11/15 20:13, Matt Turner wrote: >>> On Fri, Oct 23, 2015 at 7:17 AM, Alejandro Piñeiro <apinhe...@igalia.com> >>&g

Re: [Mesa-dev] [PATCH] i965/vec4: select predicate based on writemask for sel emissions

Gentle ping. PS: I also pinged Matt about this, but (again) probably Friday evening is not the best time for reminders ;) On 23/10/15 16:17, Alejandro Piñeiro wrote: > Equivalent to commit 4eebeb but with sel operations. In this case > we select the PredCtrl based on the wri

Re: [Mesa-dev] [PATCH] i965: check inst->predicate when clearing flag_live at dead code eliminate

Gentle ping. FWIW, this patch is a really small one. PS: I already pinged Matt about this, but probably Friday evening is not the best time for reminders ;) On 22/10/15 22:25, Alejandro Piñeiro wrote: > Detected by Matt Turner while reviewing commit > a59359ecd22154cc2b3f88bb8c599f21af

Re: [Mesa-dev] [PATCH 2/5] i965/vec4: adding vec4_cmod_propagation optimization

On 13/10/15 23:36, Matt Turner wrote: > On Tue, Oct 13, 2015 at 1:49 AM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> On 13/10/15 03:10, Matt Turner wrote: >>> Looks like this is causing an intermittent failure on HSW in our >>> Jenkins system (b

Re: [Mesa-dev] [PATCH] i965/vec4: dead_code_eliminate: update writemask on null_regs based on flag_live

On 15/10/15 14:38, Francisco Jerez wrote: > Alejandro Piñeiro <apinhe...@igalia.com> writes: > >> --- >> >> This patch implements the idea proposed by Francisco Jerez. With this >> change, even adding the new condition pointed by Matt Turner on the >> &q

[Mesa-dev] [PATCH v2] i965/vec4: Add unit tests for cmod propagation pass

This include the same tests coming from test_fs_cmod_propagation, (non vector glsl types included) plus some new with vec4 types, inspired on the regressions found while the optimization was a work in progress. Additionally, the check of number of instructions after the optimization was changed

[Mesa-dev] [PATCH] i965/vec4: dead_code_eliminate: update writemask on null_regs based on flag_live

--- This patch implements the idea proposed by Francisco Jerez. With this change, even adding the new condition pointed by Matt Turner on the "2/5 i965/vec4: adding vec4_cmod_propagation optimization", the shader-db numbers remain the same. So this patch would go before the optimization (so in

Re: [Mesa-dev] [PATCH 0/5] Implementation of vec4 equivalent to fs_cmod_propagation optimization

On 15/10/15 18:19, Matt Turner wrote: > On Sat, Oct 10, 2015 at 4:24 AM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> This series implements a vec4 equivalent to fs_cmod_propagation optimization. >> >> The last two commits are not really needed for the

[Mesa-dev] [PATCH v2] i965/vec4: track and use independently each flag channel

vec4_live_variables tracks now each flag channel independently, so vec4_dead_code_eliminate can update the writemask of null registers, based on which component are alive at the moment. This would allow vec4_cmod_propagation to optimize out several movs involving null registers. v2: added support

Re: [Mesa-dev] [PATCH 2/5] i965/vec4: adding vec4_cmod_propagation optimization

On 14/10/15 10:15, Francisco Jerez wrote: > Alejandro Piñeiro <apinhe...@igalia.com> writes: > >> On 13/10/15 23:36, Matt Turner wrote: >>> On Tue, Oct 13, 2015 at 1:49 AM, Alejandro Piñeiro <apinhe...@igalia.com> >>> wrote: >>>>

Re: [Mesa-dev] [PATCH v2] i965/vec4: track and use independently each flag channel

Just realized that I sent this email with extra comments off-list. Sending to the list now. Additionally, just a gentle reminder that this is the only patch pending to be reviewed in this series, that have already 5 patches reviewed. Thanks in advance. On 19/10/15 19:38, Alejandro Piñeiro wrote

Re: [Mesa-dev] [PATCH 2/5] i965/vec4: adding vec4_cmod_propagation optimization

On 10/10/15 16:54, Jason Ekstrand wrote: > On Sat, Oct 10, 2015 at 4:24 AM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> vec4 port of fs_cmod_propagation. >> >> Shader-db results: >> total instructions in shared programs: 6241226 -> 6224469 (-0.27

Re: [Mesa-dev] [PATCH 2/5] i965/vec4: adding vec4_cmod_propagation optimization

On 13/10/15 03:10, Matt Turner wrote: > On Mon, Oct 12, 2015 at 4:25 PM, Matt Turner <matts...@gmail.com> wrote: >> On Sat, Oct 10, 2015 at 4:24 AM, Alejandro Piñeiro <apinhe...@igalia.com> >> wrote: >>> vec4 port of fs_cmod_propagation. >>>

[Mesa-dev] [PATCH 0/5] Implementation of vec4 equivalent to fs_cmod_propagation optimization

This series implements a vec4 equivalent to fs_cmod_propagation optimization. The last two commits are not really needed for the optimization, are just nice-to-have (imho) that I added while implementing the optimization. Alejandro Piñeiro (5): i965/vec4: nir_emit_if doesn't need to predicate

[Mesa-dev] [PATCH 3/5] i965/vec4: Add unit tests for cmod propagation pass.

T, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + * Authors: + * Alejandro Piñeiro Iglesias <apinhe...@igalia.com> + * + * Based on test_fs_cmod_propagation.cpp + */ + +#include +#include "brw_vec4.h

[Mesa-dev] [PATCH 4/5] i965/vec4: use a custom envvar to decide to print the assembly on test_vec4_cmod_propagation

The complete way to do this would be parse INTEL_DEBUG and print the output if DEBUG_VS (or a new one) is present (see intel_debug.c). But that seems like an overkill for the unit tests, that after all, the most common use case is being run when calling make check. --- Just added the envvar

[Mesa-dev] [PATCH 2/5] i965/vec4: adding vec4_cmod_propagation optimization

* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + * Authors: + *Alejandro Piñeiro Iglesias <apinhe...@igalia.com> + * + * Based on brw_fs_cmod_propagation.cpp + */ + +/** @file brw_vec4_cmod_propagation.cpp + * + * Really similar to

[Mesa-dev] [PATCH 5/5] i965/vec4: print predicate control at brw_vec4 dump_instruction

--- I found this useful while I was using INTEL_DEBUG=optimizer after changing how the ifs are emitted. And after all, that info is also included by brw_disasm.c I assumed that at the vec4_visitor we would not need to handle pred_ctrl_align1, but Im not totally sure.

[Mesa-dev] [PATCH 1/5] i965/vec4: nir_emit_if doesn't need to predicate based on all the channels

--- I already talked about this with Jason Ekstrand and Matt Turner privately, but just in case somebody else jump to the review: When using BRW_PREDICATE_NORMAL, the if will use all the channels of the register flag. But nir_if only reads from one channel, so that is not needed. Another hint

[Mesa-dev] [PATCH] i965/nir/vec4: removed unneeded tex src swizzle set

At that point the swizzle should be correct. --- First versions of commit 19cf9 included some manual swizzle assignment that got removed after review [1], as get_nir_src with the right number of components should set a proper swizzle on most of the cases. This one was overlooked. [1]

[Mesa-dev] [PATCH] i965/vec4: fill src_reg type using the constructor type parameter

The src_reg constructor that received the glsl_type was using it only to build the swizzle, but not to fill this->type as dst_reg is doing. This caused some type mismatch between movs and alu operations on the NIR path, so copy propagation optimization was not applied to remove unneeded movs if

Re: [Mesa-dev] [PATCH v2 3/3] glsl/cs: Initialize gl_GlobalInvocationID in main()

lete state->symbols; > ralloc_free(state); > } > diff --git a/src/glsl/ir.h b/src/glsl/ir.h > index 750321e..4c88144 100644 > --- a/src/glsl/ir.h > +++ b/src/glsl/ir.h > @@ -2513,6 +2513,9 @@ _mesa_glsl_initialize_variables(exec_list *instructions, > struct _mesa_glsl_parse_state *state); > > extern void > +_mesa_glsl_initialize_derived_variables(gl_shader *shader); > + > +extern void > _mesa_glsl_initialize_functions(_mesa_glsl_parse_state *state); > > extern void -- Alejandro Piñeiro (apinhe...@igalia.com) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/nir/vec4: fill the type of the dst and src when loading an uniform

On 16/09/15 01:39, Jason Ekstrand wrote: > On Tue, Sep 15, 2015 at 3:23 PM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> Until know, nir_intrinsic_load_uniform was using a default type. This > "now" >> caused some type mismatch bet

[Mesa-dev] [PATCH] i965/nir/vec4: fill the type of the dst and src when loading an uniform

Until know, nir_intrinsic_load_uniform was using a default type. This caused some type mismatch between movs and alu operations, so copy propagation optimization was not applied to remove unneeded movs if negate modifier was involved. This was first detected on minus (negate+add) operations with

[Mesa-dev] [PATCH] i965/vec4: check writemask when bailing out at register coalesce

opt_register_coalesce stopped to check previous instructions to coalesce with if somebody else was writing on the same destination. This can be optimized to check if somebody else was writing to the same channels of the same destination using the writemask. Shader DB results (taking into account

[Mesa-dev] [PATCH 1/2] i965/vec4: Change types as needed to propagate source modifiers using current instruction

SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to

[Mesa-dev] [PATCH 2/2] i965/vec4: Change types as needed to propagate source modifiers using from instruction

SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to

[Mesa-dev] [PATCH 0/2] i965/vec4: Change SEL and MOV types as needed to propagate source modifiers

0 [1] http://lists.freedesktop.org/archives/mesa-dev/2015-September/094555.html Alejandro Piñeiro (2): i965/vec4: Change types as needed to propagate source modifiers using current instruction i965/vec4: Change types as needed to propagate source modifiers using from instruction .../

[Mesa-dev] [PATCH 2/2] i965/vec4: Change types as needed to propagate source modifiers using from instruction

SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to

[Mesa-dev] [PATCH 1/2] i965/vec4: Change types as needed to propagate source modifiers using current instruction

SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to

[Mesa-dev] [PATCH v2] i965/vec4: check writemask when bailing out at register coalesce

opt_register_coalesce stopped to check previous instructions to coalesce with if somebody else was writing on the same destination. This can be optimized to check if somebody else was writing to the same channels of the same destination using the writemask. Shader DB results (taking into account

Re: [Mesa-dev] [PATCH] i965/vec4: fill src_reg type using the constructor type parameter

Christoph Brill suggested to CC stable on this patch. On 01/09/15 19:53, Matt Turner wrote: > On Tue, Sep 1, 2015 at 8:02 AM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> The src_reg constructor that received the glsl_type was using it >> only to build the

[Mesa-dev] [PATCH] docs: document INTEL_DEBUG 'optimizer' envvar

--- I didn't see any kind (ie: alphabetical) order on that list, so I just added it to the end. docs/envvars.html | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/envvars.html b/docs/envvars.html index c0d5a51..168e846 100644 --- a/docs/envvars.html +++ b/docs/envvars.html @@ -153,6

[Mesa-dev] [PATCH] i965/vec4: copy abs/negate modifiers on src/dst_reg conversion constructors

--- src/mesa/drivers/dri/i965/brw_vec4.cpp | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp b/src/mesa/drivers/dri/i965/brw_vec4.cpp index c61b385..121e698 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp +++

Re: [Mesa-dev] [PATCH] i965/vec4: copy abs/negate modifiers on src/dst_reg conversion constructors

src_reg(dest); tmp.negate = true; bld.CMP(bld.null_reg_f(), tmp, zero, BRW_CONDITIONAL_GE); So I think that it would be better to forget this patch. Sorry for the noise. > Matt? > --Jason > > On Wed, Sep 30, 2015 at 10:32 AM, Alejandro Piñeiro > <apinhe...@igalia.co

Re: [Mesa-dev] i965/vec4 (nir): Plan to implement cmod_propagation on vec4

On 28/09/15 17:05, Jason Ekstrand wrote: > > > On Sep 28, 2015 2:09 AM, "Alejandro Piñeiro" <apinhe...@igalia.com > <mailto:apinhe...@igalia.com>> wrote: > > > > Hi, > > > > TL;DR: > > > > as there are several people w

Re: [Mesa-dev] [PATCH 1/4] i965: Don't print line numbers with INTEL_DEBUG=optimizer.

Not sure if this series in general was discarded after Matt's second email on "Add a pass to predicate short blocks", but in any case, I find this specific patch useful and LGTM. Just in case you were expecting for someone taking a look to it: Reviewed-by: Alejandro Piñeiro <apinhe.

[Mesa-dev] i965/vec4 (nir): Plan to implement cmod_propagation on vec4

months ago, and I found this email [1], where he suggest to implement that pass. So just in case someone else was already doing that, Im sending this email. BR [1] http://lists.freedesktop.org/archives/mesa-dev/2015-August/090624.html -- Alejandro Piñeiro (apinhe...@igalia.com

Re: [Mesa-dev] [PATCH v3] i965/vec4: Change types as needed to propagate source modifiers using from instruction

On 19/09/15 16:34, Jason Ekstrand wrote: > > > On Sep 18, 2015 10:12 AM, "Alejandro Piñeiro" <apinhe...@igalia.com > <mailto:apinhe...@igalia.com>> wrote: > > > > SEL and MOV instructions, as long as they don't have source > modifiers,

[Mesa-dev] [PATCH v4] i965/vec4: Change types as needed to propagate source modifiers using from instruction

MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer MOV instructions whenever it doesn't know what else to generate. This

[Mesa-dev] [RFC v1] i965/vec4: add a swizzle check on the uniform bail condition

Without this commit, an uniform is bailed out if the instruction has 3 sources. This commit allow to go on if the combined swizzle is a single value. WIP: it can be clearly cleaned, as the condition is somewhat ugly right now. Shader-db results for vec4 programs on Haswell: total

[Mesa-dev] [PATCH v3] i965/vec4: check swizzle before discarding a uniform on a 3src operand

Without this commit, copy propagation is discarded if it involves a uniform with an instruction that has 3 sources. But 3 sourced instructions can access scalar values. For example, this is what vec4_visitor::fix_3src_operand() is already doing: if (src.file == UNIFORM &&

Re: [Mesa-dev] [PATCH v5] i965/vec4: refactor brw_vec4_copy_propagation.

On 22/09/15 18:09, Jason Ekstrand wrote: > On Tue, Sep 22, 2015 at 8:06 AM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> Now it is more similar to brw_fs_copy_propagation, with three >> clear stages: >> >> 1) Build up the value we are propagating as

Re: [Mesa-dev] [PATCH v5] i965/vec4: refactor brw_vec4_copy_propagation.

On 22/09/15 19:27, Jason Ekstrand wrote: > On Tue, Sep 22, 2015 at 9:17 AM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> >> On 22/09/15 18:09, Jason Ekstrand wrote: >>> On Tue, Sep 22, 2015 at 8:06 AM, Alejandro Piñeiro <apinhe...@igalia.com>

[Mesa-dev] [PATCH v4] i965/vec4: check swizzle before discarding a uniform on a 3src operand

Without this commit, copy propagation is discarded if it involves a uniform with an instruction that has 3 sources. But 3 sourced instructions can access scalar values. For example, this is what vec4_visitor::fix_3src_operand() is already doing: if (src.file == UNIFORM &&

Re: [Mesa-dev] [PATCH 0/2] i965/vec4: Change SEL and MOV types as needed to propagate source modifiers

On 22/09/15 08:38, Thomas Helland wrote: > > 16. sep. 2015 21.47 skrev "Alejandro Piñeiro" <apinhe...@igalia.com > <mailto:apinhe...@igalia.com>>: > > > > On the review of the patch "i965/nir/vec4: fill the type of the dst > > and src when

[Mesa-dev] [PATCH v5] i965/vec4: refactor brw_vec4_copy_propagation.

Now it is more similar to brw_fs_copy_propagation, with three clear stages: 1) Build up the value we are propagating as if it were the source of a single MOV: 2) Check that we can propagate that value 3) Build the final value Previously everything was somewhat messed up, making the

Re: [Mesa-dev] [PATCH v3] i965/vec4: Change types as needed to propagate source modifiers using current instruction

On 18/09/15 20:00, Jason Ekstrand wrote: > > > On Sep 18, 2015 10:09 AM, "Alejandro Piñeiro" <apinhe...@igalia.com > <mailto:apinhe...@igalia.com>> wrote: > > > > SEL and MOV instructions, as long as they don't have source > modifiers,

[Mesa-dev] [PATCH v3] i965/vec4: Change types as needed to propagate source modifiers using current instruction

SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to

[Mesa-dev] [PATCH v3] i965/vec4: Change types as needed to propagate source modifiers using from instruction

SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to

Re: [Mesa-dev] [PATCH v4] i965/vec4: Change types as needed to propagate source modifiers using from instruction

On 21/09/15 18:27, Jason Ekstrand wrote: > On Sun, Sep 20, 2015 at 3:00 PM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> MOV instructions, as long as they don't have source modifiers, are >> just copying bits around. So those kind of instruction cou

[Mesa-dev] [PATCH 0/2] Remove _mesa_is_array_texture

://lists.freedesktop.org/archives/mesa-dev/2015-February/076533.html So although if someone prefers to keep the newer instead of the older, I can make the opposite change. Alejandro Piñeiro (2): i965: use _mesa_tex_target_is_array instead of _mesa_is_array_texture mesa: remove _mesa_is_array_texture

[Mesa-dev] [PATCH 2/2] mesa: remove _mesa_is_array_texture

_mesa_tex_target_is_array provides the same functionality and is older. --- src/mesa/main/teximage.c | 23 --- src/mesa/main/teximage.h | 3 --- 2 files changed, 26 deletions(-) diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c index 60fc7cc..f7fac37 100644

[Mesa-dev] [PATCH 1/2] i965: use _mesa_tex_target_is_array instead of _mesa_is_array_texture

Both methods provide the same functionality, so one would be removed. _mesa_tex_target_is_array is the older one. --- src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 2 +- src/mesa/drivers/dri/i965/gen8_surface_state.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [PATCH v2 2/2] mesa: remove _mesa_tex_target_is_array

_mesa_is_array_texture provides the same functionality and: 1. it returns bool instead of GLboolean 2. it's not related to the texture format (texformat.c) 3. the name's a little shorter v2: remove _mesa_tex_target_is_array instead (Brian Paul) --- src/mesa/main/texformat.c | 14 --

[Mesa-dev] [PATCH v2 1/2] i965: use _mesa_is_array_texture instead of _mesa_tex_target_is_array

Both methods provide the same functionality, so one would be removed. v2: use _mesa_is_array_texture and not the other way (Brian Paul) --- src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 2 +- src/mesa/drivers/dri/i965/gen8_surface_state.c| 2 +- 2 files changed, 2 insertions(+), 2

Re: [Mesa-dev] [PATCH v2 1/2] i965: use _mesa_is_array_texture instead of _mesa_tex_target_is_array

On 07/12/15 17:00, Brian Paul wrote: > On 12/05/2015 12:51 PM, Alejandro Piñeiro wrote: >> Both methods provide the same functionality, so one would be >> removed. >> >> v2: use _mesa_is_array_texture and not the other way (Brian Paul) >> -

Re: [Mesa-dev] Patchwork review process (efficiency) questions

On 03/06/16 18:45, Patrick Baggett wrote: >> I will point out a couple notes/observations: >> >> Kernel (drm/dri-devel), xorg, and other related projects use the same >> process, and a lot of us do (or at least at some point have) been >> active in 2 or more of these. >> >> Also, I have seen/used

Re: [Mesa-dev] [PATCH] glsl: geom shader max_vertices layout must match.

On 03/06/16 02:46, Dave Airlie wrote: > From: Dave Airlie > > "all geometry shader output vertex count declarations in a > program must declare the same count." This spec quote lacks context. As far as I see it comes from GLSL 4.5 spec, "4.4.2.3 Geometry Outputs". > > Fixes:

Re: [Mesa-dev] [PATCH 2/5] glsl: Optionally lower TES gl_PatchVerticesIn to a uniform.

b/src/mesa/program/prog_statevars.h > index 6333e63..4b27527 100644 > --- a/src/mesa/program/prog_statevars.h > +++ b/src/mesa/program/prog_statevars.h > @@ -128,6 +128,7 @@ typedef enum gl_state_index_ { > STATE_PT_BIAS, /**< Pixel t

Re: [Mesa-dev] [PATCH 4/5] glsl: Optionally lower TCS gl_PatchVerticesIn to a uniform.

On 02/06/16 23:09, Kenneth Graunke wrote: > i965 has no special hardware for this, so the best way to implement > this is to pass it in via a uniform. Is this comment accurate? On the next patch you implement the i965 bits, and you only do the lowering on gen8+, mentioning that you would like to

Re: [Mesa-dev] [PATCH 3/5] i965: Use a uniform for gl_PatchVerticesIn in the TES.

rimitiveRestartForPatches = true; > > ctx->Const.Program[MESA_SHADER_VERTEX].MaxNativeInstructions = 16 * 1024; Nitpicks apart: Reviewed-by: Alejandro Piñeiro <apinhe...@igalia.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] i965: Use a uniform for gl_PatchVerticesIn in the TES.

On 08/06/16 19:45, Alejandro Piñeiro wrote: > On 02/06/16 23:09, Kenneth Graunke wrote: >> Fixes GL44-CTS.tessellation_shader.single.max_patch_vertices, >> which uses gl_PatchVerticesIn in the TES, but doesn't link against >> a TCS (which would allow the linker to l

Re: [Mesa-dev] [PATCH 2/5] glsl: Optionally lower TES gl_PatchVerticesIn to a uniform.

On 09/06/16 05:50, Kenneth Graunke wrote: > On Wednesday, June 8, 2016 7:45:16 PM PDT Alejandro Piñeiro wrote: >> On 02/06/16 23:09, Kenneth Graunke wrote: >>> i965 has no special hardware for this, so we need to pass this value in >>> as a uniform (unless the TES is lin

Re: [Mesa-dev] [PATCH 4/5] glsl: Optionally lower TCS gl_PatchVerticesIn to a uniform.

On 09/06/16 05:44, Kenneth Graunke wrote: > On Wednesday, June 8, 2016 7:45:43 PM PDT Alejandro Piñeiro wrote: >> On 02/06/16 23:09, Kenneth Graunke wrote: >>> i965 has no special hardware for this, so the best way to implement >>> this is to pass it in via a uniform.

Re: [Mesa-dev] [PATCH 4/5] glsl: Optionally lower TCS gl_PatchVerticesIn to a uniform.

Assuming that you are sure about Ian's doubt: Reviewed-by: Alejandro Piñeiro <apinhe...@igalia.com> On 02/06/16 23:09, Kenneth Graunke wrote: > i965 has no special hardware for this, so the best way to implement > this is to pass it in via a uniform. > > Signed-off-by: Ken

Re: [Mesa-dev] [PATCH 5/5] i965: Use a uniform for gl_PatchVerticesIn in the TCS on Gen8+.

Reviewed-by: Alejandro Piñeiro <apinhe...@igalia.com> On 02/06/16 23:09, Kenneth Graunke wrote: > We still need to recompile the passthrough shader when this value > changes, as it also affects the output vertex count. But otherwise, > we can eliminate recompiles on Gen8+. >

Re: [Mesa-dev] [PATCH] glsl/ast: don't allow subroutine uniform comparisons

akes a left-hand " > + "operand of type 'subroutine' or a right operand of > type " > + "'subroutine'", (this->oper == ast_equal) ? "==" : > "!="); > + error_emitted = true; >

Re: [Mesa-dev] [PATCH] glsl: geom shader max_vertices layout must match.

On 06/06/16 09:44, Alejandro Piñeiro wrote: > On 06/06/16 09:00, Dave Airlie wrote: >> On 6 June 2016 at 16:30, Alejandro Piñeiro <apinhe...@igalia.com> wrote: >>> On 03/06/16 23:04, Dave Airlie wrote: >>>> On 4 June 2016 at 03:39, Alejandro Piñeiro <apinhe.

Re: [Mesa-dev] [PATCH] glsl: geom shader max_vertices layout must match.

On 06/06/16 09:00, Dave Airlie wrote: > On 6 June 2016 at 16:30, Alejandro Piñeiro <apinhe...@igalia.com> wrote: >> On 03/06/16 23:04, Dave Airlie wrote: >>> On 4 June 2016 at 03:39, Alejandro Piñeiro <apinhe...@igalia.com> wrote: >>>> On 03/06/16 02:46,

  1   2   3   4   5   6   7   8   9   10   >