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. Ed Sweetman (ed.sweetman@xxxxxxxxx): > >>>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! > > 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. > 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. 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. 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? -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
