[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:

> 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.
>

Right, but wouldn't it make more sense for the driver to define a
driver-specific ChooseTextureFormat function in those cases, or just
mark the problematic format as unsupported?

> 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
>>>>
-------------- 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/65e47af8/attachment-0001.pgp>