Hi
We have implemented GL_TOTAL_PHYSICAL_MEMORY for about 8 months, so you will not get the GL_INVALID_ENUM error. I think it will be documented later.
I have tested with your patch with 3 ATI asics, all of them can get the correct amount of video memory (1GB, 256MB, 128MB).
For the reason that GL_TOTAL_PHYSICAL_MEMORY is implemented after GL_ATI_meminfo, so if a user uses too old driver (about before Catalyst 9.2), he may have problems to get the correct amount of video memory, so I suggested to add the following code in your patches:
+ if(GL_SUPPORT(ATI_MEMINFO))
+ {
+ /* All GL_ATI_meminfo enums return 4 ints, even the (undocumented)
+ * GL_TOTAL_PHYSICAL_MEMORY_ATI one, which returns {mem, 0, 0, 0} */
+ GLint mem[4] = {0};
+ /* Returns the vidmem in KB */
+ glGetIntegerv(GL_TOTAL_PHYSICAL_MEMORY_ATI, mem);
+ TRACE("Video memory from OpenGL: %d MB\n", mem[0] / 1024);
+ gl_info->vidmem = mem[0] * 1024; /* convert from KBs to bytes */
+ if(gl_info->vidmem < 64 * 1024 * 1024)
+ gl_info->vidmem = 64 * 1024 * 1024;
+ }
Please tell me if you have any questions, thanks and good night!
Regards
Sunny
-----Original Message----- From: Stefan Dösinger [mailto:stefandoesinger@gmx.at] Sent: Friday, August 14, 2009 7:13 PM To: Sun, Sunny Cc: Roderick Colenbrander; wine-devel@winehq.org; ORCA Linux Subject: Re: about video memory detection in wine
Hi,
Can you give the attached patches a try? Do they detect the correct amount of
video memory?
Thanks,
Stefan
Am Friday 14 August 2009 11:58:12 schrieb Sun, Sunny:
Hi
I think it is difficult to maintain a large list of all ASICs, for you have
to change the list from time to time when a new ASIC is released. Actually
we have provided the functionality for getting total video memory, you can
use the following code to get the total video memory with ATI cards.
#define GL_TOTAL_PHYSICAL_MEMORY_ATI 0x87FE
const char *glExtensions = (const char*)glGetString(GL_EXTENSIONS);
if(strstr(glExtensions, "GL_ATI_meminfo"))
{
int total_mem[4] = {0};
glGetIntegerv(GL_TOTAL_PHYSICAL_MEMORY_ATI, total_mem); //
total_mem[0] contains the total video memory size and the value is in Kbyte
vidmem = total_mem[0] / 1024; //converting from Kbyte to Mbyte
}
Regards
Sunny
-----Original Message-----
From: Roderick Colenbrander [mailto:thunderbird2k@gmail.com]
Sent: Friday, August 14, 2009 1:44 AM
To: Stefan Dösinger
Cc: wine-devel@winehq.org; Hu, Li; Jin, Jian-Rong; Wang, Robin; Guan,
Xiao-Feng; Sun, Sunny Subject: Re: about video memory detection in wine
On Thu, Aug 13, 2009 at 6:59 PM, Stefan Dösingerstefandoesinger@gmx.at
wrote:
Am Wednesday 12 August 2009 10:04:10 schrieb Sun, Sunny:
I think you can first detect GL_ATI_meminfo in
glGetString(GL_EXTENSIONS); if GL_ATI_meminfo exists, then you can use
glGetIntegerv(GL_VBO_FREE_MEMORY_ATI, param) to get the current free
video memory, you can see more info at:
A minor problem with GL_ATI_meminfo is that it doesn't report the total
amount
of video memory available. D3D8 and D3D9 only report the free amount as
well,
but DirectDraw can return the total amount. There are some games that
first
query the total amount using ddraw, then continue with d3d8 or 9.
Depending
on what other apps are doing, reporting the currently free amount as
total
might result in the app thinking that free vidmem > total vidmem, running
into all sorts of troubles. (For example, another app frees a lot of
textures
between the ddraw vidmem query and the d3d9 vidmem query)
It is even worse. Even OpenGL apps like WoW use ddraw for querying the
amount of video memory at startup!
In case of Nvidia the amount of video memory and the pci ids are
advertised using the NV-CONTROL extension. At some point I plan on
adding code for that. Even when using such extension the current
fallback is still needed. The list needs some updates.
The other issue is that if some other apps use lots of video memory(like
Compiz, etc), then we can still run into the same out of memory issue if
other apps consume too much video memory.
We should probably also fall back to a saner default on newer d3d10 class
cards - a radeon 9500 isn't really representative for them any more.
I still have to update that part but haven't had time for it yet.
Roderick