[Mesa-dev] TGSI texture offset handling
Christoph Bumiller
e0425955 at student.tuwien.ac.at
Fri Aug 26 12:23:50 PDT 2011
On 26.08.2011 20:57, Ian Romanick wrote:
> On 08/26/2011 09:26 AM, Dave Airlie wrote:
> > I've involuntarily started looking into this when I tried to add TXF
> > support, so we need to expand TGSI to add support for texture offsets.
>
> > Requirements:
> > the extreme requirement so far is for textureGatherOffsets which can
> > accept 4 x ivec2, the normal textureFetchOffset can accept an ivec3.
> > The hardware seems to only tolerate -8..+7 ranges, but the interface
> > is quite open and as Brian pointed out its queryable.
>
> It's queryable, but nobody supports anything other than [-8, 7].
>
> > So adding extra src regs doesn't seem like the right answer going
> > forward (my last TXF patch did that). It really looks like expanding
> > the tgsi_instruction_texture token is the best plan, but it really
> > doesn't have the space to store 4 * ivec2 in it. Adding a new
> > tgsi_instruction_offset token with the values in it doesn't really
> > work so well either, since the GLSL compiler gives us ir_constant and
> > we parse those into the immediates file.
>
> > My current plan looks like
>
> > struct tgsi_instruction_texture
> > {
> > unsigned Texture : 8; /* TGSI_TEXTURE_ */
> > unsigned OffsetNum : 4;
> > unsigned OffsetFile : 4;
> > };
>
> > struct tgsi_instruction_offset
> > {
> > int Index:16;
> > unsigned SwizzleX : 2; /* TGSI_SWIZZLE_x */
> > unsigned SwizzleY : 2; /* TGSI_SWIZZLE_x */
> > unsigned SwizzleZ : 2; /* TGSI_SWIZZLE_x */
> > };
>
> What's the advantage of this (combined with
> tgsi_instruction_texture::OffsetFile) versus just encoding some number
> of pairs of small, signed integers? Each offset is a signed 4-bit
> value, so you can pack all four pairs in a single 32-bit value (it's
> almost like the hardware guys planned it that way).
>
> If I had to guess, I'd wager that if the ranges change, they will change
> to be arbitrary, non-constant values. Adding flexibility to have larger
> constant values seem unlikely to have future payoff.
>
It would be perfect ... if only D3D11 didn't allow non-constant values.
Although I'm not sure how to interpret the line "Support for
programmable offsets", and GLSL4.2 still requires them to be constant.
NVC0 (Fermi) supplies them (all of them) in a 32 bit register so
theoretically they need not be.
Maybe we choose to ignore that for now ... ?
> > Where OffsetFile will most likely be always the IMMEDIATE file, then
> > we just add 4 tgsi_instruction_offset to tgsi_full_instruction and go
> > from there.
>
> > Anyone see any problems with this? I'm sure someone will have an
> > alternate method that I've tried today and given up on.
>
> >
> http://people.freedesktop.org/~cbrill/dri-log/index.php?date=2011-08-26&channel=dri-devel&highlight_names=&date=2011-08-26
> > has some of the other ideas myself and calim have been back and
> > forwarding on today.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list