Hi
You are using the hardcoded method to get the vidmem now (in function IWineD3DImpl_FillGLCaps), first you call glGetString(GL_RENDERER) to get the GPU renderer string, and then you use this string to set the vidmem in your code. Unfortunately you don't get all of the ATI GPU's string now, for our workstation GPU, the string is always like "ATI FireGL V8700", so you don't recognize this GPU and consider it as ATI_RADEON_9500, then 64MB is set which doesn't support 1280x1024 resolution (Out of adapter memory).
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:
http://www.opengl.org/registry/specs/ATI/meminfo.txt
if GL_ATI_meminfo doesn't exist, you can fall back to the original method.
Please tell me if you have any questions.
Regards,
Sunny, Sun
2009/8/12 Sun, Sunny Sunny.Sun@amd.com:
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:
Is VBO_FREE_MEMORY_ATI the most appropriate value to query, or would TEXTURE_FREE_MEMORY_ATI make more sense?
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)
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.
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
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
Am Friday 14 August 2009 11:58:12 schrieb Sun, Sunny:
#define GL_TOTAL_PHYSICAL_MEMORY_ATI 0x87FE const char *glExtensions = (const char*)glGetString(GL_EXTENSIONS); if(strstr(glExtensions, "GL_ATI_meminfo"))
That sounds very helpful! Is this supported on all drivers that support GL_ATI_meminfo(but not documented in the spec)? Or was this added at some later point? Do I have to be prepared to getting a GL_INVALID_ENUM or something when I am trying to use GL_TOTAL_PHYSICAL_MEMORY_ATI?
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
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
Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny:
- if(gl_info->vidmem < 64 * 1024 * 1024)
- gl_info->vidmem = 64 * 1024 * 1024;
I guess the idea is that no ATI card that was ever supported on fglrx has less than 64 mb of memory? My old radeon 9000, which isn't supported by fglrx since years now has 64 MB. Does this hold true for radeon 8500 cards too?
I think I'll use the guessed amount of vidmem in this case instead of hardcoding 64 MB.
Using the undocumented value and the check for older drivers which don't support it is a bit hacky, but its a well-isolated hack and avoids a lot of problems, so it should be ok.
2009/8/14 Stefan Dösinger stefandoesinger@gmx.at:
Using the undocumented value and the check for older drivers which don't support it is a bit hacky, but its a well-isolated hack and avoids a lot of problems, so it should be ok.
I'm only seeing half of the discussion here (the other half is probably still in moderation...), but that doesn't sound like a good idea. Is there any reason the extension can't be fixed to include this, or alternatively a second extension created?
Am Friday 14 August 2009 18:52:36 schrieb Henri Verbeet:
I'm only seeing half of the discussion here (the other half is probably still in moderation...), but that doesn't sound like a good idea. Is there any reason the extension can't be fixed to include this, or alternatively a second extension created?
The issue is that GL_TOTAL_PHYSICAL_MEMORY was added a bit after the other 4 query flags, Sunny says they're working on adding it to the spec. So there is a range of fglrx version that supports ATI_meminfo, but returns zero on GL_TOTAL_PHYSICAL_MEMORY_ATI. So if we want to use this as-is we have to take care that we don't set the vidmem to zero accidentally.
Another extension is a possible way to go, but there are still r300 to r500 chips where the driver has been discontinued and where the vidmem info is useful too. These cards most likely won't get the new extension in that case.
@AMD: The discontinuing of fglrx for r300-r500 chips is really a pain for us. There's essentially no way to use those cards on Linux right now. The Open Source driver that ships with current distros can't even run 3DMark 2000 properly, and the 9.3 driver doesn't run on up to date distros. Currently I have to tell everyone who has such a card that it probably won't be useable for probably another year :-(
On Fri, Aug 14, 2009 at 10:30 AM, Stefan Dösingerstefandoesinger@gmx.at wrote:
Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny:
if(gl_info->vidmem < 64 * 1024 * 1024)gl_info->vidmem = 64 * 1024 * 1024;I guess the idea is that no ATI card that was ever supported on fglrx has less than 64 mb of memory? My old radeon 9000, which isn't supported by fglrx since years now has 64 MB. Does this hold true for radeon 8500 cards too?
I think I'll use the guessed amount of vidmem in this case instead of hardcoding 64 MB.
Using the undocumented value and the check for older drivers which don't support it is a bit hacky, but its a well-isolated hack and avoids a lot of problems, so it should be ok.
My Radeon 9200 has 128 MB. But I've never used fglrx on it either, so I don't know what this gains.
This seems like the wrong way to go. I'm wondering if there is another way to detect VRAM? There should be a way to determine VRAM from Xorg? Why should OpenGL or DirectDraw be the method that Wine uses to determine video RAM? Why should Wine have a fixed value based on a list? Maybe I'm being stupid, but I think it would make sense for the display server (xorg) to know how much VRAM a graphics card has...
On Fri, Aug 14, 2009 at 1:42 PM, Jesse Allen the3dfxdude@gmail.com wrote:
On Fri, Aug 14, 2009 at 10:30 AM, Stefan Dösingerstefandoesinger@gmx.at wrote:
Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny:
if(gl_info->vidmem < 64 * 1024 * 1024)gl_info->vidmem = 64 * 1024 * 1024;I guess the idea is that no ATI card that was ever supported on fglrx has
less
than 64 mb of memory? My old radeon 9000, which isn't supported by fglrx since years now has 64 MB. Does this hold true for radeon 8500 cards too?
I think I'll use the guessed amount of vidmem in this case instead of hardcoding 64 MB.
Using the undocumented value and the check for older drivers which don't support it is a bit hacky, but its a well-isolated hack and avoids a lot
of
problems, so it should be ok.
My Radeon 9200 has 128 MB. But I've never used fglrx on it either, so I don't know what this gains.
On Fri, Aug 14, 2009 at 4:23 PM, King InuYasha ngompa13@gmail.com wrote:
This seems like the wrong way to go. I'm wondering if there is another way to detect VRAM? There should be a way to determine VRAM from Xorg? Why should OpenGL or DirectDraw be the method that Wine uses to determine video RAM? Why should Wine have a fixed value based on a list? Maybe I'm being stupid, but I think it would make sense for the display server (xorg) to know how much VRAM a graphics card has...
Just a nitpick: Wine does not *use* DirectDraw, it *implements* DirectDraw, as there's no DirectDraw anywhere other than win32.
I see no problem querying OpenGL, if the extensions can be trusted to provide useful values - even if they are undocumented or not always available. The problem with the approach so far seems to be that this extension is ATI-specific. Then again, the current fallback can be left in place if Wine does not find a way to properly detect the VRAM amount.
As for asking Xorg, I do not have the knowledge to say if it is feasible - but one would think that would've been tried long ago if it were straightforward.
--Stephen
programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
On Fri, Aug 14, 2009 at 9:41 PM, Stephen Eilertspedrosa@gmail.com wrote:
On Fri, Aug 14, 2009 at 4:23 PM, King InuYasha ngompa13@gmail.com wrote:
This seems like the wrong way to go. I'm wondering if there is another way to detect VRAM? There should be a way to determine VRAM from Xorg? Why should OpenGL or DirectDraw be the method that Wine uses to determine video RAM? Why should Wine have a fixed value based on a list? Maybe I'm being stupid, but I think it would make sense for the display server (xorg) to know how much VRAM a graphics card has...
Just a nitpick: Wine does not *use* DirectDraw, it *implements* DirectDraw, as there's no DirectDraw anywhere other than win32.
I see no problem querying OpenGL, if the extensions can be trusted to provide useful values - even if they are undocumented or not always available. The problem with the approach so far seems to be that this extension is ATI-specific. Then again, the current fallback can be left in place if Wine does not find a way to properly detect the VRAM amount.
As for asking Xorg, I do not have the knowledge to say if it is feasible - but one would think that would've been tried long ago if it were straightforward.
--Stephen
programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
Xorg explicitly doesn't tell programs how much memory they have as it can lead to bad designs and these days cards have a sufficient amount of memory for 2D. In case of 3D programs the amount of memory is more important to have. OpenGL itself (except using the ATI extension) does not provide a way to query the amount of video memory or the exact videocard (yes it exports the renderer string but d3d exports the pci id as well. Like X, OpenGL wants to hide this information from the designer. Though these days this information is becoming more and more important for designers as they can decide to e.g. use a different code path. Native Linux games like Quake Wars for this reason use vendor specific extensions like NV-CONTROL to obtain some info. It might make sense to have a cleaned up version of the ATI memory extension as real ARB extension. For modern games it is crucial. Hopefully AMD can clean it up. When I last checked this extension months ago the total amount of memory wasn't in the spec, it might make sense to update the spec.
Regards, Roderick Colenbrander
Hi
Here I just want to tell you that if a user uses an old driver that we don't support querying total memory will lead to vidmem = 0, that is unexpected, so we should have a check.
It doesn't matter that the total memory is not documented, as long as it can tell you the true value.
And for the old card that doesn't support ATI_meminfo can still go the fall back path.
I think the biggest benefit from using this extension is that you don't have to update the vidmem list for newly realeased ATI cards, and you can get the correct amount of video memory for the same render string but with different video memory (eg: HD4870 may have 1GB memory or only 512MB memory)
Regards
Sunny
-----Original Message----- From: Stefan Dösinger [mailto:stefandoesinger@gmx.at] Sent: Saturday, August 15, 2009 12:31 AM To: Sun, Sunny Cc: Roderick Colenbrander; wine-devel@winehq.org Subject: Re: about video memory detection in wine
Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny:
if(gl_info->vidmem < 64 * 1024 * 1024)
gl_info->vidmem = 64 * 1024 * 1024;
I guess the idea is that no ATI card that was ever supported on fglrx has less
than 64 mb of memory? My old radeon 9000, which isn't supported by fglrx
since years now has 64 MB. Does this hold true for radeon 8500 cards too?
I think I'll use the guessed amount of vidmem in this case instead of
hardcoding 64 MB.
Using the undocumented value and the check for older drivers which don't
support it is a bit hacky, but its a well-isolated hack and avoids a lot of
problems, so it should be ok.
Am Saturday 15 August 2009 09:25:27 schrieb Sun, Sunny:
It doesn't matter that the total memory is not documented, as long as it can tell you the true value.
The concern is that lack of spec documentation makes it harder to maintain the code. Like the GL_ATI_texture_compression_3dc code, which is essentially based on guessing. However, for ATI_meminfo we have your info in the mailing list archives, and if the extension is eventually updated its ok I guess.
I'll send the patches on monday with a few minor improvements.
2009/8/15 Stefan Dösinger stefandoesinger@gmx.at:
I'll send the patches on monday with a few minor improvements.
I think the spec should be fixed/extended first.
Hi Verbeet The spec will be fixed, but it will take some time. But I think we can use it now because it is implemented and will not change.
Hi Dösinger Have you done that?
Regards Sunny -----Original Message----- From: Henri Verbeet [mailto:hverbeet@gmail.com] Sent: Sunday, August 16, 2009 9:52 AM To: Stefan Dösinger Cc: Sun, Sunny; wine-devel@winehq.org; Roderick Colenbrander Subject: Re: about video memory detection in wine
2009/8/15 Stefan Dösinger stefandoesinger@gmx.at:
I'll send the patches on monday with a few minor improvements.
I think the spec should be fixed/extended first.
Am Wednesday 19 August 2009 04:02:37 schrieb Sun, Sunny:
Hi Dösinger Have you done that?
Not yet. After Henri's objection I have decided to wait until either the spec is fixed or you two reach an agreement.
I'm sure what will happen to the GL_ATI_meminfo but perhaps it makes sense to unify it with WGL_AMD_gpu_association ?
Roderick
-
Henri Verbeet -
Jesse Allen -
King InuYasha -
Roderick Colenbrander -
Stefan Dösinger -
Stephen Eilert -
Sun, Sunny