Hi Am 18.01.24 um 19:25 schrieb Zack Rusin:
On Mon, Jan 15, 2024 at 3:21 AM Thomas Zimmermann <tzimmermann@xxxxxxx> 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)
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
