Roland Nagtegaal wrote:
>
> > It might be a big matrix.
> >
> > Could we ask users to do some simple arithmetic in order to
> > compute memory requirements for themselves?
> >
> > For example: if the screen size is W x H pixels and they're running
> > at 16bpp (2 bytes/pixel) then the frame buffer memory required will
> > be about:
> >
> > Front buffer: W * H * 2 bytes/pixel
> > Back buffer: W * H * 2 bytes/pixel
> > Z buffer: W * H * 2 bytes/pixel
> > --------------------------------------
> > total: W * H * 6 bytes
>
> I have a question about this. I have a 32MB Matrox G400 dualhead (but
> use only
> one head). I run X 4.0.3 at 1824x1368 resolution at 16bpp.
>
> According to above formula, to run GLX apps at that resolution, I would
> need
> 1824x1368x6 bytes, plus what is needed for the normal 2D framebuffer, I
> suppose, which is an additional 1824x1368x2 bytes.
Wrong.
The normal 2D framebuffer is the the "front buffer".
In your case, the framebuffer will use 1824 * 1368 * 6 = 14.3 MB.
> That is 19961856 (approx. 20MB) in total. Since I have 32MB this should
> not be
> a problem.
> Yet when I run some of the OpenGL xscreensaver demos, like 'sproingies',
> or
> 'moebius' or 'pulsar', or even the mesa demo 'gloss', I get a black bar
> at the
> top of the (fullscreen) window.
> For instance: gloss -geometry 1824x1368 gives me a screen-sized window,
> but the window is not filled itself. The top 200 rows of pixels or so
> are
> black.
> Could it be that not all of my graphics memory is used or detected?
At first I was going to suggest a memory management bug in the driver
but after a quick check I see that the maximum viewport size in
Mesa 3.4.1 is 2048 x 1200.
I didn't realize that people were running screens that tall.
I'll bump the vertical limit to 1400 or so for the next release.
Is anyone running even taller screens?
-Brian
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
