[PATCH] drm/mgag200: Increase bandwidth for G200se A rev1
Javier Martinez Canillas
javierm at redhat.com
Fri Aug 4 14:02:27 UTC 2023
Javier Martinez Canillas <javierm at redhat.com> writes:
> Thomas Zimmermann <tzimmermann at suse.de> writes:
>
[...]
>> 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) ?.
>
I think that this unwritten rule must be documented somewhere so that we
could know what the rule really is instead of people making assumptions.
Because my understanding from the discussion was that user-space has no
way to know if a format is "native" or "fake" and it shouldn't pay for the
performance penalty of doing these format conversions in the drivers.
But the irony here is that enforcing such a rule in this particular case
would prevent to have a performance gain. So it seems to me as if it's the
opposite to what such a rule wanted to achieve.
My proposal is to write a doc patch explicitly stating that drivers must
only expose a "virtual" XRGB8888 format for compatibility and that it is
allowed to drop the alpha channel in the driver if that would improve the
performance for a particular device (e.g: slow DMA as is the case here).
That way, the spirit of the rule would be to make the driver/device as
performant as possible. What do you think ? Does this make sense to you ?
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
More information about the dri-devel
mailing list