On 7/14/06, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am Donnerstag 13 Juli 2006 22:07 schrieb Frank Richter:
I think the article exaggerates. (a) it refers to one driver which exhibits the problem - Matrox G400 GL, on Win32. Linux drivers may actually all properly support that function. (b) you could use a cap - e.g. never report more than 50% of the total system ram as VRAM. Or use that as a threshold for a heuristic - if more than that amount of textures are reported as "resident", assume the logic is broken.
I tried the sample program on my Linux box (radeon M9, 64 mb vram) and I don't think that it reported correct values. It said 32 mb textures, not all resident. While I have a 1400x1050 resolution I don't think it eats 32 mb vidmem.
Yeah, not at all. Graphics card video ram these days far exceed whats needed for video modes. Just a quick number crunch shows 1400x1050@32bpp only requires approx 5.6MB. Most of the ram is used for textures, I believe.
I think the worst case at detecting amount of video ram is stuffing it with textures and guessing how much went in.
Jesse Allen <the3dfxdude <at> gmail.com> writes:
On 7/14/06, Stefan Dösinger <stefandoesinger <at> gmx.at> wrote:
I tried the sample program on my Linux box (radeon M9, 64 mb vram) and I don't think that it reported correct values. It said 32 mb textures, not all resident. While I have a 1400x1050 resolution I don't think it eats 32 mb vidmem.
Yeah, not at all. Graphics card video ram these days far exceed whats needed for video modes. Just a quick number crunch shows 1400x1050 <at> 32bpp only requires approx 5.6MB. Most of the ram is used for textures, I believe.
For a single-buffered root Xserver yes. But for a 1400x1050@32bpp game, we usually have 24bpp depth buffer, 8bpp sencil plus a double buffer for the framebuffer so we would have something like 16.8MB of video RAM. This is only OpenGL memory, the normal Xserver FB memory is still 5.6MB as you said so we would be at 22.4MB of video RAM gone (I'm pretty sure that the Xserver doesn't/can't share its framebuffer with OpenGL's, correct me if I'm wrong). I haven't looked into that test program yet, so I'm not sure how it calculates "32MB" texture space for you, but it seems a fairly reasonable number for your setup.
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. It is unfortunate that OpenGL doesn't portably provide this info directly, but texture stuffing is a work-around, although not necessarily a nice one.
It should be noted that GetAvailableTextureMem() will return the Video+AGP memory, and even MSDN recommends against using it for small-scale allocations. So as long as it is "close" (but less-than-or-equal to the physical max) it should be good enough for most games.
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?)
- Aric
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.
-
Aric Cyr -
Chris -
Jesse Allen