"assumed" graphic card memory
hiho within the dlls/wined3d/device.c there is a define for the fake size of the graphic-card memory. with the given 64MB Richard Burns Rally[1] crashes on startup - once i put my real 256MB there it start and drawprim is the only remaining problem, the game has. IIRC there where a patch, that allowed editing the amount of gfx-ram to be configured via winecfg? until an easy way can be found, would it be better to apply this patch and state this fact in the error-messages wine produces? [1] http://www.3dgamers.com/games/rburnsrally/downloads/ -- cu
On 11/07/06, Christoph Frick <frick(a)sc-networks.de> wrote:
only remaining problem, the game has. IIRC there where a patch, that allowed editing the amount of gfx-ram to be configured via winecfg?
You probably mean http://wiki.winehq.org/PatchD3dVideoMemorySize
Christoph Frick wrote:
within the dlls/wined3d/device.c there is a define for the fake size of the graphic-card memory.
Odd. Isn't it relatively easy to figure out? Perhaps something like: # ls -lS /sys/class/graphics/fb0/device/resource* | head -n1 | awk '{print $5}' 134217728 or # ls -lS "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/resource*" | head -n1 | awk '{print $5}' 134217728 Does that work / is it correct for any card? Is the AGP aperture size also needed?
Hi,
Does that work / is it correct for any card? Is the AGP aperture size also needed?
# ls -lS /sys/class/graphics/fb0/device/resource* | head -n1 | awk '{print $5}' ls: /sys/class/graphics/fb0/device/resource*: No such file or directory I'd say it needs a framebuffer device which I do not have and possibly root privs.
On 7/12/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote:
Christoph Frick wrote:
within the dlls/wined3d/device.c there is a define for the fake size of the graphic-card memory.
Odd. Isn't it relatively easy to figure out?
Perhaps something like:
# ls -lS /sys/class/graphics/fb0/device/resource* | head -n1 | awk '{print $5}' 134217728
or
# ls -lS "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/resource*" | head -n1 | awk '{print $5}' 134217728
Does that work / is it correct for any card? Is the AGP aperture size also needed?
None of that is universally correct. Not every system has an fb0 device, and even on mine that do, there are no resource entries under /sys/class/graphics/fb0/device. Also, the PCI path varies a lot, too. On one of my systems, it is found here: /sys/devices/pci0000:00/0000:00:0b.0/0000:01:00.0 and on another: /sys/devices/pci0000:00/0000:00:1e.0/0000:04:00.0 None of this works at all on non-Linux systems, for that matter. (Wine does run on non-Linux systems, in case you didn't realize that.) Carl Fongheiser
On Wednesday, July 12, 2006 16:26, Molle Bestefich wrote:
Christoph Frick wrote:
within the dlls/wined3d/device.c there is a define for the fake size of the graphic-card memory.
Odd. Isn't it relatively easy to figure out?
Perhaps something like:
# ls -lS /sys/class/graphics/fb0/device/resource* | head -n1 | awk '{print $5}' 134217728
or
# ls -lS "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/resource*"
| head -n1 | awk '{print $5}'
134217728
Does that work / is it correct for any card? Is the AGP aperture size also needed?
This reports the wrong values for me in one machine with a 32M video card: neil(a)t40-n ~ $ ls -lS /sys/class/graphics/fb0/device/resource* -rw------- 1 root root 134217728 Jul 12 17:12 /sys/class/graphics/fb0/device/resource0 -rw------- 1 root root 65536 Jul 12 17:12 /sys/class/graphics/fb0/device/resource2 -r--r--r-- 1 root root 4096 Jul 12 07:57 /sys/class/graphics/fb0/device/resource -rw------- 1 root root 256 Jul 12 17:12 /sys/class/graphics/fb0/device/resource1 ...and doesn't work at all in another: neil(a)x2-42 ~ $ ls -lS /sys/class/graphics/fb0/device/resource* ls: /sys/class/graphics/fb0/device/resource*: No such file or directory - Neil
I'd say it needs a framebuffer device which I do not have
Use the PCI variant ;-).
Also, the PCI path varies a lot
Obviously. The correct PCI path would need to be found first. (I used "lspci|grep VGA", hehe.)
None of this works at all on non-Linux systems, for that matter. (Wine does run on non-Linux systems, in case you didn't realize that.)
Default to 64MB on those systems.
This reports the wrong values for me in one machine with a 32M video card: 134217728
Ok. Guess it's rubbish then, too bad. Oh well.
It might be possible to guesstimate the available memory: http://delphi3d.net/articles/viewarticle.php?article=texman.htm
Promising! But perhaps an easier approach would be to fix every Linux driver to report the correct number in sysfs. I'm pretty sure each driver knows how much RAM is on the card already, so it should be trivial..
May be using we can use the internals of lspci and pciutils. So that we can calculate the VGA memory on the fly. On 7/13/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote:
I'd say it needs a framebuffer device which I do not have
Use the PCI variant ;-).
Also, the PCI path varies a lot
Obviously. The correct PCI path would need to be found first.
(I used "lspci|grep VGA", hehe.)
None of this works at all on non-Linux systems, for that matter. (Wine does run on non-Linux systems, in case you didn't realize that.)
Default to 64MB on those systems.
This reports the wrong values for me in one machine with a 32M video card: 134217728
Ok. Guess it's rubbish then, too bad. Oh well.
It might be possible to guesstimate the available memory: http://delphi3d.net/articles/viewarticle.php?article=texman.htm
Promising!
But perhaps an easier approach would be to fix every Linux driver to report the correct number in sysfs. I'm pretty sure each driver knows how much RAM is on the card already, so it should be trivial..
Am Donnerstag 13 Juli 2006 17:20 schrieb Vijay Kiran Kamuju:
May be using we can use the internals of lspci and pciutils. So that we can calculate the VGA memory on the fly. fglrx and the nvidia driver have an extension to read the video memory. This will give the correct value for most cards out there. For radeon dri and intel dri we could talk to the developers of those drivers.
Vijay Kiran Kamuju schrieb:
May be using we can use the internals of lspci and pciutils. So that we can calculate the VGA memory on the fly.
On 7/13/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote:
I'd say it needs a framebuffer device which I do not have
Use the PCI variant ;-).
Also, the PCI path varies a lot
Obviously. The correct PCI path would need to be found first.
(I used "lspci|grep VGA", hehe.)
None of this works at all on non-Linux systems, for that matter. (Wine does run on non-Linux systems, in case you didn't realize that.)
Default to 64MB on those systems.
This reports the wrong values for me in one machine with a 32M video card: 134217728
Ok. Guess it's rubbish then, too bad. Oh well.
It might be possible to guesstimate the available memory: http://delphi3d.net/articles/viewarticle.php?article=texman.htm quoting from the article:
The implementation of the glAreTexturesResident() function, which is so critical for this technique, has not been properly standardized. [...] This makes the technique described in this article pretty much useless - unless you want to put "NVidia 3D cards only" in your app's system requirements. ---
Promising!
But perhaps an easier approach would be to fix every Linux driver to report the correct number in sysfs. I'm pretty sure each driver knows how much RAM is on the card already, so it should be trivial..
Isn't the amount of _free_ vram what wine really is interested in? The information how much RAM the card has is pretty much useless.
And the sysfs approach won't work when using X over ssh or similiar.
Isn't the amount of _free_ vram what wine really is interested in? The information how much RAM the card has is pretty much useless.
And the sysfs approach won't work when using X over ssh or similiar.
That's too bad anyway, since there's no shared memory etc. I would imagine it would be painfully slow to run 3D applications with any nontrivial texture or sizes or geometry complexities over a remote X connection. Especially if textures are dynamic like they became in some games (say an in-game "TV" etc.). I haven't checked, so maybe I'm well off base here ;) Cheers, Kuba
It might be possible to guesstimate the available memory: http://delphi3d.net/articles/viewarticle.php?article=texman.htm
quoting from the article: --- The implementation of the glAreTexturesResident() function, which is so critical for this technique, has not been properly standardized. [...] This makes the technique described in this article pretty much useless - unless you want to put "NVidia 3D cards only" in your app's system requirements. ---
Not to mention that, especially with accelerated compositing, that the size of textures that could fit could be significantly less than the amount of VRAM the card has.
Isn't the amount of _free_ vram what wine really is interested in? The information how much RAM the card has is pretty much useless.
The amount of free VRAM is rather volatile. Most games would use the total amount of VRAM as a guide to how much to attempt to put onto the card, not as an absolute "this is how much you have to work with". Besides, if the specs for a D3D function say it returns the total amount of VRAM, WineD3D would need to return the total amount of VRAM. Something you maybe could try, if you can determine the location of the X log file.. An nVidia card with the proprietary drivers: # grep VideoRAM /var/log/Xorg.0.log (--) NVIDIA(0): VideoRAM: 262144 kBytes A built-in Intel card with the open-source drivers: # grep VideoRAM /var/log/Xorg.0.log (--) I810(0): Pre-allocated VideoRAM: 7932 kByte (==) I810(0): VideoRAM: 65536 kByte I couldn't find anyone with an ATi card to test with, unfortunately.
Chris schrieb:
It might be possible to guesstimate the available memory: http://delphi3d.net/articles/viewarticle.php?article=texman.htm quoting from the article:
The implementation of the glAreTexturesResident() function, which is so critical for this technique, has not been properly standardized. [...] This makes the technique described in this article pretty much useless - unless you want to put "NVidia 3D cards only" in your app's system requirements. ---
Not to mention that, especially with accelerated compositing, that the size of textures that could fit could be significantly less than the amount of VRAM the card has.
Isn't the amount of _free_ vram what wine really is interested in? The information how much RAM the card has is pretty much useless.
The amount of free VRAM is rather volatile. Most games would use the total amount of VRAM as a guide to how much to attempt to put onto the card, not as an absolute "this is how much you have to work with". Besides, if the specs for a D3D function say it returns the total amount of VRAM, WineD3D would need to return the total amount of VRAM. hm i thought we were talking about IDirect3DDevice9::GetAvailableTextureMem which does not return the total amount but the amount that is currently available.
Something you maybe could try, if you can determine the location of the X log file..
An nVidia card with the proprietary drivers:
# grep VideoRAM /var/log/Xorg.0.log (--) NVIDIA(0): VideoRAM: 262144 kBytes
A built-in Intel card with the open-source drivers:
# grep VideoRAM /var/log/Xorg.0.log (--) I810(0): Pre-allocated VideoRAM: 7932 kByte (==) I810(0): VideoRAM: 65536 kByte
I couldn't find anyone with an ATi card to test with, unfortunately. # grep VideoRAM /var/log/Xorg.0.log (--) RADEON(0): Mapped VideoRAM: 65536 kByte (128 bit DDR SDRAM)
still kinda ugly solution imo
# grep VideoRAM /var/log/Xorg.0.log (--) NVIDIA(0): VideoRAM: 262144 kBytes
A built-in Intel card with the open-source drivers:
# grep VideoRAM /var/log/Xorg.0.log (--) I810(0): Pre-allocated VideoRAM: 7932 kByte (==) I810(0): VideoRAM: 65536 kByte
I couldn't find anyone with an ATi card to test with, unfortunately.
I use ATI's fglrx: grep VideoRAM /var/log/Xorg.0.log (--) fglrx(0): VideoRAM: 131072 kByte, Type: DDR SGRAM / SDRAM Seems to be right *g* But again, Xorg log is also only local... Ciao, Olaf
On 13.07.2006 18:00, Peter Beutner wrote:
It might be possible to guesstimate the available memory: http://delphi3d.net/articles/viewarticle.php?article=texman.htm quoting from the article:
The implementation of the glAreTexturesResident() function, which is so critical for this technique, has not been properly standardized. [...] This makes the technique described in this article pretty much useless - unless you want to put "NVidia 3D cards only" in your app's system requirements. ---
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. Getting the RAM amount directly from the driver is definitely preferable. However, there's no universal way to do that - so consider the glAreTexturesResident() approach as a fallback in case no better way is available. -f.r.
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.
On 14/07/06, Stefan Dösinger <stefandoesinger(a)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. The amount of texture memory and the amount of video memory is not the same.
On 11.07.2006 18:23, Christoph Frick wrote:
until an easy way can be found, would it be better to apply this patch and state this fact in the error-messages wine produces?
It might be possible to guesstimate the available memory: http://delphi3d.net/articles/viewarticle.php?article=texman.htm -f.r.
participants (12)
-
Carl Fongheiser -
Chris -
Christoph Frick -
Frank Richter -
H. Verbeet -
Kuba Ober -
Molle Bestefich -
Neil Skrypuch -
Olaf Leidinger -
Peter Beutner -
Stefan Dösinger -
Vijay Kiran Kamuju