On Sun, Jan 7, 2018 at 7:24 PM, Connor Abbott <cwabbo...@gmail.com> wrote:
> 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?
Adjacent register pairs, starting with an even regsister (in all but
the oddest of cases... like the 64-bit SHL inputs). Also 128-bit
groups can end up being used (for "wide" loads/stores as well as
texture arguments). And on nv50, 16-bit values are a thing (in fact
every reg is "half" addressable, al/ah-style, but only a tiny handful
of operations can make use of that, notably integer mul, for which
there is no 32-bit variant).
>
> It sounds like the current approach is doing something wrong. The
Oh, yeah, it's totally a bug in the RA. My observation was that it's
easy to work around, and difficult to fix RA.
> 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.
In case you're curious,
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp#n1367
That's the assert being hit. Basically the idea is that you have
LValue's, and when they're coalesced (as they are when you have a
phi), one copies the defs from one list to another. This assert is
complaining about some defs being "compound" LValue's, and others not.
I haven't the faintest clue what "compound" means, unfortunately, or
why this check is there, or what the precise handling of compounds is.
Fixing this particular issue will require someone to dig into it.
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
