[MPlayer-dev-eng] [PATCH] Make vo_gl / fragment programs work with Mesa
mat at mshopf.de
Wed Feb 28 12:57:55 CET 2007
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...
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*).
> > 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.
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