[PATCH] drm/vmwgfx: Filter modes which exceed 3/4 of graphics memory.

[Thomas Zimmermann]

Hi

Am 18.01.24 um 19:25 schrieb Zack Rusin:
> On Mon, Jan 15, 2024 at 3:21 AM Thomas Zimmermann <tzimmermann at suse.de> wrote:
>>
>> Hi
>>
>> Am 12.01.24 um 21:38 schrieb Ian Forbes:
>>> SVGA requires surfaces to fit within graphics memory (max_mob_pages) which
>>> means that modes with a final buffer size that would exceed graphics memory
>>> must be pruned otherwise creation will fail.
>>>
>>> Additionally, device commands which use multiple graphics resources must
>>> have all their resources fit within graphics memory for the duration of the
>>> command. Thus we need a small carve out of 1/4 of graphics memory to ensure
>>> commands likes surface copies to the primary framebuffer for cursor
>>> composition or damage clips can fit within graphics memory.
>>>
>>> This fixes an issue where VMs with low graphics memory (< 64MiB) configured
>>> with high resolution mode boot to a black screen because surface creation
>>> fails.
>>
>> That is a long-standing problem, which we have observed with other
>> drivers as well. On low-memory devices, TTM doesn't play well. The real
>> fix would be to export all modes that possibly fit and sort out the
>> invalid configurations in atomic_check. It's just a lot more work.
>>
>> Did you consider simply ignoring vmwgfx devices with less than 64 MiB of
>> VRAM?
> 
> Unfortunately we can't do that because on new esx servers without
> gpu's the default is 16MB. A lot of people are still running their esx
> boxes with 4MB, which is in general the most common problem because
> with 4MB people still tend to like to set 1280x800 which with 32bpp fb
> takes 4096000 bytes and with 4MB available that leaves only 96KB
> available and we need more to also allocate things like the cursor.
> Even if ttm did everything right technically 1280x800 @ 32bpp
> resolution will fit in a 4MB graphics memory, but then the system will
> not be able to have a hardware (well, virtualized) cursor. It's
> extremely unlikely people would even be aware of this tradeoff when
> making the decision to increase resolution.

Do you allocate buffer storage directly in the provided VRAM? If so how 
do you do page flips then? You'd need for the example of 1280x800-32, 
you'd need around 8 MiB to keep front and back buffer in VRAM. I guess, 
you only support the framebuffer console (which doesn't do pageflips)?

In mgag200 and ast, I had the luxury for replacing TTM with SHMEM 
helpers, which worked around the problem easily. Maybe that's an option 
for low-memory systems?

Best regards
Thomas

> 
> So the driver either needs to preallocate all the memory it possibly
> might need for all the basic functionality before modesetting or the
> available modes need to be validated with some constraints.
> 
> z

-- 
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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20240119/8119b3b9/attachment-0001.sig>