On Thu, Apr 2, 2015 at 1:32 PM, Rob Clark <robdcl...@gmail.com> wrote:
> On Thu, Apr 2, 2015 at 1:24 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
>> On Thu, Apr 2, 2015 at 1:20 AM, Kenneth Graunke <kenn...@whitecape.org>
>> wrote:
>>> On Wednesday, April 01, 2015 07:22:40 PM Connor Abbott wrote:
>>>> I think it might be better here if we had a callback that backends can
>>>> fill in that tells you when an instruction can be pulled out by the
>>>> sel peephole. As Jason noted, you won't be able to do this for
>>>> everything (notably, output writes and variable writes) and we'll
>>>> probably need special handling for predicating discards if we want to
>>>> be able to flatten everything. There are also a few cases where on
>>>> i965 we aren't activating it when we could. Even then, I didn't think
>>>> we'd need something this general, but with different backends with
>>>> such varying needs I guess it makes more sense to go with the more
>>>> general solution.
>>>
>>> NIR does have nir_intrinsic_discard_if, which performs a conditional
>>> discard. Assignments can be handled by conditional selects. In the
>>> absence of other memory writes (atomics, images, etc), that's probably
>>> sufficient, no?
>>
>> Yes, that should be sufficient assuming array accesses can be
>> flattened etc. However, the NIR pass shouldn't flatten things that
>> can't be flattened so we don't generate wrong NIR. Instead, in those
>> cases, we should just let the backend die on control-flow.
>
> right.. I'll have a go at hoisting things out that can be moved (like
> kill -> kill_if and change writes to output to writes to var and then
> select before write to output).. for things that can't be moved, let
> the backend fail.. doubtful a backend that doesn't support flow
> control will support atomics and other 'fancy stuff' anyways ;-)
Well, the one other thing is relative addressing... how does that work
with your HW? I know you support it, but if I do something like:
if(...) {
foo[i] = bar;
}
? Is it just a conditional move of all the elements of foo? In any
case, we don't lower indirect addressing to SSA in NIR, so there's no
way we could flatten it there.
>
> (which.. does makes me wonder how I'll eventually deal w/ atomics vs
> instruction scheduling.. maybe I can split them out into a separate
> unconditional successor basic block since at that point I'd be doing
> instruction scheduling at the basic block level. I think.)
>
> BR,
> -R
>
>
>> --Jason
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
