On Sun, Jan 7, 2018 at 6:50 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Sun, Jan 7, 2018 at 6:39 PM, Connor Abbott <cwabbo...@gmail.com> wrote:
>> On Sun, Jan 7, 2018 at 3:42 PM, Karol Herbst <kher...@redhat.com> wrote:
>>> significant changes to last series:
>>> * disable support for 64 bit types
>>> * fix tessellation shader bugs
>>> * assume vec4 elements for variable index arrays (MemoryOpts workaround)
>>>
>>> piglit run -x glx -x egl -x streaming-texture-leak -x max-texture-size
>>> tests/gpu.py:
>>> [26010/26010] skip: 10410, pass: 15386, warn: 9, fail: 191, crash: 14
>>>
>>> remaining issues:
>>> * transform feedback with geometry shaders
>>> * indirects in image_load/store
>>> * interpolateAt
>>> * getting 64 bit types to work. This is mainly limited by codegen RA being
>>> not able to handle those correctly, because from_TGSI just generates merge
>>> and splits and doesn't hit the faulty paths.
>>
>> Just curious... what's the issue with register allocation?
>
> There are probably a few, but at least one is that it wants both sides
> of a phi to be compounds (or neither). So if you have e.g.
>
> x int64;
> if (foo) {
> x = a + b;
> } else {
> x = (c, d) [i.e. high word is one, low word is the other]
> }
> use(x)
>
> Then you may end up with a 64-bit phi, with one of the arguments that
> is a compound (the merge), and one of which isn't. The RA doesn't
> handle that situation.
>
> I believe currently we have enough splits/merges that everything
> that's 64-bit ends up being marked as a compound.
>
> I wonder if we can "just do that" for 64-bit values - i.e. auto-mark
> them as compound. It all requires carefully figuring out how RA works
> with all of this.
How are 64 bit values handled on nvidia? Can you join any 2 32-bit
registers to get a 64-bit one? Or do they have to be contiguous to use
the 64-bit ops? Or are there separate 64-bit registers entirely? Or
something else entirely?
It sounds like the current approach is doing something wrong. The
example you mentioned shouldn't be too hard to handle. Typically, you
have something like packUint2x32() and unpackUint2x32() in GLSL as
built-in pseudoinstructions that get expanded after RA, and then the
output of packUint2x32 is just a regular ol' 64-bit value, and the
register allocator shouldn't care one bit about where that value came
from - it should handle both sides of your if statement pretty much
identically. Basically, it's a funky kind of move. If you want to
coalesce the packUint2x32 before RA in your example, then things get a
little trickier since 32-bit registers might interfere with a
subregister of x. But that can come later.
>
> -ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
