[Mesa-dev] [PATCH 2/3] gallium/r600: Don't let h/w do endian swap for colorformat

[Oded Gabbay]

On Fri, Feb 26, 2016 at 9:35 AM, Oded Gabbay <oded.gabbay at gmail.com> wrote:
> On Fri, Feb 26, 2016 at 9:32 AM, Michel Dänzer <michel at daenzer.net> wrote:
>> On 26.02.2016 16:14, Oded Gabbay wrote:
>>> On Fri, Feb 26, 2016 at 5:01 AM, Michel Dänzer <michel at daenzer.net> wrote:
>>>>
>>>> [ Dropping mesa-stable list from Cc, since sending patches there by
>>>> e-mail before they've landed on master is basically noise ]
>>>
>>> Problem is that I sometimes later forget to add stable :)
>>
>> Note that I'm only referring to sending patches to the mesa-stable list
>> by e-mail, which isn't necessary for them to be backported to stable
>> branches. The stable branch maintainer will pick patches for backporting
>> using the bin/get-pick-list.sh script.
>>
>> Adding the mesa-stable tag to the commit log is of course fine per se.
>>
> Yeah, I understand, but git send-email is configured to automatically
> adds the cc: tag. Maybe I should disable it...
>
>>
>>>> On 26.02.2016 06:09, Oded Gabbay wrote:
>>>>> Since the rework on gallium pipe formats, there is no more need to do
>>>>> endian swap of the colorformat in the h/w, because the conversion between
>>>>> mesa format and gallium (pipe) format takes endianess into account (see
>>>>> the big #if in p_format.h).
>>>>
>>>> That may be true for (some?) formats with 4 components of 8 bits, but
>>>> I'd be surprised if it was true for all formats handled by this
>>>> function. Just as one example, consider formats with 32 bits per component.
>>>>
>>>
>>> I first wanted to get these 3 patches out of the gate so people could
>>> have a working desktop in the most default form they are working (4
>>> components of 8 bits). I promise I will continu to work on this and
>>> will aspire to reach parity with LE, but I'm doing this on my free
>>> time so it could take some time.
>>>
>>> I will definitely want to check all formats.
>>
>> Then you can just add the return ENDIAN_NONE in the
>> V_0280A0_COLOR_8_8_8_8 case instead of at the beginning of the function.
>> That should address Matt's concern as well.
>>
> Hmm, maybe I should. I will check to see if this doesn't cause
> regressions from what I have arrived to and will update here.
>
> Oded
>
>>
>> --
>> Earthling Michel Dänzer               |               http://www.amd.com
>> Libre software enthusiast             |             Mesa and X developer

OK, that works as well, I'll send a new patch-set soon, once I finish
running piglit on x86.

Oded