Hi Ed,
I would rather discuss 2D performance than mga_vid but I am not sure where you want to go since your reply focused mostly on mga_vid. I'll explain my position a little better on mga_vid though, hope it's useful.
I used mga_vid as an example of getting some more performance out of a slow video card, not as an example of how things should be done.
Ed Sweetman (ed.sweetman@xxxxxxxxx):It indicates that the still developing fbcon code still needs a lot of testing and debugging and maturing before it gets to be something i and many others consider using. Plus, even when it is used, i dont see any increase in performance and in fact, it limits me to the use of only the lower 16MB of my video card's memory.
Don't trust this. The video stuff is often quite hacky and it's not very good, even for this 'well supported' card. Specs are widely available yet all of these drivers could still use a ton of work, and now the cards are getting quite obsolete.
Dont trust it in what way? I have a G450, I've hacked mplayer's matrox driver to utilize the backend scaler for triple buffering and i've most definitely seen the difference compared to straight xv. It definitely works well on the G450 and support is nearly non-existant for any other card in this area as far as i know.
OK here is what I know, tell me where you think it is wrong.
With mga_vid the application writes directly to video RAM, a performance gain, and it is triple buffered to avoid tearing since the hardware page flips on retrace. XFree86 4.2 (finally) included the patch double buffered XVIDEO in the mga driver. XFree86 is now effectively triple buffered, since applications write to system memory, and you can have one frame queued waiting in video memory.
So the only difference between mga_vid and XVIDEO right now is that with XVIDEO, the X server copies the next frame from system memory to video memory, while mga_vid lets the application write to video memory. There is no tearing in either, only a speed difference.
Disadvantages to using mga_vid:
1. It is in conflict with the X server and fbcon drivers for the same hardware. Switching VTs while mga_vid is being used causes system crashes. There is no locking for these competing drivers. XVIDEO colour key gets out of sync with the mga_vid colour key.
first off, mga_vid does not need fbcon, and everything is more stable when fbcon is not enabled and being used. I've yet to see mga_vid cause a crash on my X when switching VT's (not that you'd ever need to really). I dont know why or what color keys getting out of sync between the two video output methods matter since they use the same hardware and thus cant be used at the same time. Just like xv cant be used to display two video outputs on the same screen at the same time.
I know mga_vid does not need fbcon, if things are more stable when it's not being used, doesn't this indicate that something is wrong? I wrote the mga_vid driver for my application, and I have had bug reports about crashes on VT switching. So has mplayer [1].
2. mga_vid assumes the 'end' of video RAM is available and does not
coordinate with the X server for allocating video memory. It has
been known to cause corruption of the desktop and app pixmaps.
I've used mga_vid for months. I've seen no corruption of anything and my desktop is pretty big. I have dozens of windows with plenty of pixmaps in all of them open all the time across 4 desktops of 1280x1024 @ 32bpp (24bpp with 32bpp framebuffer).
I have had bug reports. Just looking at the source does it not indicate to you that this can happen? Is your X just not storing any pixmaps in off-screen memory? Maybe this is what backing-store did for you? Look at the mga_vid code: it just uses the "end" of video RAM and hopes it is not being used !! If anything was stored in the last 2M of video memory you would be screwed!
I suppose it's quite possible than even with all the stuff i do in X, i still dont use 32MB of video ram, and i've been lucky.
3. mga_vid's API is too simplistic and does not support the a scaling rectangle or line strides like XVIDEO does.
Since i've seen mga_vid display video just as xvideo does, i dont see how these other features matter. I can scale an mga_vid window TONS faster than xvideo and doing so repeatedly does not crash X, which doing so with an xvideo window does, as well as slow everything to a grinding halt when it doesn't.
I have never seen X crash or even slow down while I am resizing my application which uses XVIDEO on my G400. Furthermore, my application uses the clipping rectangle features of XVIDEO which our mga_vid driver does not support because the API is so simplistic. I've talked to the mplayer developers about this and we all agree that the mga_vid code is messy and hackish and should really be rewritten.
I did it not 2 days ago. i have the v4l module doing xvideo scaling for xawtv on another desktop while i mess around with the movie on the current desktop. Just going through fullscreen and window repeatedly did it in, lagging up the system much more than mga_vid was. This could also be related to tsc problems I and other people have been having though. Not much on the kernel mailing list responding to it though.
The mplayer developers seem to do a lot of agreeing on this and that but not doing anything about it. Tempel and I have at least cleaned up the current mga_vid code enough to make it useable while they go about finding something to replace it the "right" way but they dont seem to be willing to patch the buggy non-working code they have.
I'm still unsure as to the advantage of clipping rectangle features in video playback. Do you mean when something covers the video window the clipping of the displayed video is accelerated ? What is "clipping rectangle features"
Nobody said it was the best way, but it performs better than the alternatives. The "triple buffering" that xvideo does you say, still doesn't produce video output that looks as nice as mga_vid's. And by looking nice i mean motion looks smoother on 24fps video. there seems to be a barely, maybe unconscious perception of latency difference.
I think your system is just slow then if you see smoother video with mga_vid.
the G450 compared to the G400 is noticably slower.
Do you think the mga_vid is a good design? How do you see it fitting into the X architecture for other cards? What about cards that support DMA transfers of video data? As I mentioned, with the NVIDIA drivers, we get rockstar performance with XVIDEO, better than we could get using the mga_vid method.
Hell no, It looks like code ripped from directfb actually, to access the backend scaler. Not that it is, just saying it might as well have been. There is no benchmarks to say for certain if mga_vid is performing better than xvideo on my system. So i think we're stuck at that point.
Would it not be better for someone to just fix the mga driver to use DMA to transfer XVIDEO data to the video card? The specs for the G4xx cards are available, and from what I can tell, they should support this. Why has this not been done?
*shrugs* why isn't render totally hardware accelerated yet? The people who know how to do these things in X dont have the time or motivation, newer better and faster cards exist to make continuing to work on older slower cards less and less appealing for free labor.
-Billy
[1] http://zebra.fh-weingarten.de/~maxi/html/mplayer-users/2003-11/msg00145.html
_______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
_______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
