On Tue, Apr 12, 2016 at 10:40 AM, Michel Dänzer <[email protected]> wrote: > On 12.04.2016 16:31, Oded Gabbay wrote: >> On Tue, Apr 12, 2016 at 10:21 AM, Michel Dänzer <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
