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

[Reimar Döffinger]

Hello,
On Sun, Feb 25, 2007 at 11:53:05AM +0100, Matthias Hopf wrote:
> On Feb 24, 07 17:49:33 +0100, Reimar Döffinger wrote:
> > 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.

Right, no idea what I was reading. Probably saw glCreateProgram and my
brain translated it to glGenProgram...
IIRC there was an official statement that these won't even be proposed
for inclusion into OpenGL by ARB, so I changed it to only check for the
ARB variants.

[...]
> > > 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.

Even if it works, I doubt the speed will be much fun...

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

I have no problem optimizing stuff a bit if you can give details
(unfortunately you can't get an Intel card without a whole new PC :-( ).
I wasted some time hacking around ATI stupidity, Intel certainly
deserves no less (after all they finally gave up NetBurst *g*).

> > > --- 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.

I was only suggesting a way to make it smaller again (also one variable
less) so that it might work.

> > 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.

Sure, but if I have an idea how I don't mind making things a bit simpler
from our side.

Greetings,
Reimar Döffinger