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.
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.
3. mga_vid's API is too simplistic and does not support the a scaling
rectangle or line strides like XVIDEO does.
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'.
> > > 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.
> 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.
-Billy
_______________________________________________
XFree86 mailing list
XFree86@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/xfree86
