[MPlayer-dev-eng] [PATCH] Make vo_gl / fragment programs work with Mesa
mat at mshopf.de
Sun Feb 25 11:53:05 CET 2007
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
> since there does not seem to be any glProgramStringNV function, but
> replacing all other Program functions with the NV variants poses no
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
> Also, the problems should be very different depending on which yuv
> option exactly you use...
> > --- 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.
Matthias Hopf <mhopf at suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat at mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
More information about the MPlayer-dev-eng