[PATCH 00/10] rm/bochs: Modernize driver

Thomas Zimmermann tzimmermann at suse.de
Mon Aug 26 08:08:15 UTC 2024


Hi

Am 26.08.24 um 09:32 schrieb Gerd Hoffmann:
>    Hi,
>
>>> So this probably makes sense, but I'd like to see a bit more background
>>> information ...
>> The difference is in damage handling.
>>
>> The old code had two BOs in video memory and flipped between them. IDK the
>> details of the old rendering, but from the massive flickering of the cursor,
>> I assume that X11's internal either copies a full buffer during each redraw,
>> or doesn't really handle damage well. It could also happen that X didn't use
>> a shadow buffer for rendering. Bochs didn't request one. Without, drawing to
>> I/O memory is really slow. If that applies to virtual I/O memory as well
>> IDK.
>>
>> The new driver code only copies areas that have been changed from rendering.
>> The flickering is gone and the overall update performance is acceptable.
> Thanks.
>
> Have you tried wayland and fbcon too?

Fbcon is ok for text at least. I've yet to try wayland.

>
>>> On vram sizes:  The default qemu vram size (16M) should be fine for the
>>> default display resolution (1280x800).  For FullHD vram size should be
>>> doubled (-device VGA,vgamem_mb=32).
>> Right. Bochs never really tested that.  So I saw something like 5k by
>> 3k resolutions on my test setup with 16 MiB.
> IIRC there used to be a check in the past, limiting resolutions to
> buffer sizes which fit into vram twice (to allow for double buffering).
>
> Crude heuristic.  I do not remember when and why it went away.  Also
> I've seen wayland use three not two buffers ...

IDK where that test went.

The problem with TTM pinning/unpinning and eviction is that it requires 
3 times the maximum consumption of physical video memory, because there 
is fragmentation in some corner cases. So the 16 MiB default size seem 
really low.

Best regards
Thomas

>
>> Now that video-memory requirements for each mode can be calculated
>> easily, we can sort out the invalid modes.
> Yes.  Also I think trading higher main memory (shmem) usage for lower
> vram usage is good overall.  Main memory can be uses for something else
> if not needed whereas vram sits around unused.
>
> take care,
>    Gerd
>

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



More information about the dri-devel mailing list