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

[Matthias Hopf]

Sorry for the delay. Mail at University sucks right now, doesn't seem to
be delivered at all any more to mailing lists... :-(

On Feb 25, 07 17:15:00 +0100, Reimar Döffinger wrote:
> Right, no idea what I was reading. Probably saw glCreateProgram and my
> brain translated it to glGenProgram...

Probably.
At first, I really liked your idea of first scanning for non-extension
function pointers, but later I remembered that subtle semantic changes
could definitely be a problem.

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

Yep, these "low level" calls will never be "official" OpenGL.

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

Ok, now I know that the chips only support a maximum of 4 dependent
texture lookups *in* *hardware*. That still could be enough, if I move
the calculation of the cubic texture lookup offsets outside the fragment
program. That should be doable, with two more interpolants.

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

Fragment programs on intel should be fast enough, except maybe for
really big screens. YUV color conversion is trivially possible, so I
guess bicubic filtering should be as well.

> 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 :-( ).

Yeah, a pitty.
Well, as soon as I've got some spare time ;)

> I wasted some time hacking around ATI stupidity, Intel certainly
> deserves no less (after all they finally gave up NetBurst *g*).

ROTFL

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

Sure. Just forget about that code ATM. It was only a test case.

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