[RFC PATCH 0/2] drm/mgag200: Use 24bit format in VRAM

Thomas Zimmermann tzimmermann at suse.de
Mon Apr 17 07:49:23 UTC 2023


Hi

Am 14.04.23 um 09:59 schrieb Jocelyn Falempe:
> On 13/04/2023 21:29, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 12.04.23 um 15:39 schrieb Jocelyn Falempe:
>>> The bandwidth between system memory and VRAM is very limited
>>> on G200.
>>> So when using a 32bit framebuffer on system memory, convert it to 24bit
>>> when copying the frame to the VRAM, this allows to go 33% faster.
>>> Converting the format on the fly is negligible, even on low end CPU.
>>
>> I'm skeptical about this idea. We emulated a number of formats in 
>> simpledrm and got a lot of flames and pushback. The argument was that 
>> we should export the formats that hardware supports and not pretend to 
>> support anything else. The only exception allowed was emulating 
>> XRGB8888, because it's the common ground hat everything in userspace 
>> supports.
>>
>> I see that this is a bit different from your patches, but not so much. 
>> When userspace wants 32-bit XRGB, it should get it if possible.
> 
> The hardware will drop the 8bit alpha anyway, there is no image quality 
> loss. So I find it better to drop it before sending it to the hardware 
> to save bandwidth. As the mgag200 doesn't expose any other 
> functionality, the userspace can't even read the VRAM back, so it's 
> unlikely to cause issue.

Believe me, I know that. :) We also made such arguments in that 
discussion around simpledrm and the answer was a big NO. This is 
considered a "rendering problem," which are better solved in userspace. 
If you get overall consent from DRM devs that this optimization is OK, 
I'm not going to block it. But I'm not going to fight for it either.

> 
>>
>> I'd rather suggest to set the console to 16 bit and also resort the 
>> formats array. It is supposed to be sorted by preference. RGB565 
>> should maybe be the top most entry, followed by RGB888. Then you'd 
>> have to teach userspace to respect these settings. I'm not sure if all 
>> compositors do.
>>
> 
> I don't think userspace cares much about very old hardware like this 
> one. I would rather make it work as good as possible with current 
> userspace.
> For example Gnome/Wayland won't work in 16bit or 24bit pixel depth, and 
> it would be much harder to add support in the compositor than this ~36 
> lines patch. Other compositors are probably expecting 32bit hardware too.
> mgag200 is also likely the last hardware from this era that's still 
> alive, so we can't expect userspace to add specific support for it.
> 
> 
> We can still change the format array order, but I would put 24bit first, 
> as 16 bit is a bit ugly nowadays.

24-bit is dead. Most userspace doesn't support it or it's broken or 
looks garbled. Even a decade ago, only pixman got it right. That 
probably didn't improve since.

Best regards
Thomas

> 
>> Best regards
>> Thomas
>>
>>>
>>> [PATCH 1/2] drm/mgag200: simplify offset and scale computation.
>>> [PATCH 2/2] drm/mgag200: Use 24bit format in VRAM
>>>
>>> drivers/gpu/drm/mgag200/mgag200_mode.c | 87 
>>> ++++++++++++++++++++++++++++++++++++---------------------------------------------------
>>>   1 file changed, 36 insertions(+), 51 deletions(-)
>>>
>>>
>>>
>>
> 
> 
> Best regards,
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
-------------- 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/20230417/592b9bd6/attachment.sig>


More information about the dri-devel mailing list