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

Oded Gabbay oded.gabbay at gmail.com
Thu Feb 25 21:24:57 UTC 2016


On Thu, Feb 25, 2016 at 11:23 PM, Matt Turner <mattst88 at gmail.com> wrote:
> On Thu, Feb 25, 2016 at 1:19 PM, Oded Gabbay <oded.gabbay at gmail.com> wrote:
>> On Thu, Feb 25, 2016 at 11:16 PM, Matt Turner <mattst88 at gmail.com> wrote:
>>> On Thu, Feb 25, 2016 at 1:09 PM, Oded Gabbay <oded.gabbay at gmail.com> 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).
>>>>
>>>> Signed-off-by: Oded Gabbay <oded.gabbay at gmail.com>
>>>> Cc: "11.1 11.2" <mesa-stable at lists.freedesktop.org>
>>>> ---
>>>>  src/gallium/drivers/r600/r600_state_common.c | 6 ++++++
>>>>  1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/src/gallium/drivers/r600/r600_state_common.c b/src/gallium/drivers/r600/r600_state_common.c
>>>> index c3346f2..614b0fb 100644
>>>> --- a/src/gallium/drivers/r600/r600_state_common.c
>>>> +++ b/src/gallium/drivers/r600/r600_state_common.c
>>>> @@ -2704,6 +2704,12 @@ uint32_t r600_translate_colorformat(enum chip_class chip, enum pipe_format forma
>>>>
>>>>  uint32_t r600_colorformat_endian_swap(uint32_t colorformat)
>>>>  {
>>>> +       /*
>>>> +        * No need to do endian swaps on colors, as mesa<-->pipe formats
>>>> +        * conversion take into account the endian issue
>>>> +        */
>>>> +       return ENDIAN_NONE;
>>>
>>> Surely you didn't mean to leave the now-unreachable 50 line switch
>>> statement below?
>>>
>>
>> I actually didn't know if to delete it for good, or leave it there in
>> case we will need it back. Of course, we can always get it back from
>> the git log, but...
>>
>> If you guys feel strongly about it, I can delete it.
>
> There's no point in leaving in code that's commented out, and I think
> this is worse than that.
>
> I don't work on this driver, but if this function is really supposed
> to do nothing... maybe you can just delete it?

As I said, I have no problem either way.
If the AMD guys will have no problem as well, than I'll just delete it.

    Oded


More information about the mesa-dev mailing list