On 7/14/06, Stefan Dösinger <[EMAIL PROTECTED]> 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. (
On 14/07/06, Stefan Dösinger <[EMAIL PROTECTED]> 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.
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
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 t
> # 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
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
> >> > 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
> 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
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 <[EMAIL PROTECTED]> wrote:
>> > I'd say it needs a framebuffer device which I do not have
>>
>> Use the PCI variant ;-).
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
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 <[EMAIL PROTECTED]> 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
Obviou
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 ru
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
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/
On 7/12/06, Molle Bestefich <[EMAIL PROTECTED]> 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* | he
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
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
On 11/07/06, Christoph Frick <[EMAIL PROTECTED]> 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
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
all
19 matches
Mail list logo
