[Chris]

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.