[MPlayer-dev-eng] patch for quadbuffered stereo using "-vo gl2:stereo"

[Stuart Levy]

On Wed, Nov 28, 2007 at 11:09:58PM +0100, Reimar Döffinger wrote:
> Hello,

> Well,
> glPushMatrix();
> glScalef(2, 1, 1);
> drawTextureDisplay();
> glTranslatef(-0.5, 0, 0);
> drawTextureDisplay();
> glPopMatrix();
> (obviously I forgot the parts setting right/left backbuffer)
> 
> sure is not any more complex than fiddling with drawTextureDisplay!

But that sends all the pixels to the graphics system *twice*, and just depends
on opengl clipping to discard the extra texture tiles.  Surely it's
worth a few extra lines of code to avoid using twice the opengl bandwidth?
Doing it my way, we just paint every pixel once -- the left-eye pixels
go only to the left buffer, and the right-eye ones go only to the right buf.
Most of the complexity in drawTextureDisplay() is in handling the
texture tiling -- I'm mostly just changing its iteration limits.

> Not to mention that it can be sped up more easily via DisplayLists, it
> is less of a hindrance to further extending and maintaining (among other
> things, due to containing the code to support stereo in one place), is
> trivial to port to e.g. vo_gl etc.

Can vo_gl handle high-resolution textures?  If that code is doing texture tiling,
it's not obvious to me.  Can it display a 1920x1080 or larger image using -vo gl
if the graphics card only accepts 1K textures, as some do?
Also, at least for the nvidia cards I've been playing with, it's tens of percent
faster to load images into many smaller textures (like 128x128 or 256x256) than
into fewer larger ones (like 1K or bigger).  E.g. on one card here,
I get 298 Mpixels/sec on 256x270 GL_TEXTURE_RECTANGLE_ARB textures to cover
a 1920x1080 window, but only 190 Mpix/sec using a 1Kx1K or 1920x1080 texture.

And -- out of curiosity -- would a display list actually help here?
I'd expect that typically this routine would just load an image into a
batch of texture tiles, display each tile once, then advance to the next image.
(I can see it would help for on-screen display pieces, as vo_gl.c does.)

> Not to mention it doesn't add a math.h dependency...

If that's important, I could avoid calling ceilf with some careful use of (int),
though ceilf seems clearer...  And lots of the other libvo modules use math.h too.

> [...]
> > > The old message was wrong anyway, and the one you add might not be right
> > > either, there can well be quadbuffer stereo support and it still will fail,
> > > e.g. because there is no doublebuffer support.
> > > It should just be replaced by something like "no suitable GLX visual found",
> > > and that is independent of this patch.
> > 
> > There's a new variant in the new attached patch -- how do you like this?
> > I think it might be nice to mention that quadbuffered stereo is required
> > in case of error, since most opengl implementations have all the
> > other requirements.
> 
> I don't know. I simply loathe having any kind of logic in
> message-printing code. I somewhat doubt it is helpful, since it does not
> say what exactly was the problem, and I somewhat doubt that
> "quadbuffered stereo" will mean anything at all to someone who stumbles
> over it by accident.

Hey, at least you can feed the phrase to google or search driver documentation for it!
Of course I'll withdraw it if you insist, but am hoping it will be more
helpful than a generic opengl error.  It's easy to think a display
is configured for stereo when some mysterious obstacle prevents it from
being so (e.g. for nVidia on linux, besides the straightforward driver settings,
you also must disable the Composite extension, and depending on the display device,
may need to set the documented but wierd option "AllowDFPStereo").

> 
> [...]
> > > I guess you give the wrong -monitoraspect. If you want it automated you
> > > probably at least have to hack VOCTRL_UPDATE_SCREENINFO
> > 
> > Could you explain more about what should be updated?  I don't know even
> > what the fields mean, let alone which ones I'm free to change at what point.
> 
> I don't know a good automatic solution. Just use -monitorpixelaspect 2

Hey ho.   Thanks.  Maybe I'll look a little further in hopes of stumbling on an automatic fix...

cheers

   Stuart