Ed Sweetman (ed.sweetman@xxxxxxxxx):
My config settings for my matrox g450 are aggressive with agp enabled
Does the open source driver use DMA at all? If it doesn't, do the higher AGP modes even help at all?
for matrox? I believe so. I'm sure some drivers do not but i'd suspect matrox's to.
Can you back this up somehow? I have a Matrox G400 card. The open source "mga" driver clearly does not do DMA transfers for MIT-SHM uploads to video memory, nor for XVIDEO (see the source). Using Option "AGPMode" I see no difference at all in SHM or XVIDEO performance.
Or did you mean something else by "aggressive with agp enabled" ?
RENDER does not use dma at all, which hinders performance a lot i would think seeing as how render is used from anti-aliased fonts to alphablending and the more programs use either the more render's performance comes into question.
How would RENDER use DMA? I know keithp talks about doing things like DMA'ing video data FROM video memory back to system memory in order to do compositing on the CPU, then send it back, but I think that idea is silly.
and backing store enabled,
Is this good or bad?
good for drivers that can use it correctly. Bad for ones that cant.
Can you tell me what this feature does and how it would help performance?
i'm being held back by this G450 despite all the support for using the backend scaler and triple buffering for video playback that i use often.
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.
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).
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.
4. Requires a kernel module.
Advantages to using mga_vid:
1. Performance gain.
It has been arguged that the performance gain is negligible if the XVIDEO driver actually DMA'ed frames to video memory, since AFAICT the card does support it, and it is done by Matrox's binary HAL driver for these cards. For an example of this, see the NVIDIA binary drivers, which use DMA and can get rockstar upload speeds using DMA. Having mplayer render to system memory and then the NVIDIA card upload it using DMA is faster than having mplayer write directly to video memory. It is unclear to me, especially given all of the disadvantages above, that the mga_vid design is the 'right way'.
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.
And are there any other 2d Xfree86 benchmarks out there that benchmark the functions and extensions actually used in X these days like render and shape and pixmap manipulation and all that stuff?
I am not sure of one in particular but the ones we like to use for supporting our app are mostly just 'x11perf -shmput500' which is usually a good indication of what any sort of 2D app would need (at least it's a good estimate for video or 2D game performance).
That's one test of one call. Hardly a measure of performance for the average X users workload.
No, like I said, it's a good indication for 2D video game performance, since it tests how fast MIT-SHM image uploads are. So, what SDL would use to draw graphics on your screen.
Though it is probably the most important call dealing with performance. I've done it on my G450 athlon system and my P4 nvidia system using xfree86's nv driver and the nv driver completely destroys the G450.
The nv driver is just using the CPU to copy, it is not using DMA. Maybe something is broken on your athlon system, or the motherboard just sucks, or you forgot to enable MTRRs. You should compare in the same machine for kicks.
Even not using dma, the video card itself is just so much faster than the G450 that it totally outperforms it. The G400 outperforms the G450 so this is not a surprise at all.
But my matrox driver has triple buffered backend scaler video support, something the nv driver doesn't have I believe.
The XVIDEO implementation in "nv" is double buffered on the video card, and as I described above, this makes it effectively triple buffered since applications write to system memory.
except as you also stated, the drivers dont use dma, and system memory is slower than the video card's memory, so even though the copy is there, it's not equivilant to real triple buffering on the video card.
-Billy
_______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
_______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
