[MPlayer-dev-eng] Re: Should I write Voodoo Banshee VIDIX driver?
albeu at free.fr
Wed Mar 17 18:03:51 CET 2004
Hi Georgi Petrov,
on Fri, 12 Mar 2004 23:18:18 -0800 (PST) you wrote:
> A'rpi and Diego, thank you people
> Until today I had hard time locating tdfx driver in the CVS tree, but
> last night I downloaded it's source. Yesterday I ported what I could
> from tdfx_vid and by looking through other VIDIX drivers. Now I have
> the best - XFree86's tdfx :)
> The Banshee VIDIX driver is *almost* ready for alpha stage testing
> (at the moment it displays something, but it's completely scrambled:)
> Today I have ~ 8-9 hours to develop and I think I'll be ready with at
> least working from first sight driver in a week :)
> As nothing will change in terms of CPU usage when I fix the displayed
> image, I can say that what I measured now is lower than with XVideo.
> It seems that this driver will be faster than Xv.
> One question (I'm curious): Direct Rendering. I know about method 1
> and method 2 and the question is:
> 1) With libavcodec and XVideo which method is possible/working?
> 2) With libavcodec and VIDIX which method is possible/working?
> That's all for now. When I have at least beta version, I'll publish
> the sources, so anyone could help further :)
> Ahhh, yes, my motivation after all - I mean why I write the VIDIX
> driver, when there are XVideo, tdfxfb and tdfx_vid:
> Weaknesses of each one:
> 1) XVideo: IMHO this is the best from the three. The problem - it's
> little slow and the last few (2-4) lines from the image are almost
> always incorrect (and flicking). I found no explanation and every
> time I had to use -vf crop with height -4 lines.
> I found the same problem with xine, so it's XVideo dependent issue
> with the Banshee :(
> Otherwise XVideo is right, I think. I ask once again: how does it
> perform DR with libavcodec?
DR help a bit but xvideo so sloooow :((((
> 2) tdfxfb: Very nice and good idea, BUT - it doesn't create overlay.
Yes. In theory it could be done. Feel free to do it ;)
However you probably can't use AGP move, so it's still not that fast.
> 3) tdfx_vid: *Could be the best*, but lacks subtitle support!!! This
> is serious.
vf_expand ? Imho there is no need to dup even more code in MPlayer. But
feel free to do it.
> Also, refer to one of my previous posts:
> There I explain that tdfx_vid CAN turn bilinear filtering on, but by
> default it doesn't! Can be fixed by ~2 lines patch. Result? Again
> poor qulity when resizing!
iirc there is a limitation. The bilinear filtering can only be enabled
in 1x mode (whatever that is) according to the specs. i have. So the code
check that and then enable bilinear filtering if possible.
Now if you can set all the time a patch is welcome.
> Also I don't like the idea of having it as a kernel module, don't
> know why :) Just this can't be the way :) BTW, I think it can't be
> inserted in 2.6.x kernel, is it so? Ohhh, problems...
It's at kernel level bcs you need to interface with the AGP mem.
I never was able to use the AGP stuff from user space (even the simplest
code samples failed miserably) so i turned to a kernel module.
I was also nice to see how you do modules ;)
> On the other side, I think that VIDIX driver will solve all of those
> problems. Wish me luck :)
I did considered VIDIX. But i soon understood VIDIX will never ever fit
with the banshee design.
VIDIX assume the card have a nice overlay wich support a given number of
The banshee overlay only support YUY2 and BGR16. That's it, it can't even
downscale. For all the rest you need to use the internal converter/scaler.
So in VIDIX to correctly support all colorspace you would need to implement
all this magic inside the driver. That was not an acceptable solution.
So i wrote tdfx_vid wich only give access to the basics functions of the
card. Then the vo do all the needed black magic to have these bit showup
on the screen as fast as possible :)
Anyway good luck with VIDIX if you really thinks that's worth it :)
Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.
More information about the MPlayer-dev-eng