Re: More details about a kernel module (by GPfault)
RJ Just add some IOCTL's for hardware acceleration). How much overhead does an ioctl involve ? (Rhethorical question.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: More details about a kernel module (by GPfault)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 14 Oct 2003 09:16 am, Raymond Jennings wrote: I hope you guys at XFree86 look into this. I haven't the foggiest idea how you would do it, as I'm a newbie. I do believe that a kernel modulized DDX layer would be of great benefit to X. Have you worked in the kernel before? I can't believe you have much kernel experience and are suggesting this as a realistic idea. It is a very bad idea. Brad - -- http://lca2004.linux.org.au - I'm registered. Are you? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/i+ZWGwwszQ/PZzgRApeAAKCb184hGVgfhEc2oBSG+dKEaej5hACfQhnX X+toevNZvCNnNnc/K0WOomE= =4Bid -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
Kernel modules are not inherently faster. the reason directx (and openGL) seem so fast on windows is because the manufacturers and MS tweak the drivers for every last bit of performance. Plus they are able to utilize interfaces that are not accessable in xfree86 due to IP concerns. Some xfree86 drivers actually are faster or support more features than their windows counterparts. Hi Alex, How can we prove this with real life data? I do realize XFree86 is VERY fast in some situations - for example I have seen Quake 3 running faster on GNU/Linux than on Windows - on the same hardware. I actually have made Windows Unreal Tournament run almost as fast on Linux as Windows. (I know UT 2003 comes with a Linux precompiled binary, I just wanted to test Wine+XFree86 efficiency in such a situation.) In both cases nVidia's non-free drivers were used. So at least I have an internal proof that X is not slow as people seem to think. I actually try to educate users here that X is good and networking is wonderful, and bottlenecks are elsewhere. Still - these are technical terms, and some people - not only gamers, are either unable or unwilling to grasp or listen to explanations. They need shiny things, FPS and white papers. What we did here a month ago during our OpenFest - festival for Free software, were some demonstrations. I was actually very amazed by XFree86 abilities. Here is a link to a shortish movie: http://ncbis.ue-varna.bg/vaso/of/mov/dscf1156.avi - 3,5?? It is my machine - AMD Athlon 1700+, 256 DDR SDRAM, nVidia GeForce 3 200, VIA KT266+ based motherboard with RedHat 9.0 demonstrating Gnome 2.4 What is seen is: 1. Top right - TOTEM playing Matrix 3 trailer (MPEG4 coded), local 2. Bottom right - GNOMEMEETING with a USB web cam showing some of the demonstrators as they try to demonstrate ;-), local (the bluish oval thing that rushes in is actually me ;-) 3. Bottom left - MPLAYER showing a DVD film, local 4. Top left - BB - a demonstration of aalib - rasterization using ASCII text. remote - this is run on another computer and just visualized via X networking abilities. 5. Middle - Windows Half-Life, run remotely under wine, using its OpenGL rasterizer, visualized via X networking abilities and running with hardware acceleration. None of the visitors believed me when I told them the hardware specs. They looked inside my box to check that I was not lying. So - I am talking about similar things: 1. Tests 2. Demos, 4. Games, 5. 3d heavy applications etc, etc. What can we really do to prove to infidels that XFree86 works great? Logic most of the times fails, explanation like usage of IPC, latency tests etc. also fails, people just scream Kernel graphics gd, X bd and it is demos like this that help me shut them up. What can we do? al_shopov ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
On Tue, 14 Oct 2003, Alexander Shopov wrote: Kernel modules are not inherently faster. the reason directx (and openGL) seem so fast on windows is because the manufacturers and MS tweak the drivers for every last bit of performance. Plus they are able to utilize interfaces that are not accessable in xfree86 due to IP concerns. Some xfree86 drivers actually are faster or support more features than their windows counterparts. Hi Alex, How can we prove this with real life data? I do realize XFree86 is VERY fast in some situations - for example I have seen Quake 3 running faster on GNU/Linux than on Windows - on the same hardware. I'm not quite convinced that that is an objective comparison however. Was Quake 3 running in both operating systems with the exact same 3D settings? Windows drivers support the full hardware featureset, and games are more likely IMHO to use the full hardware set of features in Windows. The XFree86 open source drivers support only a limited set of the functionality available in Windows. If you disable all hardware features in Windows which are not available under Linux, and configure everything else to be as close as possible for an accurate apples to apples comparison does Linux perform better? My experience is that while Linux DRI support is decent for most users, it doesn't outperform Windows. One needs to also make sure the same AGP mode is being used, etc. and that MTRR is functional... Of course I'm not discounting your claims, just a bit skeptical as to how the exact tests were ran, and how it was instrumented, or if it was just a placebo'ish it seems faster type of thing, etc... What can we really do to prove to infidels that XFree86 works great? Logic most of the times fails, explanation like usage of IPC, latency tests etc. also fails, people just scream Kernel graphics gd, X bd and it is demos like this that help me shut them up. What can we do? Quite frankly... random uninformed people making claims that X is slow, without any shred of a clue or properly deduced scientifically measured and reproduceable instrumented data, will always be out there. We can't stop people from spreading unfounded rumours nor from making random guesses as to why they or someone they know may be experiencing slowdowns in some application or another. X itself isn't slow by any stretch of the imagination, and there have been studies done that show this precicely. I don't think trying to prove anything to people who will believe whatever they want to believe helps us any at all personally... The best thing any of us can do, is continue to properly and scientifically analyze the X server, it's video drivers, and other related technologies, profile them, optimize them, etc. Right now, the biggest hit on the desktop is probably unaccelerated RENDER operations. That's what most users likely see as desktop slowdowns currently. Over time, those things will improve as people write support. The most important thing, when comparing Linux/X/XFree86 to Windows performancewise however, is that apples to apples comparisons are being made, and to understand exactly what component and/or level of the puzzle any problems that are found reside in. In the case of RENDER for example, that isn't an X11 performance problem, it is an XFree86 video driver limitation currently. Nothing that can't be overcome in the future. For video games and 3D however (to get back on specific topic), proprietary drivers that implement all of the hardware's special do-dads are very likely to always outperform the OSS drivers, simply because more resources are spent on the proprietary drivers, and more engineers with more deeper knowledge of the hardware are working on them. Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
Måns Rullgård wrote: Mike A. Harris [EMAIL PROTECTED] writes: Right now, the biggest hit on the desktop is probably unaccelerated RENDER operations. That's what most users likely see as desktop slowdowns currently. Over time, those things will improve as people write support. I've been trying to find specs for implementing hardware RENDER support for my graphics card. I have the specs for the card. The problem is that nobody seems to know what the various RENDER functions in a driver are supposed to do, or what the structs represent. Without this information, there's not much I can do. For a start, look at the mga or the sis driver. Both accelerate aa texture blitting for aa text with quite remarkable speed improvements. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
i82852/855GM 1040x1050
Hi; Some weeks back there was a discussion about a problem with some laptops (acer 661LCi, dell 500m,..) were the Vid-BIOS does not return the panel size and XFree can't use the the panel resolution of 1400x1050.Any idea if this problem gets resolved before or with the next XFree86 release ? PS the xig summit laptop drivers (commercial X) ignore the BIOS and amange to set the 1400x1050x16M panel res. hb ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i82852/855GM 1040x1050
I doubt it unless intel releases the necessary programming information. Alex --- hb [EMAIL PROTECTED] wrote: Hi; Some weeks back there was a discussion about a problem with some laptops (acer 661LCi, dell 500m,..) were the Vid-BIOS does not return the panel size and XFree can't use the the panel resolution of 1400x1050.Any idea if this problem gets resolved before or with the next XFree86 release ? PS the xig summit laptop drivers (commercial X) ignore the BIOS and amange to set the 1400x1050x16M panel res. hb ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
François Puitg wrote: The symptoms are : after X has been started and window manager is up (it's the same with KDE, GNOME and twm), sometimes after 1 hour, but most of the time immediately, the keyboard freezes and the mouse becomes erratic, even when doing nothing, just standing there staring at the screen. Then, the machine doesn't respond anymore, neither to VT switching (obvious since the keyboard is dead), nor to ping. If you are really patient (the mouse is very slow), it's possible to exit the window manager : you have to move the mouse towards the exit button, wait to see it moving on thescreen, then click and the console is there. But now, the only solution is to reboot (with the reset switch). I don't mean to sound flip, but have you checked the fans lately? I've seen similar failures when the video card fan failed, and on another when the chipset fan failed. In both cases, the cooked chips were flaky and never fully functional again :( -- Andrew E. Mileski Ottawa, Canada http://isoar.ca/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
Måns Rullgård wrote: Thomas Winischhofer [EMAIL PROTECTED] writes: I've been trying to find specs for implementing hardware RENDER support for my graphics card. I have the specs for the card. The problem is that nobody seems to know what the various RENDER functions in a driver are supposed to do, or what the structs represent. Without this information, there's not much I can do. For a start, look at the mga or the sis driver. Both accelerate aa texture blitting for aa text with quite remarkable speed improvements. I was hoping not to have to wade through hundreds of lines of chip specific code and try to guess what they tell the chip to do. If I only knew exactly what the functions are supposed to do, and what the supplied data is, it would be straight-forward to have my chip do the work. The parts that do RENDER accleration are by no means hundreds lines of code. It plain two accelerator functions. I myself had no clue either when I started, and implementing this took only one day. It's basically two blitting functions: one for pure alpha map (one bitplane, only alpha values; this one is used for aa text), one for 32 bit ARGB bitmaps. If you know how to implement this on your hardware, it's really easy. You can take over most of the surrounding code from either the mga or the sis driver, and just replace the machine specific stuff. The mga driver uses the 3D engine for this (AFAIK), the sis driver the 2D engine and a small hack (for aa text, since the engine lacks support for doing source and destination alpha at the same time). If you look at the sis driver, look in sis310_accel.c for everything inside #ifdef INCL_RENDER. I am afraid that is all the help I can give you. I haven't found any documentation on this either. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
I'm not quite convinced that that is an objective comparison however. Was Quake 3 running in both operating systems with the exact same 3D settings? Of course not! ;-) I am as skeptical as you are regarding similar tests. However - a demonstration like this helps me when proving that X is not slow. Furthermore - I can now challenge anyone to run Half Life accelerated remotely on Windows, when the same thing is easy to do with GNU/Linux. ;-) Still - what you get from current popular IT literature are very easily refutable tests that the public none the less believes in. Now - there are two things I can do - point that the test is unscientific, something that no one is interested in publishing as a proof is very boring (and people just love simple numbers pointing to the undisputable winner). The other thing is to actually make a simple demo and demonstrate in a flashy manner (everyone loves demos) that the test is obviously flawed. Scientific tests are a very important thing, I just want to make sure that unscientific ones are not used anti-XFree86-wise ;-) Quite frankly... random uninformed people making claims that X is slow, without any shred of a clue or properly deduced scientifically measured and reproduceable instrumented data, will always be out there. We can't stop people from spreading unfounded rumours nor from making random guesses as to why they or someone they know may be experiencing slowdowns in some application or another. Actually we can. Make a good demonstration, so that people see that the sentence X is slow is obviously and without any doubt flawed. I don't think trying to prove anything to people who will believe whatever they want to believe helps us any at all personally... I think it helps us prevent the stupid rumor propagating. A vaccine will not heal people, but it will prevent a disease from spreading. The best thing any of us can do, is continue to properly and scientifically analyze the X server, it's video drivers, and other related technologies, profile them, optimize them, etc. From a development perspective - yes, you are right. Popularization needs a more pro-active approach. Right now, the biggest hit on the desktop is probably unaccelerated RENDER operations. That's what most users likely see as desktop slowdowns currently. Over time, those things will improve as people write support. I know that, and people on the list know that. However I find it difficult to explain it to people that do not know what RENDER is, people that do not want to know what RENDER is, and people that just trust the old saying: seeing is believing Best regards: al_shopov ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Export symbol lists on Linux (was Re: RFC Marking private symbols in XFree86 shared libraries as private)
I'd say it would be better to reuse *-def.cpp files (didn't know something like that existed). I've preprocessed all *-def.cpp files included in XFree86/xc/lib, gathered all symbols currently exported from XFree86 shared libraries, all undefined symbols in 5800 shared libraries and binaries I found on my box which are satisfied by one of XFree86 shared libraries and attached are results. The first is a MUST list, symbols which are exported from XFree86 shared libraries now when there is no anonymous version script, are not exported when an anonymous versions script created from stock *-def.cpp file is applied and are used by some binary or shared library (including other shared libraries in the XFree86 collection). There is IMHO no way other than adding these to *-def.cpp files (any issues with this)? For libGL.so, as anonymous version scripts accept wildcards, I think we should use gl* wildcard, as it is too error-prone to list all the gl* functions. For libGLU.so, I think we should export everything, no version script on Linux. Second is a MAY list. These are symbols ATM exported from the shared libraries, which would be hidden by linker script but which looked to me like they are in the standard namespace of the libraries and thus might be good candidates for exports. Can anyone please review these and tell me if there are some which definitely shouldn't be exported? I can supply a tarball with all the symbols ATM exported, exported via *-def.cpp, used etc. to interested parties if you want to do more investigations. I'll follow up with a patch which exports MUST + current *-def.cpp ones and will wait for responses about the MAY list (or candidates not even on MAY list). Jakub libGL.so XF86DRIAuthConnection XF86DRICloseConnection XF86DRICloseFullScreen XF86DRICreateContext XF86DRICreateDrawable XF86DRIDestroyContext XF86DRIDestroyDrawable XF86DRIGetClientDriverName XF86DRIGetDeviceInfo XF86DRIGetDrawableInfo XF86DRIOpenConnection XF86DRIOpenFullScreen XF86DRIQueryDirectRenderingCapable XF86DRIQueryVersion __glXFindDRIScreen __glXInitialize _gl_tls_Context _glapi_Context _glapi_add_entrypoint _glapi_check_multithread _glapi_get_context _glapi_get_dispatch_table_size _glapi_noop_enable_warnings _glapi_set_context _glapi_set_dispatch _glthread_GetID glColorSubTable glColorTable glColorTableEXT glConvolutionFilter1D glConvolutionFilter2D glFogCoorddvEXT glFogCoordfEXT glFogCoordfvEXT glMultiTexCoord1dvARB glMultiTexCoord1fARB glMultiTexCoord1fvARB glMultiTexCoord1ivARB glMultiTexCoord1svARB glMultiTexCoord2dvARB glMultiTexCoord2fARB glMultiTexCoord2fvARB glMultiTexCoord2ivARB glMultiTexCoord2svARB glMultiTexCoord3dvARB glMultiTexCoord3fARB glMultiTexCoord3fvARB glMultiTexCoord3ivARB glMultiTexCoord3svARB glMultiTexCoord4dvARB glMultiTexCoord4fARB glMultiTexCoord4fvARB glMultiTexCoord4ivARB glMultiTexCoord4svARB glSecondaryColor3bvEXT glSecondaryColor3dvEXT glSecondaryColor3fEXT glSecondaryColor3fvEXT glSecondaryColor3ivEXT glSecondaryColor3svEXT glSecondaryColor3ubEXT glSecondaryColor3ubvEXT glSecondaryColor3uivEXT glSecondaryColor3usvEXT libGLU.so export all? libICE.so _IceTransNoListen libXaw.so.7 _XawTextGetSTRING libXaw.so.6 _XawTextGetSTRING libXcursor.so XcursorImageHash libXext.so XShmAttach XShmCreateImage XShmCreatePixmap XShmDetach XShmGetEventBase XShmGetImage XShmPixmapFormat XShmPutImage XShmQueryExtension XShmQueryVersion libXrandr.so XRRConfigCurrentConfiguration XRRConfigCurrentRate XRRConfigRates XRRConfigRotations XRRConfigSizes XRRFreeScreenConfigInfo XRRRates XRRSelectInput XRRSetScreenConfigAndRate XRRUpdateConfiguration libXrender.so XRenderCreateAnimCursor libXt.so _XtCountVaList _XtDefaultWarningMsg _XtVaToArgList colorConvertArgs libGL.so DRI_glXUseXFont XF86DRIQueryExtension __glFreeAttributeState __glXClientInfo __glXCloseDisplay __glXDebug __glXExtensionInfo __glXFlushRenderBuffer __glXFreeContext __glXGetCurrentContext __glXInitVertexArrayState __glXNewIndirectAPI __glXRegisterExtensions __glXRegisterGLXExtensionString __glXRegisterGLXFunction __glXSendLargeCommand __glXSetCurrentContext
Re: You suggest an upgrade, eh?
On Wed, 15 Oct 2003 00:19:58 +0300, Alexander Shopov wrote: I'm not quite convinced that that is an objective comparison however. Was Quake 3 running in both operating systems with the exact same 3D settings? Of course not! ;-) I am as skeptical as you are regarding similar tests. However - a demonstration like this helps me when proving that X is not slow. It does no such thing. It demonstrates that OpenGL on Linux is not slow, but to run those applications you essentially shut down X. You've demonstrated nothing about X's performance. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
It does no such thing. It demonstrates that OpenGL on Linux is not slow, but to run those applications you essentially shut down X. You've demonstrated nothing about X's performance. I am not sure I understand what you are saying. To the best of my knowledge - I used the OpenGL drivers that nVidia provides. Thay use X infrastrucrure, they have two parts - one for XFree86, the other one - kernel module for direct low level access. They use X infrastructure, things like GLX, DRI etc. All of these are clearly within the boundaries of XFree86. Maybe my application did not use Xlib - so what. It is still an X app. The other example I gave - running Half Life remotely and still having it accelerated - this further shows that X is fast. In one case I am using direct rendering, in the other one - I go through the OpenGL protocol encoder. What is the difference? And in the Quake 3 case - I ran the application both full screen and in windowed mode. How and when did I shut the X server down? I do not get your point, please correct me if I am wrong. Best regards: al_shopov -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
