[MPlayer-dev-eng] [PATCH] Make vo_gl / fragment programs work with Mesa

[Matthias Hopf]

Hey Reimar,

On Feb 24, 07 17:49:33 +0100, Reimar Döffinger wrote:
> On Sat, Feb 24, 2007 at 03:16:32PM +0100, Matthias Hopf wrote:
> > Basically, Mesa has a glProgramString function and exports it, which
> > seems completely uncorrelated to glProgramStringARB (I don't exactly
> > remember whether this is an OpenGL 2.0 call, but I doubt so), which
> > results in a segfault as soon as a fragment program is to be loaded.
> > Same for glGenPrograms etc.
> 
> glGenPrograms is in OpenGL 2.0 and I supposed it would be compatible

Program objects in OpenGL 2.0 are created with glCreateProgram(), with a
different prototype to glGenProgram*(). I cannot find GenProgram
mentioned anywhere in both the 2.0 and 2.1 documents.

> with the ARB variant. glProgramString is not even in OpenGL 2.1 so I
> don't know why it exists in Mesa.

I suppose it is an internal function.... Why it is exposed as an API
function pointer, I don't know. Same for glGenProgram.

> Is that the only one that is causing problems? If so I'd prefer to
> change only that, at least for now.

AFAIK you are actually required to use functions for a single extension
consistently.  That's why I would suggest using the other related
functions and not a mixture, which is not guaranteed to work at all. 

I had one segfault in glProgramString, and one in glGenPrograms.

> > Also, all fragment programs in gl_common.c are ARB fragment programs, so
> > having a fallback for NV fragment programs (which have different syntax)
> > is actually harmful.
> 
> Actually, that's not what it does for all I can tell. NV and ARB programs
> are distinguished by their header. I might be missing something though,

The NV spec does not mention ARB in any way, so that glProgramStringARB
works for NV programs is just pure luck (or rather a design decision by
the nvidia developers, I assume them to call the same internal function
in the driver), and *not* what you should use. Also, with older versions
of the driver that didn't have ARB calls, ARB programs wouldn't have
been accepted (because ARB wasn't specified / implemented back then).

So basic notion: For ARB fragment programs, you have to use ARB function
calls.

> since there does not seem to be any glProgramStringNV function, but
> replacing all other Program functions with the NV variants poses no
> problem.

It's actually called glLoadProgramNV(), and has a different prototype
and a bit different semantics than glProgramStringARB().  The other
functions have the same prototypes and almost identical semantics.

> > That's the good news. The bad news is that neither lscale=1 nor yuv>2
> > gets hardware accelerated, because we hit several driver limits. First,
> > we get:
> 
> You can probably forget lscale, it is just much too complex.

No, probably not. The chips *should* be capable of that. I'll ask Keith
later today.

> Also, the problems should be very different depending on which yuv
> option exactly you use...

Sure :)

> > --- libvo/gl_common.c	(revision 22306)
> > +++ libvo/gl_common.c	(working copy)
> > @@ -682,11 +682,15 @@
> >    /* first y-interpolation */ \
> >    "ADD coord, fragment.texcoord[%c].xyxy, cdelta.xyxw;" \
> >    "ADD coord2, fragment.texcoord[%c].xyxy, cdelta.zyzw;" \
> > -  "TEX a.r, coord.xyxy, texture[%c], "textype";" \
> > -  "TEX a.g, coord.zwzw, texture[%c], "textype";" \
> > +  "MOV tmp, coord.xyxy;" \
> > +  "TEX a.r, tmp, texture[%c], "textype";" \
> 
> That's pointless, just remove the swizzle here, it is only there to make

Which was exactly what the driver was complaining about - swizzles in
TEX commands not supported. For the first TEX command, you could ignore
the swizzle, for the second, you can't.

> the code clearer to read. I was not aware it could cause any problems
> ever. Actually, if it does the compiler is really, really stupid. Since

Yes, it is :)
This is still work in progresss.

> only the first two components are used it can hardly matter how the
> later two are changed.
> 
> > +  "MOV tmp, coord.zwzw;" \
> 
> MOV coord.xy, coord.zwzw;
> Probably should be better, too.

I just did a trivial replace, with not much thinking.
As I said, it's just a proof of concept. This is something that has
(mostly) to be fixed in the driver.

CU

Matthias

-- 
Matthias Hopf <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de