[Mesa-dev] [PATCH 03/10] mesa/st: add endian_format field to struct pipe_resource
Michel Dänzer
michel at daenzer.net
Tue Apr 12 07:40:57 UTC 2016
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. :)
The solution proposed by Marek basically means that there's a conversion
between the state tracker and driver interpretations of formats at
transfer time.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the mesa-dev
mailing list