Sorry, should've clarified to mean this patch gets my r-b.
On Wed, Feb 11, 2015 at 9:20 PM, Connor Abbott wrote:
> Given that this commit only changes NIR code, I think it should be
> prefixed by "nir: ", e.g. "nir: Drop dependency on mtypes.h in nir.h."
>
What does the source look like? Both the TGSI and GLSL looks fine to
me. This is essentially doing:
vec3 vec_value_tmp = ...;
bvec3 dereference_condition = equals(row.xxx, vec3(0, 1, 2));
//per-component equals
float tmp; //called vec_index_tmp_v in the GLSL IR
// this is where the use-before-def
I'll ask the same question I asked Jason when he did this for FS...
did you verify that the new q_values is the same as the old one?
On Fri, Feb 13, 2015 at 8:02 AM, Francisco Jerez wrote:
> This fixes a regression in the running time of Piglit introduced by
> commit 78e9043475d4bed8b50f7e413963c
I think we should be adding this to nir_emit_system_values_block()
like we do for the other system values. This should get us parity with
what we had before where we only called
emit_frontfacing_interpolation() once per shader.
On Sat, Feb 14, 2015 at 3:51 PM, Jason Ekstrand wrote:
> ---
> src/m
Patches 2 and 3 are
Reviewed-by: Connor Abbott
On Sat, Feb 14, 2015 at 3:51 PM, Jason Ekstrand wrote:
> GLSL IR labels gl_FrontFacing as an input variable and not a system value.
> This commit makes NIR silently translate gl_FrontFacing to a system value
> so that it properly gets t
Reviewed-by: Connor Abbott
On Sat, Feb 14, 2015 at 4:26 PM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> b/src/mesa/drivers/dri/i
Hi Francisco,
A few comments:
1) This is just a difference in definitions, but to me an
optimistically-colored node is a node that we pushed onto the stack
without knowing whether we could color it or not. There may be (and
most certainly are) nodes above the optimistically-colored node on the
st
I gave my r-b on v1 since I couldn't find the v2 and you hadn't sent
the v3 yet. We'll figure out the rest of it later.
On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand wrote:
> Previously, if you remved a CF node that still had instructions in it, none
> of the use/def information from those inst
Now that we talked about this on the last version of this patch, this
makes more sense. But I'd like to see something in the commit message
explaining what the issue was (going too far and casting the exec_node
embedded in the block to a nir_instr) and how you put the patch that
changes the behavio
On Mon, Feb 16, 2015 at 3:57 PM, Connor Abbott wrote:
> Now that we talked about this on the last version of this patch, this
> makes more sense. But I'd like to see something in the commit message
> explaining what the issue was (going too far and casting the exec_node
> embedde
Reviewed-by: Connor Abbott
On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand wrote:
> ---
> This replaces the original patch 10 even though they are very different.
>
> src/glsl/nir/nir.h | 6 --
> src/glsl/nir/nir_opt_dce.c | 14 +-
> 2 files chan
That seems fine to me.
On Mon, Feb 16, 2015 at 4:23 PM, Jason Ekstrand wrote:
>
>
> On Mon, Feb 16, 2015 at 1:03 PM, Connor Abbott wrote:
>>
>> On Mon, Feb 16, 2015 at 3:57 PM, Connor Abbott
>> wrote:
>> > Now that we talked about this on the last version
This patch is
Reviewed-by: Connor Abbott
I'll leave it to the others to review the i965 stuff as I'm not as
well-versed in it, although it makes sense to me.
On Tue, Feb 17, 2015 at 2:46 PM, Matt Turner wrote:
> From: Jason Ekstrand
>
> This adds a parent_instr field sim
On Tue, Feb 17, 2015 at 2:00 PM, Jason Ekstrand wrote:
>
>
> On Mon, Feb 16, 2015 at 11:39 AM, Francisco Jerez
> wrote:
>
>
> UINT_MAX would be clearer than ~0
>
>>
>> int i;
>>
>> while (progress) {
>> @@ -483,12 +490,16 @@ ra_simplify(struct ra_graph *g)
>>
>>if (!progress && be
On Tue, Feb 17, 2015 at 8:15 AM, Francisco Jerez wrote:
> Connor Abbott writes:
>
>> Hi Francisco,
>>
> Hi Connor, and thank you for your feedback.
>
>> A few comments:
>>
>> 1) This is just a difference in definitions, but to me an
>> optimisti
On Tue, Feb 17, 2015 at 3:04 PM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> On Mon, Feb 16, 2015 at 11:39 AM, Francisco Jerez
>> wrote:
>>
>>> The round-robin allocation strategy is expected to decrease the amount
>>> of false dependencies created by the register allocator and give the
On Tue, Feb 17, 2015 at 3:52 PM, Eric Anholt wrote:
> Matt Turner writes:
>
>> From: Jason Ekstrand
>>
>> This adds a parent_instr field similar to the one for ssa_def. The
>> difference here is that the parent_instr field on a nir_register can be
>> NULL if the register does not have a unique
On Tue, Feb 17, 2015 at 4:41 PM, Alan Coopersmith
wrote:
> On 02/17/15 10:21 AM, Emil Velikov wrote:
>>
>> Hi Alan,
>>
>> On 16/02/15 02:41, Alan Coopersmith wrote:
>>>
>>> When compiling in C99 or C++11 modes, Solaris defines isnormal() as
>>> a macro via , which causes the function definition to
On Tue, Feb 17, 2015 at 6:44 PM, Eric Anholt wrote:
> Connor Abbott writes:
>
>> On Tue, Feb 17, 2015 at 3:52 PM, Eric Anholt wrote:
>>> Matt Turner writes:
>>>
>>>> From: Jason Ekstrand
>>>>
>>>> This adds a parent_instr field
On Tue, Feb 17, 2015 at 3:17 PM, Connor Abbott wrote:
> On Tue, Feb 17, 2015 at 3:04 PM, Francisco Jerez
> wrote:
>> Jason Ekstrand writes:
>>
>>> On Mon, Feb 16, 2015 at 11:39 AM, Francisco Jerez
>>> wrote:
>>>
>>>> The round-rob
Ok, so I think there are two things left that I'm going to ask for:
1) Add a nir_builder_init(nir_builder *, nir_function_impl *),
nir_builder_insert_after_cf_list(nir_builder *, exec_list *), and if
you feel like it (you could use it in tgsi -> nir) a helper function
nir_builder_init_after_cf_lis
On Wed, Feb 18, 2015 at 8:31 AM, Francisco Jerez wrote:
> Connor Abbott writes:
>
>> On Tue, Feb 17, 2015 at 3:04 PM, Francisco Jerez
>> wrote:
>>> Jason Ekstrand writes:
>>>
>>>> On Mon, Feb 16, 2015 at 11:39 AM, Francisco Jerez
>>>&
IES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef _NIR_BUILDER_OPCODES_
> +#define _NIR_BUILDER_OPCODES_
> +
> +% for name, opcode in sorted(opcodes.iteritems()):
> +ALU${opcode.num_inputs}(${name});
> +% endfor
> +
> +#endif /* _NIR_BUILDER_OPCODES_ */"""
> +
> +from nir_opcodes import opcodes
> +from mako.template import Template
> +
> +print Template(template).render(opcodes=opcodes)
> --
> 2.1.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Connor Abbott
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I agree with Ken that the regressions are small enough, and it seems
they're mostly stuff we can prevent by being smarter when doing the
sel peephole, so it seems like the cleanup that will probably help
other passes is worth it.
Reviewed-by: Connor Abbott
On Fri, Feb 20, 2015 at 1:03 AM,
On Fri, Feb 20, 2015 at 3:04 PM, Eric Anholt wrote:
> We have some useful optimizations to drop things like 'ine a, 0' on a
> boolean argument, but if 'a' came from logical operations on bools, it
> couldn't tell. These kinds of constructs appear as a result of TGSI->NIR
> quite frequently (at le
Aside from one minor suggestion for patch 2, this series is
Reviewed-by: Connor Abbott
On Fri, Feb 20, 2015 at 3:28 PM, Matt Turner wrote:
> The series is
>
> Reviewed-by: Matt Turner
> ___
> mesa-dev mailing list
> mesa-dev@lis
Reviewed-by: Connor Abbott
Whoops, I should've caught that...
On Sun, Feb 22, 2015 at 1:31 AM, Jason Ekstrand wrote:
> ---
> src/glsl/nir/nir_opt_gcm.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/glsl/nir/nir_opt_gcm.c b/src/glsl/nir/nir_opt_gcm.c
>
On Tue, Feb 24, 2015 at 5:19 AM, Kenneth Graunke wrote:
> For conditional discards, we can call emit_bool_to_cond_code to generate
> the condition in f0.0. However, we want it in f0.1. The flag value is
> always produced by the last instruction emit_bool_to_cond_code
> generates, so we can simpl
Except for the comment on patch 6, patches 1-7 are
Reviewed-by: Connor Abbott
I'm not familiar enough with the code patch 8 is modifying, and Matt
and Eric have already commented on it.
On Tue, Feb 24, 2015 at 5:19 AM, Kenneth Graunke wrote:
> Copy and pasted from the ir_if::c
ere carrying around. This patch changes it to have a special jump
> instruction that gets placed at the end of the block in front of the if.
> This way we no longer have to keep special-casing the source and can treate
> it like any other use in an instruction.
>
> Cc: Connor
Reviewed-by: Connor Abbott
On Thu, Mar 5, 2015 at 11:26 PM, Kenneth Graunke wrote:
> Being able to see both location and driver_location can be useful when
> debugging IO mistakes.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/nir/nir_print.c | 2 +-
> 1 file chang
Reviewed-by: Connor Abbott
I was in the middle of rewriting this pass for making derefs
instructions, which hasn't been going nearly as nicely as I would like
(ugh...), so if it pans out then I'll have to think about it a little
more to make sure the new version is deterministic to
Reviewed-by: Connor Abbott
On Mon, Mar 9, 2015 at 9:36 PM, Kenneth Graunke wrote:
> From: Jason Ekstrand
>
> __next and __prev are pointers to the structure containing the exec_node
> link, not the embedded exec_node. NULL checks would fail unless the
> embedded exec_node ha
On Mon, Mar 9, 2015 at 10:35 PM, Matt Turner wrote:
> On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner wrote:
>> On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke
>> wrote:
>>> From: Jason Ekstrand
>>>
>>> __next and __prev are pointers to the structure containing the exec_node
>>> link, not the embe
On Mon, Mar 9, 2015 at 10:54 PM, Jason Ekstrand wrote:
>
>
> On Mon, Mar 9, 2015 at 7:48 PM, Connor Abbott wrote:
>>
>> On Mon, Mar 9, 2015 at 10:35 PM, Matt Turner wrote:
>> > On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner wrote:
>> >> On Mon, Mar 9, 201
On Mon, Mar 9, 2015 at 11:02 PM, Jason Ekstrand wrote:
>
>
> On Mon, Mar 9, 2015 at 7:59 PM, Connor Abbott wrote:
>>
>> On Mon, Mar 9, 2015 at 10:54 PM, Jason Ekstrand
>> wrote:
>> >
>> >
>> > On Mon, Mar 9, 2015 at 7:48 PM, Connor Abbott
&
On Tue, Mar 10, 2015 at 10:54 PM, Ian Romanick wrote:
> On 03/09/2015 06:36 PM, Kenneth Graunke wrote:
>> From: Jason Ekstrand
>>
>> __next and __prev are pointers to the structure containing the exec_node
>> link, not the embedded exec_node. NULL checks would fail unless the
>> embedded exec_no
On Thu, Feb 9, 2017 at 4:16 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> Hello
>
> IMPORTANT NOTE: Using the uint32_t data type, quad_hash*quad_hash will
> overflow as soon as the hash table has more than 2**16=65536=64K
> elements. To enable more than 64K elements in hash table, the data
> typ
Even though we supported both coherent and non-coherent memory types, we
effectively forced apps to use the coherent types by accident. Found by
inspection, only compile tested.
Signed-off-by: Connor Abbott
---
I sent this out a while ago, but it seems like it was lost.
---
src/intel/vulkan
On Tue, Feb 14, 2017 at 12:33 PM, Jason Ekstrand wrote:
> On Tue, Feb 14, 2017 at 9:23 AM, Connor Abbott wrote:
>>
>> Even though we supported both coherent and non-coherent memory types, we
>> effectively forced apps to use the coherent types by accident. Found by
>&g
(I'm replying to this version, since I can't find an email
corresponding to the version you have on Github. Did you ever get
git-send-email working again?)
On Tue, Jul 14, 2015 at 4:29 PM, Thomas Helland
wrote:
> Signed-off-by: Thomas Helland
> ---
> src/glsl/Makefile.sources |1 +
FWIW, both patches are:
Reviewed-by: Connor Abbott
I'm working on FP64 support (I've been using no16 up till now) so this
is obviously very useful to me.
On Wed, Aug 5, 2015 at 10:38 AM, Francisco Jerez wrote:
> This extends the SIMD lowering pass to enforce the hardware limitat
), true, 1, 0, 0,
> + NIR_INTRINSIC_CAN_ELIMINATE | NIR_INTRINSIC_CAN_REORDER)
It looks like there's 3 sources, but you've only specified the size of
one. Did you mean to do ARR(1, 1, 1)? With that fixed,
Reviewed-by: Connor Abbott
> +
> +/*
>
On Wed, Aug 5, 2015 at 1:30 AM, Iago Toral Quiroga wrote:
> ---
> src/glsl/nir/glsl_to_nir.cpp | 36
> src/glsl/nir/nir_intrinsics.h | 12 ++--
> 2 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/gls
ir/nir_intrinsics.h b/src/glsl/nir/nir_intrinsics.h
> index 83eeecd..9877ea4 100644
> --- a/src/glsl/nir/nir_intrinsics.h
> +++ b/src/glsl/nir/nir_intrinsics.h
> @@ -168,7 +168,7 @@ SYSTEM_VALUE(invocation_id, 1)
> LOAD(uniform, 0, NIR_INTRINSIC_CAN_ELIMINATE | NIR_INTRINSIC_CAN_REORDER)
Change the prefix to "nir/glsl_to_nir" and this is
Reviewed-by: Connor Abbott
On Wed, Aug 5, 2015 at 1:30 AM, Iago Toral Quiroga wrote:
> ---
> src/glsl/nir/glsl_to_nir.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/glsl/nir/glsl_
On Wed, Aug 5, 2015 at 1:30 AM, Iago Toral Quiroga wrote:
> The original GLSL IR intrinsics have been lowered to an internal
> version that accepts a block index and an offset instead of a
> SSBO reference.
> ---
> src/glsl/nir/glsl_to_nir.cpp | 55
> +++
On Thu, Aug 6, 2015 at 12:23 AM, Iago Toral wrote:
> On Wed, 2015-08-05 at 12:24 -0700, Connor Abbott wrote:
>> On Wed, Aug 5, 2015 at 1:30 AM, Iago Toral Quiroga wrote:
>> > The original GLSL IR intrinsics have been lowered to an internal
>> > version that accepts
On Thu, Aug 6, 2015 at 12:30 AM, Iago Toral wrote:
> On Wed, 2015-08-05 at 12:17 -0700, Connor Abbott wrote:
>> On Wed, Aug 5, 2015 at 1:30 AM, Iago Toral Quiroga wrote:
>> > ---
>> > src/glsl/nir/glsl_to_nir.cpp | 36
>>
So, I was sort of imagining that we'd want to go a little farther with
this, and make nir_instr_insert_before/after_* a wrapper around a
cursor based API just called "nir_instr_insert". Then
nir_builder_instr_insert() would become even simpler, since it would
just call nir_instr_insert() and then p
On Fri, Aug 7, 2015 at 1:15 AM, Iago Toral wrote:
> On Fri, 2015-08-07 at 07:43 +0200, Iago Toral wrote:
>> On Thu, 2015-08-06 at 11:06 -0700, Connor Abbott wrote:
>> > On Thu, Aug 6, 2015 at 12:30 AM, Iago Toral wrote:
>> > > On Wed, 2015-08-05 at 12:17 -0700, C
Less duplication and one less case to handle for doubles.
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
b/src/mesa/drivers/dri/i965
Signed-off-by: Connor Abbott
---
src/glsl/ir_equals.cpp | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ir_equals.cpp b/src/glsl/ir_equals.cpp
index cc1964e..c6446f7 100644
--- a/src/glsl/ir_equals.cpp
+++ b/src/glsl/ir_equals.cpp
@@ -58,8 +58,13
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index ce1edc3..812648f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index c7628dc..44af5f3 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
+++ b
This makes intelligent autocomplete plugins much happier.
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir_builder.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/nir/nir_builder.h b/src/glsl/nir/nir_builder.h
index 9223e83..1745453 100644
--- a/src/glsl/nir/nir_builder.h
we
checked previously into it.
Signed-off-by: Connor Abbott
---
.../drivers/dri/i965/brw_fs_copy_propagation.cpp | 58 +-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
b/src/mesa/driver
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 386e9a2..5474eac 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa
This way the caller doesn't have to initialize all 4 channels when they
aren't using them.
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir_builder.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/nir/nir_builder.h b/src/glsl/nir/nir_builder.h
ind
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir_opcodes.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/nir/nir_opcodes.py b/src/glsl/nir/nir_opcodes.py
index df5b7e2..77c766b 100644
--- a/src/glsl/nir/nir_opcodes.py
+++ b/src/glsl/nir/nir_opcodes.py
Signed-off-by: Connor Abbott
---
src/glsl/builtin_functions.cpp | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 2175c66..ac55170 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl
round.
Signed-off-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 812648f..386e9a2 100644
--- a/src/mesa/drivers/dri
This can happen when the source of the compare was split by the SIMD
lowering pass. Potentially, we could allow the case where the exec size
of scan_inst is larger, and scan_inst has the right quarter selected,
but doing that seems a little more risky.
Signed-off-by: Connor Abbott
---
src/mesa
re's
the result of that -- a random smattering of fixes and improvements here
and there that I did either to help debugging or to fix some of the fp64
piglit tests.
Connor Abbott (12):
nir/builder: include nir.h
nir/builder: only read meaningful channels in nir_swizzle()
nir: fix con
On Mon, Aug 17, 2015 at 12:09 AM, Pohjolainen, Topi
wrote:
> On Fri, Aug 14, 2015 at 03:30:18PM -0700, Connor Abbott wrote:
>> In some cases, we need to emit ALU instructions with a certain stride
>> due to a HW limitation. When splitting that instruction, we need to
>>
On Mon, Aug 17, 2015 at 1:27 AM, Connor Abbott wrote:
> On Mon, Aug 17, 2015 at 12:09 AM, Pohjolainen, Topi
> wrote:
>> On Fri, Aug 14, 2015 at 03:30:18PM -0700, Connor Abbott wrote:
>>> In some cases, we need to emit ALU instructions with a certain stride
>>>
On Mon, Aug 17, 2015 at 2:41 AM, Francisco Jerez wrote:
> Connor Abbott writes:
>
>> On Mon, Aug 17, 2015 at 12:09 AM, Pohjolainen, Topi
>> wrote:
>>> On Fri, Aug 14, 2015 at 03:30:18PM -0700, Connor Abbott wrote:
>>>> In some cases, we need to emit
On Tue, Aug 18, 2015 at 2:29 AM, Francisco Jerez wrote:
> Connor Abbott writes:
>
>> On Mon, Aug 17, 2015 at 2:41 AM, Francisco Jerez
>> wrote:
>>> Connor Abbott writes:
>>>
>>>> On Mon, Aug 17, 2015 at 12:09 AM, Pohjolainen, Topi
>>>
On Tue, Aug 18, 2015 at 9:56 AM, Kenneth Graunke wrote:
> Hey,
>
> I was thinking about using an anonymous union. Specifically, something
> like:
>
> struct shader {
>...
>union {
> struct geometry_shader_info gs;
> struct tess_eval_shader_info tes;
> ...
>};
> };
>
largely involves moving the existing code into a new function.
>
> Suggested by Connor Abbott.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/nir/nir.c | 115
++---
> src/glsl/nir/nir.h | 7
> 2 files changed, 63 inse
On Aug 27, 2015 11:45 AM, "Jason Ekstrand" wrote:
>
> On Tue, Aug 25, 2015 at 1:24 PM, Kenneth Graunke
wrote:
> > This is a lot more reasonable than returning an offset from NULL.
> >
> > Signed-off-by: Kenneth Graunke
> > ---
> > src/glsl/nir/nir.h | 4 ++--
> > 1 file changed, 2 insertions(+)
This seems a little dubious... why restrict it to gen7+? And why only
scalar? This pass assumes SSA, but so do many other passes in core NIR
that we also run in nir_optimize(), so that shouldn't be a problem.
On Thu, Sep 15, 2016 at 3:03 AM, Timothy Arceri
wrote:
> ---
> src/compiler/glsl/glsl_p
On Thu, Sep 15, 2016 at 9:06 PM, Timothy Arceri
wrote:
> On Thu, 2016-09-15 at 19:49 -0400, Connor Abbott wrote:
>> This seems a little dubious... why restrict it to gen7+?
>
> Because if we don't switch to using nir_lower_indirect_derefs() then
> lower_variable_index_to_co
On Fri, Sep 16, 2016 at 6:25 PM, Jason Ekstrand wrote:
> On Thu, Sep 15, 2016 at 12:03 AM, Timothy Arceri
> wrote:
>>
>> From: Thomas Helland
>>
>> This pass detects induction variables and calculates the
>> trip count of loops to be used for loop unrolling.
>>
>> I've removed support for float
I don't know anything about this code, but the change seems obviously
correct so feel free to add my r-b.
On Wed, Oct 5, 2016 at 3:13 PM, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> Cc: "12.0"
> Cc: Jordan Justen
> ---
> src/compiler/nir/nir_lower_io.c | 2 +-
> 1 file changed, 1
Thanks for doing this! This has always bugged me. For the series,
Reviewed-by: Connor Abbott
On Wed, Oct 5, 2016 at 11:37 PM, Jason Ekstrand wrote:
> This makes calling nir_foo_as_bar a bit safer because we're no longer 100%
> trusting in the caller to ensure that it's safe.
On Wed, Aug 10, 2016 at 1:53 PM, Eric Anholt wrote:
> Kenneth Graunke writes:
>
>> On Haswell (GL 3.3):
>>
>> total instructions in shared programs: 6208759 -> 6203860 (-0.08%)
>> instructions in affected programs: 856541 -> 851642 (-0.57%)
>> helped: 3157
>> HURT: 113
>> LOST: 7
>> GAINED: 15
On Wed, Aug 10, 2016 at 2:24 PM, Kenneth Graunke wrote:
> On Wednesday, August 10, 2016 10:02:12 AM PDT Erik Faye-Lund wrote:
>> On Wed, Aug 10, 2016 at 4:30 AM, Kenneth Graunke
>> wrote:
>> > On Haswell (GL 3.3):
>> >
>> > total instructions in shared programs: 6208759 -> 6203860 (-0.08%)
>> >
So, I don't know much about how nv50 ir works, but to me this just
seems like a pretty slow implementation of a very limited instruction
scheduler. In addition to the runtime complexity problems you
mentioned, you're going to get a lot more benefit even from a very
simple list scheduler compared to
On Sat, Aug 13, 2016 at 3:33 PM, Ilia Mirkin wrote:
> On Sat, Aug 13, 2016 at 3:26 PM, Connor Abbott wrote:
>> So, I don't know much about how nv50 ir works, but to me this just
>> seems like a pretty slow implementation of a very limited instruction
>> scheduler.
On Wed, Aug 17, 2016 at 10:15 AM, Kenneth Graunke wrote:
> Fixes several GL44-CTS.tessellation_shader (and GL45 and ES31) subcases:
> - vertex_spacing
> - tessellation_shader_point_mode.points_verification
> - tessellation_shader_quads_tessellation.inner_tessellation_level_rounding
>
> Cc: mesa-st
each_function(func, nir) {
> - if (!func->impl)
> - continue;
> + nir_function *func = nir_shader_get_entrypoint(nir);
> + if (!func->impl)
> + return;
Minor nit: I think you can drop the if, since it doesn't make sense to
have an entrypoint with only a declaration and no
On Thu, Aug 18, 2016 at 6:12 PM, Jason Ekstrand wrote:
> On Aug 18, 2016 23:02, "Connor Abbott" wrote:
>>
>> On Thu, Aug 18, 2016 at 2:46 PM, Kenneth Graunke
>> wrote:
>> > We want to insert the code at the end of the program. Looping over
>> &g
splitting it, so that the set of predecessors remained
> unchanged. This was admittedly ugly.
>
> Connor suggested instead saving a copy of the set, so we can iterate
> it safely. This is also a little ugly, but a much better plan.
>
> Signed-off-by: Kenneth Graunke
> Cc: Co
ader,
> +val->num_components,
> +val->bit_size);
> + nir_instr_insert(nir_before_cf_list(&val->builder->impl->body),
> + &undef->instr);
I mentioned on IRC that
>
> In any case, this patch ensures we avoid that problem as well.
>
> Cc: mesa-sta...@lists.freedesktop.org
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97225
Reviewed-by: Connor Abbott
> ---
> Most easily reviewed with git show -w
>
> src/compiler/nir
On Thu, Aug 25, 2016 at 2:26 PM, Matt Turner wrote:
> On Wed, Aug 24, 2016 at 11:25 PM, Connor Abbott wrote:
>> On Thu, Aug 25, 2016 at 12:04 AM, Matt Turner wrote:
>>> Prior to this commit rename_variables_block() is recursively called,
>>> performing a depth-fir
On Mon, Aug 29, 2016 at 12:54 AM, Timothy Arceri
wrote:
> Don't do copy propagation inside loops until after we try
> unrolling them.
>
> This helps avoid propagating everything to the phis which
> makes loop unrolling more difficult.
>
> For example without this:
>
>loop {
> block block
On Mon, Aug 29, 2016 at 12:59 AM, Timothy Arceri
wrote:
> ---
> src/compiler/Makefile.sources | 1 +
> src/compiler/nir/nir.h | 2 +
> src/compiler/nir/nir_opt_loop_unroll.c | 394
> +
> 3 files changed, 397 insertions(+)
> create mod
I already noted in patch 12/13 that you can get rid of your use of
stitch_blocks(). I also don't get why you need a special
nir_cf_loop_list_extract() here... why
On Mon, Aug 29, 2016 at 12:59 AM, Timothy Arceri
wrote:
> This makes stitch_blocks() available for use else where, and adds
> a new he
So, you've noticed that your method of handling phi's while cloning
doesn't handle phi's that point to other phi's in the same block.
Particularly, something like:
a = phi(b, ...)
b = phi(a, ...)
which is supposed to swap a and b each iteration. Here's a better
strategy which should be simpler th
On Mon, Aug 29, 2016 at 2:30 AM, Timothy Arceri
wrote:
> On Mon, 2016-08-29 at 01:30 -0400, Connor Abbott wrote:
>> On Mon, Aug 29, 2016 at 12:54 AM, Timothy Arceri
>> wrote:
>> >
>> > Don't do copy propagation inside loops until after we try
>>
On Tue, Aug 30, 2016 at 12:40 AM, Matt Turner wrote:
> On Mon, Aug 29, 2016 at 9:06 PM, Timothy Arceri
> wrote:
>> Can't the phi have more than one source from before the loop? e.g
>>
>>int i = 0;
>>if (somthing)
>> i = 1;
>>else
>> i = 2;
>>
>>for ( ; i < 5; i++)
>>
On Mon, Aug 29, 2016 at 11:57 PM, Timothy Arceri
wrote:
> On Mon, 2016-08-29 at 20:42 -0400, Connor Abbott wrote:
>> I already noted in patch 12/13 that you can get rid of your use of
>> stitch_blocks(). I also don't get why you need a special
>> nir_cf_loop_list_extr
On Tue, Aug 30, 2016 at 10:06 AM, Marek Olšák wrote:
> On Tue, Aug 30, 2016 at 3:21 PM, Eero Tamminen
> wrote:
>> Hi,
>>
>>
>> On 30.08.2016 12:51, Marek Olšák wrote:
>>>
>>> Recently I discovered that our GLSL compiler spends a lot of time in
>>> rzalloc_size, so I looked at possible options to
As-is, this change will make us delete trivially infinite loops (i.e.
loops with no break statement). The most likely scenario where we get
one of those (besides for silly Piglit tests) is a developer with an
accidental bug in their shader. In that case, it seems kinda mean to
then delete the entir
On Thu, Sep 1, 2016 at 6:19 PM, Jason Ekstrand wrote:
> On Thu, Sep 1, 2016 at 12:41 PM, Connor Abbott wrote:
>>
>> As-is, this change will make us delete trivially infinite loops (i.e.
>> loops with no break statement). The most likely scenario where we get
>> one
I think we can just fix this by emitting another move with the right
swizzle. Then DCE should clean up the original moves, so it should
still be a win. Let me send a patch.
On Fri, Sep 2, 2016 at 4:50 PM, Kenneth Graunke wrote:
> This reverts commit 144cbf89879103c45f79b7c5b923ebad63f08c55.
>
> I
In 144cbf8 ("nir: Make nir_opt_remove_phis see through moves."), Ken
made nir_opt_remove_phis able to coalesce phi nodes whose sources are
all moves with the same swizzle. However, he didn't add the logic
necessary for handling the fact that the phi may now have multiple
different sources, even tho
And re-implement nir_after_cf_node_and_phis() using it.
---
src/compiler/nir/nir.h | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index d0dfb0d..6852551 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/
201 - 300 of 1264 matches
Mail list logo
