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

[Chris Forbes]

There's cases where BGRA or ARGB or whatever avoids having to juggle
things either in texture upload paths, or blits to scanout buffers --
if we didn't care about that, then yes, we could just default to the
canonical layout.

I think we can also detect the cases for views via
type==format==GL_NONE in mesa, and possibly avoid the parameter -- but
that doesn't help for ARB_shader_image_load_store.

-- Chris

On Wed, Mar 12, 2014 at 8:47 AM, Francisco Jerez <currojerez at riseup.net> wrote:
> 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
>>>