"assumed" graphic card memory

[Christoph Frick]

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/

[H. Verbeet]

On 11/07/06, Christoph Frick  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

[Molle Bestefich]

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?

[Stefan Dösinger]

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.

[Carl Fongheiser]

On 7/12/06, 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?

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

[Neil Skrypuch]

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@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@x2-42 ~ $ ls -lS /sys/class/graphics/fb0/device/resource*
ls: /sys/class/graphics/fb0/device/resource*: No such file or directory

- Neil

[Molle Bestefich]

> 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..

[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.

On 7/13/06, Molle Bestefich  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..

[Stefan Dösinger]

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.

[Peter Beutner]

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  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.

[Kuba Ober]

> 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

[Chris]

> > > > 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.

[Peter Beutner]

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

[Olaf Leidinger]

> # 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

[Frank Richter]

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.

[Stefan Dösinger]

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.

[H. Verbeet]

On 14/07/06, Stefan Dösinger  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.

[Frank Richter]

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.