[Mesa-dev] [PATCH 2/4] gallium: Add PIPE_SHADER_CAP_INDIRECT_TEMP_ARRAY_ADDR

Marek Olšák maraeo at gmail.com
Sun Nov 25 18:44:29 PST 2012


On Mon, Nov 26, 2012 at 12:28 AM, Christoph Bumiller
<e0425955 at student.tuwien.ac.at> wrote:
> On 25.11.2012 23:31, Marek Olšák wrote:
>> On Thu, Nov 8, 2012 at 7:08 PM, Christoph Bumiller
>> <e0425955 at student.tuwien.ac.at> wrote:
>>> DCL TEMP[0..3] = "array" without indirect access (registers)
>>> DCL TEMP[4..12] = indirectly accessed array
>>> DCL TEMP[12..20] = another indirectly accessed array
>>> DCL IMM[0] { -2, 0, 0, 0 }
>>>
>>> fill with data:
>>> MOV TEMP[4], IN[1]
>>> MOV TEMP[5], IN[2]
>>> etc.
>>>
>>> indirect move with address (IN[0].x - 2) from array TEMP[4..12] to output:
>>> UADD TEMP[0].x, IN[0].x, IMM[0].x <- added here explicitly instead of
>>> using (4 - IMM[0].x == 2) in the MOV below
>>> UARL ADDR[0].x, TEMP[0].x
>>> MOV OUT[1], TEMP[ADDR[0].x + 4] <- must be 4 here to identify the
>>> array/range (iff there is indirect addressing)
>> I don't like this. It looks hackish. I think it would be better to
>> have the array clearly specified in the declaration and in the
>> instruction. For example like this:
> Of course it looks hackish, if you want to add a new (3rd) index field
> to TGSI sources and declarations you're welcome to do so.
> I really want a solution that doesn't just work for TEMPs but also the
> other files, especially INPUT and OUTPUT, where the 2nd index is already
> taken (vertex index, in geometry and tessellation shaders), otherwise
> someone will have to do this all over again at a later point.

I'd be okay with the 3rd index, but making even cosmetic changes to
the gallium interface is really a lot of work. Exposing changes in
the interface through a new cap and unused TGSI file seems more reasonable.

>
> Btw. for non-vec4 arrays we can use the UsageMask and e.g. declare a
> scalar array with TEMP[0][0..3].x so the driver can pack it.

Yes, we could use UsageMask, but allowing register allocation with
temporary arrays is more important at the moment.

Marek


More information about the mesa-dev mailing list