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 ThomasBest 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:
OpenPGP_signature.asc
Description: OpenPGP digital signature
