On Mon, 4 Nov 2002, Marc Aurele La France wrote:
I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits=
2147483648. The Xserver calculates the memory in bits when validating
the mode.
No, it doesn't. apertureSize is in bytes.
apertureSize is indeed in bytes, but in
On Thu, Nov 07, 2002 at 02:11:46PM -0700, Marc Aurele La France wrote:
[relevant, cogent data snipped]
I've committed a change that should be able to handle video memory sizes
of up to 8GB.
I've got to get me one of *these* cards! Woot!
Kurt
--
Don't get suckered in by the comments -- they
Title: RE: [Xpert]256 megs board fails Validation,
sorry, but your number theory has some error.
2^1 = 2 (1 bit, counting from 0 to 1 = 2 values)
2^2 = 4 (2 bits, counting from 0 to 3 = 4 values)
2^4 = 8 (3 bits counting from 0 to 7 = 8 values)
[...]
2^31 = 2 GB
2^32 = 4 GB
an integer
I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits=
2147483648. The Xserver calculates the memory in bits when validating
the mode.
Luugi
Alexander Stohr wrote:
RE: [Xpert]256 megs board fails Validation,
sorry, but your number theory has some error.
2^1 = 2 (1
On Mon, 4 Nov 2002, Luugi Marsan wrote:
There's a problem when validating a given mode. The board I
have has 256
megs and it fails crying that it has insufficient memory for
the given
mode. This happens because the videoRam in bits is equal to
2^31 ( 256
megs). The number
Title: RE: [Xpert]256 megs board fails Validation,
and
thats with boards that can handle bus width with chunks of 256 bit = 32 byte per
access cylce.
i think i do generally object to using signed numbers for
ordinal values. ;-)
if
there is really a limitiation,
then its the question
Marc Aurele La France wrote:
On Mon, 4 Nov 2002, Luugi Marsan wrote:
There's a problem when validating a given mode. The board I
have has 256
megs and it fails crying that it has insufficient memory for
the given
mode. This happens because the videoRam in bits
On Mon, 4 Nov 2002, Luugi Marsan wrote:
I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits=
2147483648. The Xserver calculates the memory in bits when validating
the mode.
No, it doesn't. apertureSize is in bytes.
apertureSize is indeed in bytes, but in xf86Modes.c,
Title: RE: [Xpert]256 megs board fails Validation,
Hmm, looks like a limitation of the inital coders knowledge.
Nothing to worry about in an OpenSource project where lots
of coding youngsters did take part in.
The below coding:
if (mode-HDisplay * mode-VDisplay * scrp
Why not use math?
factor = 1024 * 8 / scrp-fbFormat.bitsPerPixel;
if (mode-HDisplay * mode-VDisplay scrp-videoRam * factor)
return MODE_MEM;
This assumes that scrp-fbFormat.bitsPerPixel is a power of two.
Also, really huge monochrome displays are still vunerable. In
other words, I would
Title: RE: [Xpert]256 megs board fails Validation,
Adam Luter [mailto:[EMAIL PROTECTED]] wrote:
Why not use math?
factor = 1024 * 8 / scrp-fbFormat.bitsPerPixel;
if (mode-HDisplay * mode-VDisplay scrp-videoRam * factor)
return MODE_MEM;
This assumes that scrp-fbFormat.bitsPerPixel
Well you answered my question.
Isn't three going to be the only non-two factor? (Which in my previous
email, hadn't thought possible -- I thought 24bpp was treated as 32bpp).
Anyway the better way (if still doing factoring) is to use a loop like
this:
x = mode-HDisplay
y = mode-VDisplay
z =
12 matches
Mail list logo
