[Mesa-dev] [PATCH 03/10] mesa/st: add endian_format field to struct pipe_resource

[Oded Gabbay]

On Tue, Apr 12, 2016 at 10:40 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 12.04.2016 16:31, Oded Gabbay wrote:
>> On Tue, Apr 12, 2016 at 10:21 AM, Michel Dänzer <michel at daenzer.net> wrote:
>>> On 11.04.2016 23:34, Oded Gabbay wrote:
>>>> This patch adds a new field, called "endian_format", to
>>>> "struct pipe_resource". The new field is of type "enum pipe_endian" and
>>>> can receive one of two values:
>>>> - PIPE_ENDIAN_LITTLE
>>>> - PIPE_ENDIAN_NATIVE
>>>>
>>>> PIPE_ENDIAN_NATIVE is initialized to either PIPE_ENDIAN_LITTLE or
>>>> PIPE_ENDIAN_BIG during build time.
>>>>
>>>> This field is needed to provide information to the H/W drivers about the
>>>> endianess current state or desired state of the resource. In other words,
>>>> for resources that are the source of the operation, this field indicates
>>>> the resource's current memory layout endianess (big or little endian).
>>>> For resources that are the destination of the operation, this field
>>>> indicates the resource's desired memory layout endianess.
>>>>
>>>> This field is mandatory because of how mesa works. When we get into the
>>>> H/W driver functions, the driver *ususally* doesn't know if it is doing a
>>>> CPU->GPU, a GPU->CPU, a CPU->CPU or a GPU->GPU operation, as this
>>>> information is "hidden" by the fact we go through common code
>>>> paths (state tracker layer).
>>>
>>> That shouldn't matter if the formats are defined completely and their
>>> usage is consistent across the board. Sounds like either or both of
>>> those conditions aren't completely true yet. I agree with Roland that
>>> this should be addressed fundamentally rather than adding more hacks on top.
>>
>> I disagree with your statement. The formats are defined correctly,
>> it's just that the software rendering drivers can use the
>> automatically generated functions in u_format_table.c to handle all
>> the endianess issues, while H/W drivers won't do it. So H/W drivers
>> need additional hint.
>
> In other words, the formats aren't used consistently across the board. :)
Yeah, well, I guess one might phrase it like that. It seems like we
mean the same thing but use different phrasing.

>
> The solution proposed by Marek basically means that there's a conversion
> between the state tracker and driver interpretations of formats at
> transfer time.

Again, I think that's what I tried to do, although not in the correct
places as Marek and Roland pointed out.
Let me rewrite that section and send again the patches for a second round.

Oded

>
>
> --
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer