Re: Frambuffer configuration Onyx IR

New Message Reply Date view Thread view Subject view Author view

Eric Kunze (ekunze++at++yacko.engr.sgi.com)
Thu, 15 Jul 1999 11:26:08 -0700


> No, the problem is that when you use quad-buffer stereo, it appears to
> me that you
> can only use stereo channel configurations that only use 1/2 of the
> framebuffer.
> The other half is used by the (not seen in ircombine) second dualbuffers
> (hence quad).
> With old stereomode, the framebuffer is partitioned in two halfs anyway,
> reducing the
> actual vertical resolution.
> Can anyone confirm that?

  Ircombine will report what pixel depth you get for a given framebuffer size,
number of RMs combination. The channel configuration has nothing to do with
the visuals available. You can get stereo visuals without having any stereo
channels running.

  The visuals available are dependant only on the pixel depth. If you have a
single RM and are doing a framebuffer of 2560x1024, you are getting small
pixels. With small pixels, you cannot get quadbuffer stereo and multisampling
and Z. You can get quadbuffer stereo and Z, just not multisampling. Samples
require a lot of framebuffer memory.

  If you add a second RM, you can go up to medium pixel depth, which does
allow samples, db, stereo and Z. If you bring up the "Edit Globals" button in
ircombine, you can see what pixel depth a combination will have. You can use
the "Edit User Defined Hardware" option to see what pixel depths various #s of
RMs will give you. Running findvis or glxinfo -t will show you what visuals
are currently available.

> Works ok for my friends (with a 4pipe "lots of RM") too, so it should
> work here too, the question is the following:
> Does multisampling uses additional FB- resources that i have to keep
> in mind when i try to configure it?

  Yes, multisampling uses a lot of framebuffer resources. Your friend with 4
RMs has 4x as much framebuffer as you, that is how they manage to get the
visuals you don't. 2RMs should be enough for what you want though.

Eric

-- 
Eric Kunze
ekunze++at++engr.sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Thu Jul 15 1999 - 11:26:17 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.