[Mesa-dev] [PATCH 04/15] i965/fs: Get rid of reladdr
Matt Turner
mattst88 at gmail.com
Thu Dec 10 12:39:44 PST 2015
On Thu, Dec 10, 2015 at 11:11 AM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>
> On Dec 10, 2015 6:58 AM, "Francisco Jerez" <currojerez at riseup.net> wrote:
>>
>> Jason Ekstrand <jason at jlekstrand.net> writes:
>>
>> > We aren't using it anymore.
>>
>> It seems useful to me to be able to represent indirect access as part of
>> any instruction source or destination register.
>>
>> The following:
>>
>> | mov_indirect g0, g1, a0
>> | foo g2, g0
>>
>> and the converse case with indirect destination offset (which you don't
>> seem to represent currently) can be implemented by the hardware more
>> efficiently using a single instruction in certain cases. The current IR
>> is able to represent what the hardware can do, but supporting the
>> MOV_INDIRECT instruction only would force us to keep the indirection
>> separate from the instruction that uses it, so it seems like a less
>> expressive representation to me than the current approach, unless you're
>> willing to add _INDIRECT variants of most hardware opcodes.
>
> Yes and, mostly, no. Yes, you can put an indirect on almost anything but it
> has substantial restrictions:
>
> 1) Destination indirects must be uniform (I'm only 95% sure this is the
> case)
Almost true. The Register Region Restrictions page gives an example:
> // Example:
> mov (16) r[a0.0]:f r10:f
> // The above instruction behaves the same as the following two instructions:
> mov (8) r[a0.0]:f r10:f
> mov (8) r[a0.1]:f r11:f
But that's all you get -- you still have to use 1x1 mode.
And that behavior changes on BDW:
> // Example:
> mov (16) r[a0.0]:f r10:f
> // The above instruction behaves the same as the following two instructions:
> mov (8) r[a0.0]:f r10:f
> mov (8) r[a0.0, 8*4]:f r11:f
The BRW_VERTICAL_STRIDE_ONE_DIMENSIONAL (0xF) vertical stride is
necessary for Vx1 or VxH, and the destination does not have vertical
stride. It's also not usable in align16 mode or on src1.
More information about the mesa-dev
mailing list