Re: [PATCH v3] drm/plane: Add documentation about software color conversion.

[Thomas Zimmermann <tzimmermann@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 4571 bytes --]

Hi

Am 11.09.23 um 12:05 schrieb Jocelyn Falempe:
[...]
>> Optimization always depends on the workload; something that the driver 
>> doesn't know. For example, as we mostly move the mouse cursor around 
>> the screen, the damages areas are usually small. Optimizing this might 
>> be pointless in any case.
> 
> So your point is we should not optimize because sometime it might not be 
> necessary ? And even for cursor update, the conversion is still 25% faster.

Yes, kind of. Those 25% are meaningless in the big picture. And the 
current code is fast enough for what these chips do (server consoles). 
So there's no pointing micro-optimizing anything here. See my reply to 
Pekka for an optimization that I'd find much more useful.

If I have to choose between fast-enough-but-simple and 
faster-but-complicated, the former is much preferable. Anyone who wants 
fast and beautiful graphics has a better graphics card anyway.

> 
>>
>>>
>>>>
>>>> Another point of concern is CPU consumption: Slow I/O buses may 
>>>> stall the display thread, but the CPU could do something else in the 
>>>> meantime. Doing format conversion on the CPU prevents that, hence 
>>>> affecting other parts of the system negatively. Of course, that's 
>>>> more of a gut feeling than hard data.
>>>
>>> I think it's the reverse. Without dropping the X data, the CPU is 
>>> actually stalling much longer sending useless bytes to the mgag200's 
>>> VRAM. And the CPU can't do anything else while doing memcpy_toio().
>>
>> Hyperthreading.
> 
> I still doubt a user-space conversion would do a better job than the 
> kernel.
>>
>> You are also arguing against XRGB in general, which is a different topic.
> 
> yes, the issue is human eyes only sees 3 colors, and it's not a power of 
> two. So compromise have been made, and that Matrox card, is from the era 
> of the transition from 16bits to 32bits, and works significantly better 
> in 24bits. And it's probably the only remaining GPU with this problem.

No. There's at least udl hardware, which does only support RGB16 and 
RGB24. And for simpledrm and ofdrm, we have to take whatever the system 
provided us with. That could be RGB24.

> 
>>
>>> Using DMA is the only way to free the CPU during the copy, but it 
>>> appears to be either broken or significantly slower on most mgag200 
>>> hardware.
>>>
>>> I actually have made the work to support DMA, and I'm a bit sad it 
>>> didn't work on all g200, so this optimization is really a last 
>>> resort, on a really broken hardware.
>>>
>>>>
>>>> Please note that the kernel's conversion code uses memory allocation 
>>>> of intermediate buffers. We even recently had a discussion about 
>>>> allocation overhead during display updates. Userspace can surely do 
>>>> a better job at keeping such buffers around.
>>>>
>>>> And finally a note the hardware itself: on low-end hardware like 
>>>> those Matrox chips, just switch to RGB16. That will be pretty and 
>>>> fast enough for these chips' server systems. Anyone who cares about 
>>>> fast and beautiful should buy a real graphics card.
>>>
>>> There are still sysadmin users that occasionally have to browse the 
>>> web to find answer, or read their mail in a GUI client. It turns out 
>>> that rgb16 is pretty ugly for today standard, and buying an external 
>>> card would be a bit too much, and won't work for remote control.
>>
>> I'm sure sysadmins have a computer for work with a decent GPU and 
>> don't need to browse the web on their server systems.
> 
> The GUI applications also include graphical installer, that obviously 
> you can't run on other system.

> I do have bug reports, and I already fixed a few regressions in the 
> mgag200 driver from this reports.

This isn't a driver bug.

> But if you think they shouldn't use this GPU, then why maintaining a 
> driver in the first place ? Simpledrm is enough if you don't use graphics.

I've done my share of graphic installations on these chips. Neither 
low-color modes nor performance has ever been a problem. And if, it is 
still better to spend the time on the renderer, so that all drivers can 
benefit.

Best regards
Thomas

> 
>>
>> Best regards
>> Thomas
>>
>>>
>>>
>>> Best regards,
>>>
>>
> 
> Best regards,
> 

-- 
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)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]