[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