[PATCH] drm/mgag200: Increase bandwidth for G200se A rev1
Thomas Zimmermann
tzimmermann at suse.de
Thu Jul 27 14:55:47 UTC 2023
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.
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.
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.
Best regards
Thomas
>
> Maxime
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230727/a1ff6504/attachment-0001.sig>
More information about the dri-devel
mailing list