[PATCH] drm/mgag200: Increase bandwidth for G200se A rev1

[Javier Martinez Canillas]

Thomas Zimmermann <tzimmermann at suse.de> writes:

> Hi Maxime
>
> Am 27.07.23 um 16:33 schrieb Maxime Ripard:
>> Hi Thomas,
>> 
>> On Wed, Jul 26, 2023 at 05:36:15PM +0200, Thomas Zimmermann wrote:
>>>> I've already sent a patch to use internally 24bit colors, when userspace
>>>> can use 32bit that would solve this issue as well. In the end, on the
>>>> VGA link, 24 or 32 bit colors are the same. That would allow modern
>>>> userspace to work on par with Xorg. So maybe we can reconsider it ?
>>>
>>> No way. We've had IRC flamewars over this topic already. People didn't get
>>> work done that day; others ragequit-ed in frustration. Ask Javier, he'll
>>> remember. :)
>>>
>>> The consent in DRM-land is: we're not going to mess with color formats
>>> behind the back of userspace. The only exception is the emulation of
>>> XRGB8888 iff the hardware does not support that. And only because it's the
>>> fallback format that is universally supported.
>> 
>> I'm aware that I might be reviving old heated debates here, but I'm not
>> sure what is the problem here.
>> 
>> I guess part of the problem is that due to the memcpy call, we would
>> have it in software.
>> 
>> But it's not clear to me how we're messing with color formats there: the
>> memcpy would drop the alpha part that was doing to be dropped by the
>> hardware anyway (and likely would have done so transparently if it
>> wasn't for the memcpy).
>> 
>> It doesn't affect the userspace at all, it doesn't change the way we
>> interpret the format either, it just ignores a part of the format that
>> is supposed to be ignored anyway. And doing so frees up a bunch of
>> resources?
>> 
>> So, AFAIU, it doesn't have any side effect except for the fact that it
>> consumes less memory bandwidth and allows for more pixels to go through.
>> That's not really "messing with the formats" in my book.

I agree with you Maxime and I believe Thomas also does, but the concensus
when that topic was (heatedly) dicusssed was that drivers should not fake
a pixel format. Even if is only about dropping the alpha channel, like in
the patch that Jocelyn mentioned.

>
> Technically not, but it's still a difference. Even in such cases without 
> side effects, it was dismissed when discussed in the context of simpledrm.
>

Indeed. I remember that discussion.

> The reasoning is that userspace should always be in control of the 
> format (sans that one exception). If userspace wants packed 24-bits it 
> can support RGB888 explicitly.  For the color-format transformation, 
> it's better to do that in userspace with SSE-like instructions than in 
> the kernel.
>
> I wasn't super-happy with this, but I think it's a clear statement with 
> simple rules to follow. I'd prefer that over relaxed rules where each 
> driver does its own thing.
>

I wasn't super happy either, but if I remember correctly we were the only
two that had this point of view and everyone else there thought that the
drivers shouldn't expose a format that don't support (other than XR24) ?.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat