[Mesa-dev] [PATCH 00/11] TGSI support for input and output array declarations

[Marek Olšák]

Testing is really easy. Just run all piglit variable-indexing tests.
Also, drivers don't have to do anything for outputs yet, because those
are always moved to temps by lower_output_reads.

Marek

On Sun, May 24, 2015 at 6:22 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> Right, but you're changing what the driver receives, so we should make
> sure they all handle it correctly. Or let the major driver authors
> know what's going on so they can test it out and fix their driver
> accordingly. Perhaps find a couple of piglit tests that exercise the
> functionality. On that note, I should probably check what nouveau
> does, esp on nv30...
>
> On Sun, May 24, 2015 at 12:15 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> Drivers that only use tgsi_shader_info won't break.
>>
>> Drivers that process tgsi_full_declaration manually and interpret
>> Range.First .. Range.Last correctly won't break either.
>>
>> A driver can only break if it doesn't handle Range.Last correctly. If
>> that's the case, the driver should be fixed, because this is a basic
>> TGSI feature that has always been there.
>>
>> Marek
>>
>> On Sun, May 24, 2015 at 5:45 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> While I'm all for doing this, won't this break every driver if it no
>>> longer has all the decl's? It'll take special logic to convert
>>>
>>> DECL IN[0..5], GENERIC[0]
>>>
>>> into
>>>
>>> DECL IN[0], GENERIC[0]
>>> DECL IN[1], GENERIC[1]
>>> etc
>>>
>>> Perhaps this should be guarded by a cap? Or an audit of all drivers
>>> should be done?
>>>
>>> On Sun, May 24, 2015 at 7:19 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> The reason I add this is that TGSI doesn't allow indirect indexing of inputs and outputs. Consider this:
>>>>
>>>> MOV OUT[ADDR[0]-1000], IMM[0]
>>>>
>>>> There is no way to know where the output array starts here. It could be for example OUT[6]=GENERIC4 or anything else. The problem is some outputs are physically stored in a different memory domain than others. Per-patch (tessellation) outputs are one such example. Does the MOV instruction write a per-vertex or per-patch output? There is no way to know.
>>>>
>>>> The problem can be avoided by using carefully-generated unoptimized TGSI where the relative index is the same as the base of the array, which is OUT[6] here:
>>>>
>>>> UADD TEMP[0].x, TEMP[0].x, -1006
>>>> UARL ADDR[0], TEMP[0].x
>>>> MOV OUT[ADDR[0]+6], IMM[0]
>>>>
>>>> This hack helps for this case, but the drivers which do move outputs to temps are still unable to allocate registers efficiently, because there is no way to know the actual array size.
>>>>
>>>> This patch series adds proper TGSI support for IN/OUT arrays. It works in the same way as temp arrays and it's a requirement for tessellation.
>>>>
>>>> Please review.
>>>>
>>>> Marek
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev