Re: [XFree86] 2d performance info
Billy Biggs wrote: 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 ([EMAIL PROTECTED]): 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]. 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. 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
Re: [XFree86] 2d performance info
Billy Biggs wrote: 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. The mga driver does some RENDER acceleration, which reads data from the system memory (the alpha texture, for example). This could perhaps done via DMA. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] 2d performance info
I'm fairly sure i've pushed XFree86 as far as i can without reprogramming anything for 2d performance. I've compiled all of X with -march=athlon-tbird -O2 -mmmx -m3dnow -ftracer using modified flag variables in my host.conf as well as profile compiling which i had X up doing my thing for over a day learning my work load before recompiling it with the new data. My config settings for my matrox g450 are aggressive with agp enabled and backing store enabled, memory overclocked. Still though, my g450 is slow, slower than a G400...that's just the way it was made. There are lots of data on card performance in 3d-land as there are easy direct benchmarks. In 2d-land the only real benchmark i've seen is Xmark which uses x11perf which doesn't measure any realistic workload but rather all of X. But even using this, i've yet to find any real listing of which card is the fastest in 2d on a given system by any sites. This means i have to make a decision for nvidia or ati upgrades based on word of mouth which is hardly reliable. I know ati has more open source support and i'm leaning towards them but i'm not sure how much faster those cards would be on a modern system to see if it would be worth spending a hundred or so on a new video card. X is barable, yea, but i know efficiency wise, 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. I refuse to use the binary only drivers from any card maker so that aside, which card has the best xfree86 support these days while being the fastest, ati or nvidia? 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? Ok that's the end of my rant and questions. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 2d performance info
Ed Sweetman ([EMAIL PROTECTED]): 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? and backing store enabled, Is this good or bad? 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. 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). -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 2d performance info
Billy Biggs wrote: Ed Sweetman ([EMAIL PROTECTED]): 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. 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. and backing store enabled, Is this good or bad? good for drivers that can use it correctly. Bad for ones that cant. 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. 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. 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. But my matrox driver has triple buffered backend scaler video support, something the nv driver doesn't have I believe. ATI however seems to have better hardware support, I'm not sure though because I haven't seen any sort of up to date rundown of video card performance and support (ie. cvs), only for 3d. -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 2d performance info
Ed Sweetman ([EMAIL PROTECTED]): 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
Re: [XFree86] 2d performance info
Billy Biggs wrote: Ed Sweetman ([EMAIL PROTECTED]): 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
