[XFree86] mem issues with G450 mga and matroxfb
I'm aware that the accel features of matroxfb (ala 2.5/2.6) can only take advantage of the lower 16MB of a 32MB G450 card. My question revolves around the fact that fbset -i tells me my card has 16MB even though dmesg reports the driver detecting 32MB like it should. I hacked mga_vid (mplayer's video kernel device driver for matroxfb) so that it works with 2.6 and it also detects 32MB. Now all of this would be ok because the comments in matroxfb says the accel features is all that is limited by 16MB and that it can still use all 32MB for display and such while accelerated. The problem is X only reports detecting what fbset reports as my video card's memory size and because i have matroxfb loaded, it ignores videoram directives in the config file. xaa isn't using the same amount of cache that it normally would without the framebuffer driver loaded so i am assuming X is not seeing 32MB like the matroxfb driver says it should be able to do. Now on top of this. X seems to not be using the mtrr's that the matroxfb driver setup. mtrr: no MTRR for e400,100 found is what X reports according to dmesg. and xfree86.log shows this as what is being requested. This is what is in my /proc/mtrr file for the video card. reg02: base=0xe400 (3648MB), size= 32MB: write-combining, count=3 reg05: base=0xe000 (3584MB), size= 64MB: write-combining, count=1 One appears to be the video card's memory, the other agp's access to system memory. Perhaps this is due to the 16MB visible thing? ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] freetype2 problems with cvs
Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
David Dawes wrote: On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree. I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
David Dawes wrote: On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by ttobjs.h isn't a public interface, so naturally it isn't installed. If we can avoid using it, that'd be good. But it's more important that our freetype backend works correctly at this point in the release cycle :-) not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree. The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. well i'm not sure what "wrong" would be because i dont know when it's supposed to use this local copy and when it's supposed to use the system and why it even needs the system one at all. I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir. Well, the build of the module version of the freetype backend is actually a build of freetype itself, hence it needs the freetype source rather than a freetype installation. This also means that it's fairly closely tuned to the version of freetype we're using. Don't expect that to work against an external source tree of a newer version without some tuning. The non-module freetype backend only requires ttobjs.h from the build tree, and editing lib/font/FreeType/Imakefile would allow that to find ttobjs.h from elsewhere. So what's the point of having "#define freetype2" if we're going to build our own local copy of freetype2 anyway? Why link to any external freetype2. If you want to build against an external *installation* (not build tree) of a newer freetype version, then keep extras/freetype2 around, and that should work with the patch I sent, providing the public interfaces are backward compatible. That's what I thought your original email was about. If you want to go beyond that and use an external build tree so that nothing in xc/extras/freetype2 is ever used, then you're on your own for now, or you'll have to wait until after 4.4 is out, when we'll probably look at importing a newer version of freetype. David But why does xfree86 need to have it's own build of freetype2 when every other userspace programs that use freetype2 just use the library interface like they're supposed to? For instance, freedesktop.org's Xserver links to freetype and doesn't require a build of it's own freetype2 library locally, it links to the system one. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] freetype2 problems with cvs
You wanted an example where things were getting mixed up. Here you go. In file included from /usr/local/include/freetype2/freetype/internal/ftobjs.h:31, from /usr/local/include/freetype2/freetype/internal/tttypes.h:26, from ftfuncs.c:53: /usr/local/include/freetype2/freetype/ftrender.h:24:21: freetype/ftmodule.h: No such file or directory Here we clearly see a system header being called from the local source tree's "ftheader.h" which has FT_MODULE_H defined as freetype/ftmodule.h instead of the newer ftmodapi.h which is what my system ftheader.h has defined. This is what happens when you have two conflicting versions of a library and you have to manually -I the directory for each one to use them. include "something.h" gets the same meaning as include and thus we get a mixing of headers. Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote: Not sure if this is the place for bugs, in fact i really think it's [EMAIL PROTECTED] so i'll cc it to them too. It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors? Something like the attached patch should take care of most of it. Let me know if it works. Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently? The patch attached should address the other parts of lib/font/FreeType. David Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by ttobjs.h isn't a public interface, so naturally it isn't installed. If we can avoid using it, that'd be good. But it's more important that our freetype backend works correctly at this point in the release cycle :-) not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree. The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. well i'm not sure what "wrong" would be because i dont know when it's supposed to use this local copy and when it's supposed to use the system and why it even needs the system one at all. I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir. Well, the build of the module version of the freetype backend is actually a build of freetype itself, hence it needs the freetype source rather than a freetype installation. This also means that it's fairly closely tuned to the version of freetype we're using. Don't expect that to work against an external source tree of a newer version without some tuning. The non-module freetype backend only requires ttobjs.h from the build tree, and editing lib/font/FreeType/Imakefile would allow that to find ttobjs.h from elsewhere. So what's the point of having "#define freetype2" if we're going to build our own local copy of freetype2 anyway? Why link to any external freetype2. If you want to build against an external *installation* (not build tree) of a newer freetype version, then keep extras/freetype2 around, and that should work with the patch I sent, providing the public interfaces are backward compatible. That's what
Re: [XFree86] freetype2 problems with cvs
David Dawes wrote: On Thu, Nov 20, 2003 at 01:29:13AM -0500, Ed Sweetman wrote: David Dawes wrote: On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote: The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used. well i'm not sure what "wrong" would be because i dont know when it's What you consider "wrong". :-) supposed to use this local copy and when it's supposed to use the system and why it even needs the system one at all. The system one is only used for the module freetype backend build. In fact last night I committed a change that moves it (and some other locally modified headers) to the module directory so they can't be used by anything else. In my build tests with the patch, it only uses the local ft2build.h in that case. That's why if you're seeing something different I need some specific details in order to follow it up. So what's the point of having "#define freetype2" if we're going to build our own local copy of freetype2 anyway? Why link to any external freetype2. So because one out of the 4 or 5 things that reference freetype2 ignores the external one, we shouldn't allow the external one at all? But why does xfree86 need to have it's own build of freetype2 when every other userspace programs that use freetype2 just use the library interface like they're supposed to? For instance, freedesktop.org's Xserver links to freetype and doesn't require a build of it's own freetype2 library locally, it links to the system one. If you build a non-modular XFree86 server, then you get exactly that. Add '#define DoLoadableServer NO' to you host.def. You don't get that for the (default) modular XFree86 server because nobody has done the work necessary to build an XFree86 "freetype" backend module that can request that an external freetype library be loaded on demand. Remember the backend font modules are loaded optionally by the modular XFree86 server, so modules that use specific external interfaces should cause those interface to get loaded as required rather than requiring the core XFree86 binary to be linked against all conceivable external interfaces in advance. Until that work is done, the freetype backend module needs to contain its own complete copy of libfreetype. Feel free to do the work necessary to correct this obvious anomaly :-). The ttobjs.h issue needs to be addressed one way or another too, either by findind an equivalent public interface, or creating an equivalent public interface, so that this user-mode program can do what it needs to do without knowing more about the freetype internals than it has any right to :-) David Ok, so the module responsible for the actual rendering in Xfree86 is compiling against the local copy of freetype2 right? The reason why I thought there was no reason to link to a local source tree because you're building it into a module, is that there are plenty of examples of programs with plugins that link to libraries like gtk and such without having local copies of such libraries. I take it this is very difficult to do with XFree86 since it was originally written in a non-modular form. Are there flags i can override in host.cf that will let me point xfree86 to a different source tree or can i just dump the system freetype2 source tree into xc/extras and do things that way? Otherwise i'll just compile it non-modular, as I'm still getting freetype2 errors related to headers not correctly being used. missed this one. and several others in the same directory. Here's the latest error after your ftnew.diff make[4]: Entering directory `/usr/src/userspace/xc-new/xc/programs/fonttosfnt' gcc -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../../exports/include/X11/fonts-I/usr/local/include -I/usr/local/include/freetype2/include -I/usr/local/include -I/usr/local/include/freetype2 -I../../exports/include/X11 -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE-DFUNCPROTO=15 -DNARROWPROTO-DXFREE86_FT2-c -o fonttosfnt.o fonttosfnt.c In file included from fonttosfnt.h:28, from fonttosfnt.c:27: /usr/local/include/freetype2/freetype/freetype.h:20:2: #error "`ft2build.h' hasn't been included yet!" It uses quotes in the source file but doesn't appear to need to use the local copy of the source tree so i changed them to use the system copy headers. Of course this doesn't mean it'll be linked to the system library. :-/ it compiled though. make[3]: Leaving dir
[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
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
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
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 an
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. Ed Sweetman ([EMAIL PROTECTED]): I was originally looking to finding a place where a modern benchmarking of the most popular cards used with xfree86 are done. Either that or a list of extensions or features of an extension that are hardware accelerated by a card, much like how individual instructions are shown as being hardware accelerated or not in opengl for 3d support. I'd like to be able to decide if getting an ati card or nvidia card is the way to go for the future of X support if i dont want to use propriatary drivers A simple way of seeing the amount of hardware support for certain cards and the progress in working on hardware support for upcoming features...Stuff similar to how the dri.sourceforge page displays progress of support. I really really dont care about 3d, anything i can do to make the 3d performance of my card into 2d i'll do. Not loading glx, not loading dri in order to increase 2d performance ...these are guess and check things because everywhere you see people telling you to load these things for better X performance, without telling you that it's at the cost of 2d by sucking up memory or worse. Really i'm looking for something that is strictly 2d performance oriented in the direction and showing of progress in xfree86 drivers, in the same way that there are for 3d support. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] shared memory identifier
Mark Vojkovich wrote: That means shmget failed. The kenel config you provided does show SYSVIPC enabled, however... You should run the "nv" driver that came with XFree86 to ensure that you can get the server started with working MIT-SHM support (ie. a benchmark like "x11perf -shmput500" succeeds). Not only do NVIDIA's drivers require SHM support, it is performance critical for other drivers as well. Mark. On Mon, 15 Dec 2003 [EMAIL PROTECTED] wrote: hi, i have a laptop, sony vaio pcg grt 785e. the distribution i use is gentoo 1.4 with kernel 2.4.20 with several bug-fixes. my problem is that i cant get glx extensions to run, when using nvidia-driver-4496. in my opinion, the problem is the message "Failed to obtain a shared memory identifier". How can i solve this? thx already for help, patrick perhaps you didn't mount the shm vfs? usually something like this. tmpfs /dev/shmtmpfs defaults00 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] X cvs priority being set to -1
I've looked everywhere on my system that could be setting the priority of X to -1 and i cant find any scripts that do it. So i assume that the X server, itself, is setting the priority to -1. I am running the cvs pull of X on 2.6.0-test11 on a debian unstable system. I would really appreciate it if anyone knows why this priority setting is taking place tells me. Thanks in advance. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Weirdness in mga_video.c code
I ran across a little oddity while working on the matrox driver. In MGAPutImage, the ScreenInfoPtr sent to it which is then converted to a MGAPtr does not have drmCtx set to a non-zero value even though dri is enabled and working at the time the function is called. I do not understand why this is and consider it to be a bug. Can anyone shed some light on this? This is of course working on the cvs pull of X. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Weirdness in mga_video.c code
line 967 of mga_dri.c has a typo on the comment. it has to be fixed to */ so that the code below it is not commented out. sorry bout that. Ed Sweetman wrote: David Dawes wrote: [EMAIL PROTECTED] is probably a better place for this] On Thu, Dec 18, 2003 at 12:36:25AM -0500, Ed Sweetman wrote: I ran across a little oddity while working on the matrox driver. In MGAPutImage, the ScreenInfoPtr sent to it which is then converted to a MGAPtr does not have drmCtx set to a non-zero value even though dri is enabled and working at the time the function is called. I do not understand why this is and consider it to be a bug. Can anyone shed some light on this? This is of course working on the cvs pull of X. You'll have to be a little more specific/precise. I don't see any field called "drmCtx" in the current XFree86 CVS version of the mga driver, for example. David Well that would be because I added it. Getting my source trees mixed up. Ok. sorry about that. But i do have another question. The reason why I mixed that stuff up was because a friend and I have been working on giving mga DMA'd XV for kicks and giggles and that code was added in the very beginning. Now, we've borrowed a lot from the ati R128 driver in how it uses blits to do DMA. We felt this was viable because the MGA and R128 driver are very similar in how the code is structured and functions. However, this is the first time we've both worked on video cards at this level to this degree and we're having trouble getting the actual blit code to work correctly. I keep getting this error. [drm:mga_verify_blit] *ERROR* *** bad blit: src=0x1 dst=0x300 Obviously I have no idea how to create a blit or something. The mga driver's blit structure is drastically different from the R128's so i've used some inference to fill in the missing pieces and what not. Fallbacks work correctly, so does using the option method of turning it off and on. Once this little hurdle of code is done then we should see the same type of dma benefits (if any) as the R128 card gets. The YV12 code is not expected to work as is for dma due to all the nasty multiplexing and all but there is another patch out there we're going to try and get a hold of that may eliminate the need for all that multiplexing and give us a function like the YUY2 one. Anyway, if any developers wanna check out this blit code and tell me what i'm doing wrong with it... it's in mga_video.c in the MGADMA function. just cd ./xc/programs/Xserver/hw/xfree86/drivers/mga and patch -p1 the attached patch. or if the list doesn't like attached patches i'll host it on a temp site. http://signal-lost.homeip.net:3001/mga_xvdma.patch.bz2 If nobody can help we still plan on continuing with the patch so anyone interested in the results of all this messing around need not give up. :) ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Weirdness in mga_video.c code
David Dawes wrote: [EMAIL PROTECTED] is probably a better place for this] On Thu, Dec 18, 2003 at 12:36:25AM -0500, Ed Sweetman wrote: I ran across a little oddity while working on the matrox driver. In MGAPutImage, the ScreenInfoPtr sent to it which is then converted to a MGAPtr does not have drmCtx set to a non-zero value even though dri is enabled and working at the time the function is called. I do not understand why this is and consider it to be a bug. Can anyone shed some light on this? This is of course working on the cvs pull of X. You'll have to be a little more specific/precise. I don't see any field called "drmCtx" in the current XFree86 CVS version of the mga driver, for example. David Well that would be because I added it. Getting my source trees mixed up. Ok. sorry about that. But i do have another question. The reason why I mixed that stuff up was because a friend and I have been working on giving mga DMA'd XV for kicks and giggles and that code was added in the very beginning. Now, we've borrowed a lot from the ati R128 driver in how it uses blits to do DMA. We felt this was viable because the MGA and R128 driver are very similar in how the code is structured and functions. However, this is the first time we've both worked on video cards at this level to this degree and we're having trouble getting the actual blit code to work correctly. I keep getting this error. [drm:mga_verify_blit] *ERROR* *** bad blit: src=0x1 dst=0x300 Obviously I have no idea how to create a blit or something. The mga driver's blit structure is drastically different from the R128's so i've used some inference to fill in the missing pieces and what not. Fallbacks work correctly, so does using the option method of turning it off and on. Once this little hurdle of code is done then we should see the same type of dma benefits (if any) as the R128 card gets. The YV12 code is not expected to work as is for dma due to all the nasty multiplexing and all but there is another patch out there we're going to try and get a hold of that may eliminate the need for all that multiplexing and give us a function like the YUY2 one. Anyway, if any developers wanna check out this blit code and tell me what i'm doing wrong with it... it's in mga_video.c in the MGADMA function. just cd ./xc/programs/Xserver/hw/xfree86/drivers/mga and patch -p1 the attached patch. or if the list doesn't like attached patches i'll host it on a temp site. http://signal-lost.homeip.net:3001/mga_xvdma.patch.bz2 If nobody can help we still plan on continuing with the patch so anyone interested in the results of all this messing around need not give up. :) mga_xvdma.patch.bz2 Description: BZip2 compressed data
[XFree86] xinit setting priority of X process
First of all i'd like to thank the guy who thought it would be really cool to make X set it's priority as a hardcoded value by default instead of having it be set from a config file. Line 624 of xinit.c has this. #ifdef PRIO_PROCESS setpriority( PRIO_PROCESS, serverpid, -1 ); #endif I've been compiling my own X for literally years and i dont remember seeing PRIO_PROCESS documented anywhere in xf86site.def as a configurable option nor any other documents on having in a config file somewhere to override it with another option name. Debian's X server uses something called Xwrapper.conf but that's a debian thing. So if this is indeed a configuration option i'm missing to override it then I'd be very happy if someone would show me where i could find that configuration option and where to have it. Otherwise I suggest this code be removed from X as it's completely annoying, useless, and obviously not very documented since my previous questions on how come my server is being niced to -1 all the time was met with no response whatsoever. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] altering mga to use less mem for texture with dri
Yes, most uses of DRI are 3d and all. But it has some 2D uses. You can achieve more 2d memory (the default mode i believe does not give adequeate memory to have multiple virtual desktops, multiple xvideo outputs and populate those desktops with a bunch of windows). In mga_storm.c line 866 or so, whatever line it is before this : pMGADRIServer->textureOffset = (pMga->FbMapSize - pMGADRIServer->textureSize + MGA_BUFFER_ALIGN) & ~MGA_BUFFER_ALIGN; All you need on the line before that is the following command with your memory size in bytes you wanna fork over. The remaining memory can then be used by xaa and the server to do all the stuff you normally do when dri is not loaded. pMGADRIServer->textureSize = SIZE_IN_BYTES; This could easily just be coded into a configuration file option for the mga driver to give you the ability to change this without recompiling. I set it to 512KB, and i dont play any video games. This is just a "just so ya know" post. I've been annoyed by the fact that using some drm/dri features meant i had to fight with 2d performance, some other people may too. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] xinit setting priority of X process
The fact that it has existed for a decade doesn't make it correct to use now. /usr/include/linux files are provided by debian for me, and whatever your distribution is. I dont know if your X server process is being niced to a value of -1 (or if you use the cvs and not some distro version) but either this is a debian problem or a X problem because having the server default to a niced value of -1 is not optimal or desired behavior anymore. I wonder if undefining it in host.cfg will cause any other adverse effects. Either way, if your distribution is defining PRIO_PROCESS (maybe even vanilla kernels do too) then the only reason why some people's X's aren't running -1 is because they renice it with some script. default nice level is something that should be handled by reading a value from .xinitrc not hardcoded. a decade ago this was fine because everyone used kernels with not so good schedulers. Mark Vojkovich wrote: That is in the sample implementation. That line exists in the XFree86 code base going back a decade. http://cvsweb.xfree86.org/cvsweb/xc/programs/xinit/xinit.c?rev=1.1&content-type=text/x-cvsweb-markup On my machine PRIO_PROCESS is defined in /usr/include/linux/resource.h Mark. On Fri, 19 Dec 2003, Ed Sweetman wrote: First of all i'd like to thank the guy who thought it would be really cool to make X set it's priority as a hardcoded value by default instead of having it be set from a config file. Line 624 of xinit.c has this. #ifdef PRIO_PROCESS setpriority( PRIO_PROCESS, serverpid, -1 ); #endif I've been compiling my own X for literally years and i dont remember seeing PRIO_PROCESS documented anywhere in xf86site.def as a configurable option nor any other documents on having in a config file somewhere to override it with another option name. Debian's X server uses something called Xwrapper.conf but that's a debian thing. So if this is indeed a configuration option i'm missing to override it then I'd be very happy if someone would show me where i could find that configuration option and where to have it. Otherwise I suggest this code be removed from X as it's completely annoying, useless, and obviously not very documented since my previous questions on how come my server is being niced to -1 all the time was met with no response whatsoever. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] glxgears and cpu utilization funny...
Rahul Sawarkar wrote: Hi I'm not clear. From: Ian Romanick When the card has to draw less pixels, a **larger** percentage of the time is spent sending commands from the CPU to the card. When the window is tiny, the card is drawing fewer pixels, but the CPU has to send the **same** number of commands per frame. So are you saying Same number of commnds per frame + More pixels gives <= cpu utilization, as compared to Same number of commands per frame + less pixels ? Here my cpu utilization is a dramatic 80% when glxgears is a 3x3 inch window and 4% when glx gears is maximized full-screen at 1280x1024 res. Also when I hide the 3x3" glxgears window behind say my browser window i.e bring another app window to front, and glxgears is no longer visible, cpu utilization remains at 80% or more. Could you please clarify ? I think you haven't explained everything thats on your mind or know. I think my graphics card GPU is kicking in when I maximize but inactive when minimized, something to do with the way X works. its a hunch ... Thanks for you effort. Please cc to: [EMAIL PROTECTED] as I'm not subscribed. Rgrds You'll also see this effect with video playback that uses xv for hardware bes. The codepath must be significantly longer for windows than for fullscreen, since it's easier to do less pixel pushing than more, the implimentation must be much simpler for fullscreen in both extensions. Hello I've got a intel440bx with a Radeon7500 rv200 chip , running x4.3, on kernel 2.6. System is built from source entirely. One strange thing I noticed is that when I run glxgears in a small window say 2x2 inch, cpu utilization jumps above 70%. But when I maximise the window, cpu utilization drops to 1-2%. I can see this clearly in gkrellm. I thought it should be the reverse. what gives?? I'm running the Radeon in agp2x mode. Rgrds ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
