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

[Reimar Döffinger]

Hello,
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
with the ARB variant. glProgramString is not even in OpenGL 2.1 so I
don't know why it exists in Mesa.
Is that the only one that is causing problems? If so I'd prefer to
change only that, at least for now.

> 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,
since there does not seem to be any glProgramStringNV function, but
replacing all other Program functions with the NV variants poses no
problem.

> 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.
Also, the problems should be very different depending on which yuv
option exactly you use...

> By patching the ARB program with the second patch (do not apply to SVN!)
> we can get around this issue (patch only showcase for lscale=1), but
> that makes the program larger, and we hit a second limit we cannot
> circumvent:

Well, it probably was too large before, too...
But: 

> Index: libvo/gl_common.c
> ===================================================================
> --- 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
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
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.

> +  "TEX a.g, tmp, texture[%c], "textype";" \

Similarly in the other places.

Greetings,
Reimar Döffinger