On Sun, Jan 23, 2022 at 1:58 PM Abel Bernabeu
wrote:
>>
>> Yes, NIR arrays and struct and nir_deref to deal with them but, by the time
>> you get into the back-end, all the nir_derefs are gone and you're left with
>> load/store messages with actual addresses (either a 64-bit memory address or
>
There are precise rules for when calculations in GL must return the
same result, which are laid out in Appendix A ("Invariance"). The
relevant rule here:
"Rule 4 The same vertex or fragment shader will produce the same result when
run multiple times with the same input. The wording ‘the same shade
On Fri, Jan 7, 2022 at 6:32 PM Emma Anholt wrote:
>
> On Fri, Jan 7, 2022 at 6:18 AM Connor Abbott wrote:
> >
> > Unfortunately batch mode has only made it *worse* - I'm sure it's not
> > intentional, but it seems that it's still running the CI pipelines
&g
On Fri, Jan 7, 2022 at 6:32 PM Emma Anholt wrote:
>
> On Fri, Jan 7, 2022 at 6:18 AM Connor Abbott wrote:
> >
> > Unfortunately batch mode has only made it *worse* - I'm sure it's not
> > intentional, but it seems that it's still running the CI pipelines
&g
On Fri, Jan 7, 2022 at 3:18 PM Connor Abbott wrote:
>
> Unfortunately batch mode has only made it *worse* - I'm sure it's not
> intentional, but it seems that it's still running the CI pipelines
> individually after the batch pipeline passes and not merging them
>
Unfortunately batch mode has only made it *worse* - I'm sure it's not
intentional, but it seems that it's still running the CI pipelines
individually after the batch pipeline passes and not merging them
right away, which completely defeats the point. See, for example,
!14213 which has gone through
On Tue, Nov 17, 2020 at 9:56 PM Brian Paul wrote:
>
> On 11/17/2020 11:49 AM, Ian Romanick wrote:
> > On 11/17/20 9:25 AM, Brian Paul wrote:
> >>
> >> Using the Intel Vulkan driver, we've found some cases where SpvOpSelect
> >> is returning -0.0 (negative zeros) instead of normal 0.0 depending on
Why are you calling gl_nir_lower_samplers_as_deref twice? The entire
point of it is to deal with the crazy legacy GL model where samplers
are "just normal uniforms" that can be embedded in structs and calling
glUniform() can update the sampler binding. It doesn't touch samplers
with an explicit bin
As a drive-by comment, in case you didn't know, the "standard"
solution for avoiding flushing when BO's are written by the CPU (e.g.
uniform buffer updates) as documented in ARM's performance guide is to
add a copy-on-write mechanism, so that you have "shadow" BO's when the
original BO is modified
Fixes: c45f5db527252384395e55fb1149b673ec7b5fa8 ("nir/lower_io_to_temporaries:
Handle interpolation intrinsics")
---
Whoops...
src/compiler/nir/nir_lower_io_to_temporaries.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/compiler/nir/nir_lower_io_to_temporaries.c
b/src/compiler/nir/n
I haven't thought about whether it's algebraically correct, but
otherwise your pattern looks fine to me.
If you haven't noticed already, I added some commented out code to
nir_replace_instr() that will print out each pattern that's matched.
The first thing I'd do is move that up to the beginning o
inaccessiblememonly means that it doesn't modify memory accesible via
normal LLVM pointers. This lets LLVM's dead store elimination, memcpy
forwarding, etc. ignore functions with this attribute. We don't
represent descriptors as pointers, so this property is always true of
buffer and image stores.
While we're here, copy the comment explaining this from radeonsi.
---
src/amd/common/ac_nir_to_llvm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 833b1e54abc..11de22a8cbd 100644
--- a/src/amd/com
When e9d935ed0e2 added force_dcc_off(), we forced it off for any
preloaded image descriptor which had stores associated with them, since
the same preloaded descriptors were used for loads and stores. However,
when the preloading was removed in 16be87c9042, the existing logic was
kept despite it not
On Tue, Jun 4, 2019 at 4:24 PM Juan A. Suarez Romero
wrote:
>
> On Fri, 2019-05-31 at 14:55 +0200, Connor Abbott wrote:
> > Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM.
>
> Does it make sense to nominate this for stable release?
I don't think
Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM.
---
With this patch, we now have Piglit parity in debug mode.
src/gallium/drivers/radeonsi/si_shader_nir.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
At least on vim, indenting doesn't work without this. Copied from
src/amd/vulkan.
---
src/gallium/drivers/radeonsi/.editorconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeonsi/.editorconfig
b/src/gallium/drivers/radeonsi/.editorconfig
index cc8e11ffd65..21a3c7d12
"Resolve Discussion" button. This way the reviewer
knows which feedback got handled and which didn't.
I definitely didn't notice this when I started using Gitlab either.
With the fixed text:
Reviewed-by: Connor Abbott
On Thu, May 16, 2019 at 11:36 AM Alejandro Piñeiro wrote:
>
On Mon, May 13, 2019 at 4:48 PM Alyssa Rosenzweig wrote:
>
> > Using nir_gather_ssa_types is wrong. In both Midgard and NIR, SSA
> > values are just a bunch of bits with no int/float distinction, and
> > therefore you shouldn't need to know how a register is used to compile
> > the instruction pro
Using nir_gather_ssa_types is wrong. In both Midgard and NIR, SSA
values are just a bunch of bits with no int/float distinction, and
therefore you shouldn't need to know how a register is used to compile
the instruction producing it. The only distinction between imov and
fmov, in both NIR and the M
On Fri, May 10, 2019 at 11:47 AM Connor Abbott wrote:
>
>
> This way of representing liveness, and then using a coloring register
> allocator, is a common anti-pattern in Mesa, that was initially copied
> from i965 which dates back to before we knew any better. I really
> do
On Fri, May 10, 2019 at 11:09 AM Christian Gmeiner
wrote:
>
> Signed-off-by: Christian Gmeiner
> ---
> src/etnaviv/compiler/eir.h| 3 +
> src/etnaviv/compiler/eir_live_variables.c | 258 ++
> src/etnaviv/compiler/meson.build | 1 +
> .../c
On Mon, May 6, 2019 at 1:26 AM wrote:
>
> From: Ryan Houdek
>
> Adds Round, RoundEven, and the two Trunc variants to the disassembler.
> Additionally adds two control register types that were used with these
> instructions.
>
> Signed-off-by: Ryan Houdek
> ---
> src/gallium/drivers/panfrost/bif
On Sun, May 5, 2019 at 1:27 AM Alyssa Rosenzweig wrote:
>
> > The blend shader enable bit is already described in the comments in
> > the header; the blend shader is enabled when unk2 == 0.
>
> I'm pretty sure that comment was from you, but thank you ;)
>
> > (the blend shader has
> > to be alloca
On Sun, May 5, 2019 at 12:14 AM Alyssa Rosenzweig wrote:
>
> This commit does a fairly large cleanup of blend descriptors, although
> there should not be any functional changes. In particular, we split
> apart the Midgard and Bifrost blend descriptors, since they are
> radically different. From th
On Fri, May 3, 2019 at 10:39 PM Jason Ekstrand wrote:
> On Fri, May 3, 2019 at 3:29 PM Connor Abbott wrote:
>
>> FWIW, the reason I changed it away was to keep it consistent with the
>> line directly above that uses the length (since the C array won't exist if
>&
Baker wrote:
>
>> Quoting Connor Abbott (2019-05-02 13:34:07)
>> > Just don't emit the transform array at all if there are no transforms
>> > for a state, and avoid trying to walk over it.
>> > ---
>> > Brian, does this build on Windows? I tested it on
Just don't emit the transform array at all if there are no transforms
for a state, and avoid trying to walk over it.
---
Brian, does this build on Windows? I tested it on my shader-db
on radeonsi.
---
src/compiler/nir/nir_algebraic.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
di
Whoops, that should be "radeonsi with radeonsi_enable_nir=true" since NIR
isn't enabled by default yet.
On Thu, May 2, 2019 at 9:35 PM Connor Abbott wrote:
> This will crash at runtime, since it'll construct a "struct transform"
> with all NULL pointers, an
This will crash at runtime, since it'll construct a "struct transform" with
all NULL pointers, and then the loop below in ${pass_name}_block() will see
that there's one transform in the array since it uses ARRAY_SIZE and then
crash trying to access it.
Running piglit with i965, or radeonsi will re
On Fri, Mar 15, 2019 at 5:00 PM Ilia Mirkin wrote:
>
> On Fri, Mar 15, 2019 at 11:52 AM Connor Abbott
wrote:
> >
> > On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin
wrote:
> > >
> > > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig <
aly...@rosenzweig.io&g
On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin wrote:
>
> On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig
wrote:
> >
> > > This is needed if you can only handle point sprites on certain
> > > varyings but not others. This is the case for nv30- and nvc0-based
> > > GPUs, which is why the cap was i
On Thu, Feb 21, 2019 at 5:07 PM Alyssa Rosenzweig
wrote:
> > Yes, there is a buffer for holding the results of the tiler. The way it
> > works is that the userspace driver allocates a very large buffer with a
> > "grow on page fault" bit, so the kernel will allocate more memory as the
> > tiler a
On Thu, Feb 21, 2019 at 3:01 PM Rob Clark wrote:
> On Thu, Feb 21, 2019 at 1:19 AM Alyssa Rosenzweig
> wrote:
> >
> > For reasons that are still unclear (speculation included in the comment
> > added in this patch), the tiler? metadata has a fast path that we were
> > not enabling; there looks t
On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák wrote:
> On Tue, Feb 19, 2019 at 7:57 PM Rob Clark wrote:
>
>> On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák wrote:
>> >
>> > st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
>> >
>> > nir_validate_shader 49%
>> >
>> > nir_validate_shade
On Tue, Feb 19, 2019 at 5:33 PM Emil Velikov
wrote:
> On Fri, 15 Feb 2019 at 21:39, Alyssa Rosenzweig
> wrote:
> >
> > > - about 1/5 of the patch seems to be white space changes
> >
> > ...Oops. Any tips for avoiding this type of diff churn in the future? I
> > suppose it's not inherently harmfu
Reviewed-by: Connor Abbott
I agree that if we ever need to bring this back, we should just check for
both branches empty and no phis afterwards.
On Thu, Feb 14, 2019 at 2:38 AM Timothy Arceri
wrote:
> This was probably useful when it was first written, however it
> looks to be no
Reviewed-by: Connor Abbott
I'm a bit surprised it's that slow... do you have any idea what's going on?
I've made flamegraphs in the past on i965 to see where most of the time is
spent.
On Wed, Feb 13, 2019 at 9:00 AM Timothy Arceri
wrote:
> Currently the radeonsi N
On Wed, Feb 6, 2019 at 11:46 AM Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> According to Vulkan spec, the new execution modes affect only
> correctly rounded SPIR-V instructions, which includes fadd,
> fsub and fmul.
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/compile
I think maybe it would be better if we put all this in nir_opcodes.py
instead. Again, I'd like to make sure that for every opcode, what it does
is right next to the definition instead of buried in
nir_constant_expressions.py.
Also, I don't see anywhere in the series where you handle different
roun
On Tue, Dec 18, 2018 at 11:35 AM Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> v2:
> - Refactor conditions and shared function (Connor)
> - Move code to nir_eval_const_opcode() (Connor)
> - Don't flush to zero on fquantize2f16
> From Vulkan spec, VK_KHR_shader_float_controls section
On Mon, Dec 10, 2018 at 2:20 PM Samuel Iglesias Gonsálvez
wrote:
>
> On 05/12/2018 19:22, Connor Abbott wrote:
> > Why is this needed? In general, we shouldn't be relying on
> > optimization ordering for correctness. It probably just means one of
> > the optimizations
b2i can now take any size boolean in preparation for 1-bit booleans, so
the error message printed is slightly different.
Fixes: dca6cd9ce65 ("nir: Make boolean conversions sized just like the others")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108961
Cc: Jason Ekstrand
---
src/compil
On Fri, Dec 7, 2018 at 1:16 AM Ian Romanick wrote:
>
> On 12/05/2018 10:12 AM, Connor Abbott wrote:
> > This won't work, since this optimization in nir_opt_algebraic will undo it:
> >
> > # For any float comparison operation, "cmp", if you have "a
Is this going to be used by an extension? If you don't have a use for
it yet, it would probably be better to wait.
On Thu, Dec 6, 2018 at 3:01 PM Nicolai Hähnle wrote:
>
> From: Nicolai Hähnle
>
> Order-aware scan/reduce can trade-off LDS traffic for external atomics
> memory traffic in producer/
I had a look, and this series is
Reviewed-by: Connor Abbott
I think I already reviewed at least part of your 1-bit-boolean series,
and had some feedback, but I'm done reviewing for today :)
On Fri, Nov 30, 2018 at 12:37 AM Jason Ekstrand wrote:
>
> This is mostly a re-send of my ear
All the current lowerings produce their result using a floating-point
multiply or add, so denorms should already be flushed (e.g.
nir_op_frcp), or they never produce a denorm (e.g. nir_op_ftrunc), so
I don't think this is necessary.
On Wed, Dec 5, 2018 at 4:56 PM Samuel Iglesias Gonsálvez
wrote:
>
On Wed, Dec 5, 2018 at 4:56 PM Samuel Iglesias Gonsálvez
wrote:
>
> According to VK_KHR_shader_float_controls:
>
> "Denormalized values obtained via unpacking an integer into a vector
> of values with smaller bit width and interpreting those values as
> floating-point numbers must: be flushed to
Why is this needed? In general, we shouldn't be relying on
optimization ordering for correctness. It probably just means one of
the optimizations is wrong, and you're working around that.
On Wed, Dec 5, 2018 at 4:56 PM Samuel Iglesias Gonsálvez
wrote:
>
> This would do constant folding and also fl
On Wed, Dec 5, 2018 at 4:56 PM Samuel Iglesias Gonsálvez
wrote:
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/compiler/nir/nir.h | 15 +++
> src/compiler/nir/nir_constant_expressions.py | 46 +---
> src/compiler/spirv/vtn_alu.c
This is not acceptable, since this will disable the optimization even
when it would otherwise be allowed. Either we need to mark everything
as precise if one of these execution modes are enabled, or we need to
disable this optimization only if the appropriate preserve-NaN-and-Inf
mode is set.
On We
This won't work, since this optimization in nir_opt_algebraic will undo it:
# For any float comparison operation, "cmp", if you have "a == a && a cmp b"
# then the "a == a" is redundant because it's equivalent to "a is not NaN"
# and, if a is a NaN then the second comparison will fail anyway.
for
Given that other places call nir_eval_const_opcode(), and they'll be
broken unless they also flush denorms, it's probably a good idea to
move all this into nir_eval_const_opcode() itself.
On Wed, Dec 5, 2018 at 4:56 PM Samuel Iglesias Gonsálvez
wrote:
>
> Signed-off-by: Samuel Iglesias Gonsálvez
Before this commit, there were two copies of the algorithm: one in C,
that we would use to figure out what bit-size to give the replacement
expression, and one in Python, that emulated the C one and tried to
prove that the C algorithm would never fail to correctly assign
bit-sizes. That seemed pret
On Mon, Dec 3, 2018 at 11:39 PM Dylan Baker wrote:
>
> Quoting Jason Ekstrand (2018-12-03 14:12:41)
> > On Mon, Dec 3, 2018 at 3:50 PM Dylan Baker wrote:
> >
> > Quoting Connor Abbott (2018-11-29 10:32:02)
> > > Before this commit, there were two
Before this commit, there were two copies of the algorithm: one in C,
that we would use to figure out what bit-size to give the replacement
expression, and one in Python, that emulated the C one and tried to
prove that the C algorithm would never fail to correctly assign
bit-sizes. That seemed pret
On Sat, Dec 1, 2018 at 3:22 PM Samuel Pitoiset
wrote:
>
> I'm not saying this series is the right thing to do. It just fixes two
> test failures in the vkd3d testsuite for RADV. I added a new compiler
> option to not break anything and to only affects RADV. Anyways, it seems
> unclear what the bes
On Fri, Nov 30, 2018 at 10:18 PM Ian Romanick wrote:
>
> On 11/29/2018 07:47 AM, Connor Abbott wrote:
> > On Thu, Nov 29, 2018 at 4:22 PM Jason Ekstrand wrote:
> >>
> >> Can you provide some context for this? Those rules are already flagged
> >> &quo
The non-failure path can be tested by just compiling mesa and then
testing it, but the failure paths won't be hit unless you make a mistake,
so it's best to test them with some unit tests.
---
src/compiler/Makefile.nir.am | 4 +-
src/compiler/nir/meson.build |
SizeValidator, since that part of the diff won't be too helpful.
Finally, I haven't actually tested the compiled mesa, but I'm working on
it :) It would be good to give this a run through the Intel CI.
Connor Abbott (2):
nir/algebraic: Rewrite bit-size inference
nir/algebraic: Add
Before this commit, there were two copies of the algorithm: one in C,
that we would use to figure out what bit-size to give the replacement
expression, and one in Python, that emulated the C one and tried to
prove that the C algorithm would never fail to correctly assign
bit-sizes. That seemed pret
On Thu, Nov 29, 2018 at 4:47 PM Connor Abbott wrote:
>
> On Thu, Nov 29, 2018 at 4:22 PM Jason Ekstrand wrote:
> >
> > Can you provide some context for this? Those rules are already flagged
> > "inexact" (that's what the ~ means) so they won'
On Thu, Nov 29, 2018 at 4:22 PM Jason Ekstrand wrote:
>
> Can you provide some context for this? Those rules are already flagged
> "inexact" (that's what the ~ means) so they won't apply to anything that's
> "precise" or "invariant".
I think the concern is that this isn't allowed in SPIR-V, ev
I don't see this working where there are any phi nodes involved. The
variable pointers spec says that you can use pointers with phi nodes.
Currently we just create a plain integer type, so this will fall over.
Are there any CTS tests that phi nodes which don't get removed by
nir_opt_peephole_sel?
This will cause the assert to pass when it shouldn't in some cases
with a 32-bit bitsize, and seems like a hack since it's subverting the
point of the assert, which is guarantee that we won't lose any
information by truncating the source. It would be better to fix the
caller that's hitting the asse
On Mon, Nov 12, 2018 at 9:34 PM Bas Nieuwenhuizen
wrote:
>
> On Mon, Nov 12, 2018 at 5:55 PM Samuel Pitoiset
> wrote:
> >
> > This allows to fast clear the depth part (or the stencil part)
> > of a depth+stencil surface when HTILE is enabled. I didn't test
> > on GFX8, so it's disabled currently.
I quickly looked through the users of glsl_get_bit_size, and here are
the ones I found that still have to be fixed up:
- vtn_type_layout_430()
- vtn_type_block_size() in vtn_variables.c
- our OpBitcast implementation, although I don't think we can see
booleans there? (Also, it doesn't handle 8 and
On Tue, Oct 23, 2018 at 12:16 AM Jason Ekstrand wrote:
>
> This commit adds support for 1-bit booleans and integers. Booleans
> obviously take a value of true or false. Because we have to define the
> semantics of 1-bit signed and unsigned integers, we define uint1_t to
> take values of 0 and 1
On Tue, Nov 6, 2018 at 1:45 PM Pohjolainen, Topi
wrote:
>
> On Tue, Nov 06, 2018 at 11:31:58AM +0100, Connor Abbott wrote:
> > On Tue, Nov 6, 2018 at 11:14 AM Pohjolainen, Topi
> > wrote:
> > >
> > > On Tue, Nov 06, 2018 at 10:45:52AM +0100, Connor Abbott w
On Tue, Nov 6, 2018 at 11:31 AM Connor Abbott wrote:
>
> On Tue, Nov 6, 2018 at 11:14 AM Pohjolainen, Topi
> wrote:
> >
> > On Tue, Nov 06, 2018 at 10:45:52AM +0100, Connor Abbott wrote:
> > > As far as I understand, mediump handling can be split into two parts:
>
On Tue, Nov 6, 2018 at 11:14 AM Pohjolainen, Topi
wrote:
>
> On Tue, Nov 06, 2018 at 10:45:52AM +0100, Connor Abbott wrote:
> > As far as I understand, mediump handling can be split into two parts:
> >
> > 1. Figuring out which operations (instructions or SSA values in
As far as I understand, mediump handling can be split into two parts:
1. Figuring out which operations (instructions or SSA values in NIR)
can use relaxed precision.
2. Deciding which relaxed-precision operations to actually compute in
16-bit precision.
At least for GLSL, #1 is pretty well nailed
ctx->f32_1 probably needs to be replaced by the appropriately-sized
float, like LLVMConstReal(1., ...)
On Mon, Oct 29, 2018 at 11:45 AM Timothy Arceri wrote:
>
> Hi Marek,
>
> It's late and I haven't dug into this any further but this patch causes
> a whole bunch of f64 piglit tests to fail for th
On Tue, Oct 23, 2018 at 12:16 AM Jason Ekstrand wrote:
>
> This should be useful for drivers that don't support real integers.
>
> Cc: Alyssa Rosenzweig
> ---
> src/compiler/Makefile.sources | 1 +
> src/compiler/nir/meson.build | 1 +
> src/compiler/nir/nir_lower_
On Tue, Oct 23, 2018 at 12:16 AM Jason Ekstrand wrote:
>
> D3D booleans use a 32-bit 0/-1 representation. Because this previously
> matched NIR exactly, we didn't have to really optimize for it. Now that
> we have 1-bit booleans, we need some specific optimizations to chew
> through the D3D12-st
And implement ac_bulid_expand_to_vec4() on top of it.
Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for 16bit
buffer loads")
---
src/amd/common/ac_llvm_build.c | 40 ++
src/amd/common/ac_llvm_build.h | 3 +++
2 files changed, 29 insertions(+),
This reverts commit 647c2b90e96a9ab8571baf958a7c67c1e816911a. There was
one recently-introduced bug in ac for dvec3 loads, but the other test
failures were actually bugs in the tests. See
https://github.com/cwabbott0/VK-GL-CTS/tree/voteallequal-fixes
---
src/amd/vulkan/radv_device.c | 6 ++
1
The comment was wrong, since the loop above casts to a type with the
correct bitsize already.
Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for 16bit
buffer loads")
---
src/amd/common/ac_nir_to_llvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src
On Mon, Oct 15, 2018 at 8:41 PM Jason Ekstrand wrote:
>
> On Mon, Oct 15, 2018 at 1:39 PM Ian Romanick wrote:
>>
>> On 10/14/2018 03:58 PM, Jason Ekstrand wrote:
>> > On October 14, 2018 17:12:34 Matt Turner wrote:
>> >> +static nir_ssa_def *
>> >> +lower_iabs64(nir_builder *b, nir_ssa_def *x)
>
On Thu, Jul 19, 2018 at 10:24 AM, Timothy Arceri wrote:
> On 19/07/18 12:02, Connor Abbott wrote:
>>
>> Why not do the more general thing, and evaluate the condition in every
>> block dominated by the then and else blocks? That should handle the
>> loop and non-loop c
Why not do the more general thing, and evaluate the condition in every
block dominated by the then and else blocks? That should handle the
loop and non-loop cases.
On Thu, Jul 19, 2018 at 8:06 AM, Timothy Arceri wrote:
> Since we know what side of the branch we ended up on we can just
> replace t
On Sat, Apr 14, 2018 at 3:39 PM, Erico Nunes wrote:
> On Sat, Apr 14, 2018 at 9:26 PM, Jason Ekstrand wrote:
>> Reviewed-by: Jason Ekstrand
>>
>> What driver is hitting this path? The !supports_ints path isn't used to my
>> knowledge so if some driver has started using it, they're liable to fin
On Sat, Mar 24, 2018 at 6:00 PM, Jason Ekstrand wrote:
> On Sat, Mar 24, 2018 at 2:27 PM, Marek Olšák wrote:
>>
>> On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott
>> wrote:
>>>
>>> If Gallium was being lazy and not
>>> specifying the bounds
My understanding is that unlike most other architectures, Mali does
vertex shading on every vertex up-front, completely ignoring the index
buffer. Primitive assembly and tile binning happen after every vertex
is transformed. There is no cache of transformed vertices. Utgard also
only supports GLES2
On Wed, Mar 14, 2018 at 6:07 PM, Rob Clark wrote:
> On Wed, Mar 14, 2018 at 7:42 PM, Connor Abbott wrote:
>> On Wed, Mar 14, 2018 at 5:05 PM, Rob Clark wrote:
>>> On Wed, Mar 14, 2018 at 4:58 PM, Connor Abbott wrote:
>>>> FWIW, the way I imagined doing this was so
On Wed, Mar 14, 2018 at 5:05 PM, Rob Clark wrote:
> On Wed, Mar 14, 2018 at 4:58 PM, Connor Abbott wrote:
>> FWIW, the way I imagined doing this was something like:
>>
>> 1. Add nir_deref_instr and nir_deref_type_pointer. At this point, just
>> make everything asser
FWIW, the way I imagined doing this was something like:
1. Add nir_deref_instr and nir_deref_type_pointer. At this point, just
make everything assert if the base deref isn't a nir_deref_var. This
will be a bit of a flag-day, but also very mechanical. It'll also help
us catch cases where we don't h
Floating point division shouldn't signal on division by zero, it
should just return an appropriately-signed infinity, which seems like
a sane thing to do, and way better than just returning 0. So we
shouldn't do this with fdiv. I guess 0 is as good a result as any for
the integer division, though -
Why not just use LLVMConstNull()?
On Mon, Feb 26, 2018 at 12:14 AM, Timothy Arceri wrote:
> ---
> src/amd/common/ac_llvm_build.c | 15 +++
> src/amd/common/ac_llvm_build.h | 3 +++
> 2 files changed, 18 insertions(+)
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/a
Yes, this is the right ordering for NIR (and GLSL) comparisons.
Reviewed-by: Connor Abbott
On Fri, Feb 23, 2018 at 8:21 AM, Samuel Pitoiset
wrote:
> Original patch from Timothy Arceri, I have just fixed the
> not equal case locally.
>
> This fixes one important rendering issue in W
On Fri, Feb 23, 2018 at 8:30 AM, Bas Nieuwenhuizen wrote:
>
>
> On Thu, Feb 15, 2018 at 8:54 AM, Connor Abbott wrote:
>>
>> On Wed, Feb 14, 2018 at 11:53 PM, Timothy Arceri
>> wrote:
>> >
>> >
>> > On 15/02/18 04:39, Marek Olšák wrote:
&
On Wed, Feb 21, 2018 at 3:03 PM, Daniel Schürmann
wrote:
>
>> On Wed, Feb 21, 2018 at 1:00 PM,
>> wrote:
>>>
>>> From: Dave Airlie
>>>
>>> Co-authored-by: Daniel Schürmann
>>> Signed-off-by: Daniel Schürmann
>>> ---
>>> src/amd/common/ac_llvm_build.c| 3 +-
>>> src/amd/common/ac_nir_t
On Wed, Feb 21, 2018 at 3:13 PM, Connor Abbott wrote:
> On Wed, Feb 21, 2018 at 3:03 PM, Daniel Schürmann
> wrote:
>>
>>> On Wed, Feb 21, 2018 at 1:00 PM,
>>> wrote:
>>>>
>>>> From: Dave Airlie
>>>>
>>&
On Wed, Feb 21, 2018 at 1:00 PM, wrote:
> From: Dave Airlie
>
> Co-authored-by: Daniel Schürmann
> Signed-off-by: Daniel Schürmann
> ---
> src/amd/common/ac_llvm_build.c| 3 +-
> src/amd/common/ac_nir_to_llvm.c | 39 ++
> src/amd/vulkan/radv_extensions.py | 1 +
>
On Tue, Feb 20, 2018 at 2:06 PM, Daniel Schürmann
wrote:
> From: Dave Airlie
>
> Signed-off-by: Daniel Schürmann
> ---
> src/amd/common/ac_nir_to_llvm.c | 51 +++
> src/amd/vulkan/radv_extensions.py | 1 +
> src/compiler/nir/meson.build | 1 +
> src/compiler
On Wed, Feb 14, 2018 at 11:53 PM, Timothy Arceri wrote:
>
>
> On 15/02/18 04:39, Marek Olšák wrote:
>>
>> Reviewed-by: Marek Olšák
>>
>> Marek
>>
>> On Wed, Feb 14, 2018 at 7:29 AM, Timothy Arceri
>> wrote:
>>>
>>> Fixes glsl-1.30/execution/isinf-and-isnan* piglit tests for
>>> radeonsi and shou
On Mon, Dec 11, 2017 at 11:01 AM, Jason Ekstrand wrote:
> On Mon, Dec 11, 2017 at 12:55 AM, Iago Toral wrote:
>>
>> This didn't get any reviews yet. Any takers?
>>
>> On Fri, 2017-12-01 at 13:46 +0100, Iago Toral Quiroga wrote:
>> > Otherwise loop unrolling will fail to see the actual cost of
>>
When I was talking about handling I/O for radeonsi NIR with Nicolai, I
think the conclusion was that the best way forward is to make the
driver call nir_lower_io and friends, at least for inputs and outputs.
This is a perfect example of the kind of hacks that we have to do --
precisely how to handl
On Wed, Jan 10, 2018 at 3:27 PM, Ilia Mirkin wrote:
> On Wed, Jan 10, 2018 at 3:13 PM, Gert Wollny wrote:
>> Am Mittwoch, den 10.01.2018, 16:36 +0100 schrieb Gert Wollny:
>>> This seems to satisfy the sb optimizer, i.e. no regressions in the
>>> piglits compared to disabling sb for tesselation sh
In order to reduce moves when coalescing multiple registers into a
larger register, RA will try to coalesce MERGE instructions with their
definitions. For example, for something like this in GLSL:
uint a = ...;
uint b = ...;
uint64 x = packUint2x32(a, b);
The compiler will try to coalesce x with
1 - 100 of 1264 matches
Mail list logo
