On Wednesday 19 July 2006 02:13, Aric Cyr wrote:
Jesse Allen <the3dfxdude <at> gmail.com> writes:
I think the worst case at detecting amount of video ram is stuffing it with textures and guessing how much went in.
This is probably the only reasonably accurate and cross-platform way to do it without resorting to hacks or platform-specific methods or graphic-card specific methods.
I'd think that this method is itself a (nasty) hack. What do the OpenGL specs say about this? Wouldn't the driver be free to defer the actual uploading of textures to VRAM until it's actually used (thus reporting no free VRAM)? Or worse, defer the actual freeing of the textures, so testing for the free remaining video memory would, in essence, use up the free video memory (thus reporting the free VRAM, but leaving you with none of it).
Since OpenGL doesn't even need VRAM to be used, it would be hard to devise a reliable method using it to detect the amount of VRAM a system has. You'd probably have to use X11 calls to get that info. But even still, OpenGL is allowed to push off data from VRAM to system RAM, completely transparent to the program, so the amount of available texture memory isn't at all based on the amount of VRAM a system may have. Granted it's not really optimal to fall back on the use of system RAM, but a bit of overflow is hardly noticeable to overall performance. It's only when it needs to use more than the total VRAM at any given time does performance really suffer.
I still say a registry entry is a simple alternative way to go, with a default of 32MB or 64MB. (Didn't someone supply a patch for this a while ago?)
What about having a default of 0 in the registry? In which case Wine should try various methods to get the total VRAM size (X11/driver calls, log parsing, etc), and failing that, default to 32MB or 64MB. Winecfg could then have a section for manually setting the amount of VRAM (0 for autodetect), and a readout showing the amount it autodetected.