[Mesa-dev] [RFC PATCH 3/4] mesa: Prefer non-swizzled formats when prefer_no_swizzle set

[Francisco Jerez]

Chris Forbes <chrisf at ijw.co.nz> writes:

> Hi Michel, and thanks for the quick feedback.
>
> This is why it's tagged RFC :)
>
> After thinking about it a bit more, I'm not convinced it's the right
> thing either.
>
> You're right, the spec is very careful not to say anything about the
> memory layout. The 4.2 core profile spec, section 3.9.20 defines
> reinterpretation of texels in a roundabout way to avoid having to
> specify the memory layout:
>
> "
>     The re-interpretation for image
>     loads and the read portion of image atomics is performed as though data were
>     copied from the texel of the bound texture to a similar texel
> represented in the
>     format of the image unit. Similarly, the re-interpretation for
> image stores and the
>     write portion of image atomics is performed as though data were
> copied from a
>     texel represented in the format of the image unit to the texel in
> the bound texture.
>     In both cases, this copy operation would be performed by:
>
>      - reading the texel from the source format to scratch memory according to
>        the process described for GetTexImage (see section 6.1.4), using default
>        pixel storage modes and <format> and <type> parameters corresponding
>        to the source format in table 3.22; and
>
>      - writing the texel from scratch memory to the destination format according
>        to the process described for TexSubImage3D (see section 3.9.4),
> using default
>        pixel storage modes and <format> and <type> parameters corresponding
>        to the destination format in table 3.22
> "
>
> My underspecified "exact matching format" and "correct order" are then
> those which make the above operations just a memcpy, so we don't
> actually have to do anything beyond aliasing the memory.
>
> I suppose there might be implementations which want to do other things.
>

Yeah, that's right, an implementation of ARB_shader_image_load_store or
ARB_texture_view is still free to store the texture components in any
memory layout it pleases.  If the memory layout used internally is just
a (consistently) swizzled variant of what's specified by
ARB_image_load_store, the implementation may still avoid the copy in
many cases, but the approach of this patch series seems like the best
thing to do to me.

Is there any reason we need the 'prefer_no_swizzle' argument?  Can't we
just default to the "canonical" layout if it's supported?

> CC'ing Francisco on this as he was working on
> ARB_shader_image_load_store, which first introduces this -- I care
> mostly about the ARB_texture_view bits, which defines reinterpretation
> of a texture's data store by piggybacking on the load_store
> definition.
>
> -- Chris
>
> On Tue, Mar 11, 2014 at 3:42 PM, Michel Dänzer <michel at daenzer.net> wrote:
>> On Mon, 2014-03-10 at 22:20 +1300, Chris Forbes wrote:
>>> If prefer_no_swizzle is set, try:
>>> - The exact matching format
>>> - Formats with the required components in the correct order, plus a junk
>>>   component
>>
>> How are 'exact matching' and 'correct order' defined? My understanding
>> of GL internal formats is that they just specify which components are
>> there and possibly their sizes, but nothing about their memory layout.
>> If my understanding is correct, I think it's a bad idea to hardcode
>> driver / platform specific preferences here like this.
>>
>> I think you would either need to take the 'format' parameter into
>> account as well, or just use a driver specific ChooseTextureFormat hook.
>>
>>
>> --
>> Earthling Michel Dänzer            |                  http://www.amd.com
>> Libre software enthusiast          |                Mesa and X developer
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140311/c6749c89/attachment.pgp>