Re: about video memory detection in wine
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
Re: about video memory detection in wine
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.
RE: about video memory detection in wine
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:hverb...@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 : > I'll send the patches on monday with a few minor improvements. > I think the spec should be fixed/extended first.
Re: about video memory detection in wine
2009/8/15 Stefan Dösinger : > I'll send the patches on monday with a few minor improvements. > I think the spec should be fixed/extended first.
Re: about video memory detection in wine
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.
RE: about video memory detection in wine
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:stefandoesin...@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.
RE: about video memory detection in wine
Thanks, I will do it later Regards Sunny -Original Message- From: Henri Verbeet [mailto:hverb...@gmail.com] Sent: Friday, August 14, 2009 7:26 PM To: Sun, Sunny Cc: wine-devel@winehq.org Subject: Re: about video memory detection in wine Could you please subscribe to wine-devel (http://www.winehq.org/mailman/listinfo/wine-devel) so your mail doesn't have to go through moderation? It's possible to disable mail delivery if you don't want to receive all the mail.
RE: about video memory detection in wine
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:stefandoesin...@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_ATI0x87FE
>
> 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:thunderbir...@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ösinger
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
RE: about video memory detection in wine
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_ATI0x87FE
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:thunderbir...@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ösinger 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
Re: about video memory detection in wine
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 :-(
Re: about video memory detection in wine
On Fri, Aug 14, 2009 at 9:41 PM, Stephen Eilert wrote: > > > > On Fri, Aug 14, 2009 at 4:23 PM, King InuYasha 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
Re: about video memory detection in wine
On Fri, Aug 14, 2009 at 4:23 PM, King InuYasha 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.
Re: about video memory detection in wine
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 wrote: > On Fri, Aug 14, 2009 at 10:30 AM, Stefan Dösinger > 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. > > >
Re: about video memory detection in wine
On Fri, Aug 14, 2009 at 10:30 AM, Stefan Dösinger 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.
Re: about video memory detection in wine
2009/8/14 Stefan Dösinger : > 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?
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.
Re: about video memory detection in wine
Could you please subscribe to wine-devel (http://www.winehq.org/mailman/listinfo/wine-devel) so your mail doesn't have to go through moderation? It's possible to disable mail delivery if you don't want to receive all the mail.
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_ATI0x87FE
>
> 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:thunderbir...@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ösinger
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
From 0844cdc2be0fb4bf1769e97a05a6d6b4ac624ef2 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Stefan=20D=C3=B6singer?=
Date: Fri, 14 Aug 2009 13:09:26 +0200
Subject: [PATCH 4/4] WineD3D: Use GL_ATI_meminfo if available
---
dlls/wined3d/directx.c | 24 +---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 82e476c..723eb78 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -1957,11 +1957,29 @@ static BOOL IWineD3DImpl_FillGLCaps(struct wined3d_gl_info *gl_info)
}
TRACE_(d3d_caps)("FOUND (fake) card: 0x%x (vendor id), 0x%x (device id)\n", gl_info->gl_vendor, gl_info->gl_card);
-/* If we have an estimate use it, else default to 64MB; */
-if(vidmem)
-gl_info->vidmem = vidmem*1024*1024; /* convert from MBs to bytes */
+/* Use video memory info from GL if available */
+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];
+/* 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] * 1
Re: about video memory detection in wine
Am Friday 14 August 2009 11:58:12 schrieb Sun, Sunny: > #define GL_TOTAL_PHYSICAL_MEMORY_ATI0x87FE > 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?
Re: about video memory detection in wine
On Thu, Aug 13, 2009 at 6:59 PM, Stefan Dösinger 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
Re: about video memory detection in wine
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.
Re: about video memory detection in wine
2009/8/12 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: > Is VBO_FREE_MEMORY_ATI the most appropriate value to query, or would TEXTURE_FREE_MEMORY_ATI make more sense?
RE: about video memory detection in wine
Hi I am sorry I forgot to introduce myself. I am a software engineer at AMD, working on OpenGL graphics driver, I am working with wine issues now. Some uses complained that there are too many issues to play games with wine with AMD graphics card, so we want to improve the quality. That's all, Thanks Regards Sunny From: Sun, Sunny Sent: Wednesday, August 12, 2009 4:04 PM To: 'wine-devel@winehq.org' Cc: Jin, Jian-Rong; Hu, Li; Guan, Xiao-Feng; Wang, Robin Subject: about video memory detection in wine 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
about video memory detection in wine
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
