Re: updated i830 texture compression patch
Am Samstag, 12. Juni 2004 23:23 schrieb Roland Scheidegger: Dieter Nützel wrote: Am Donnerstag, 10. Juni 2004 11:59 schrieb Dieter Nützel: Am Dienstag, 8. Juni 2004 00:14 schrieb Roland Scheidegger: Dave Airlie wrote: I've fixed the FXT support but DXT1 RGB is still knackered and probably won't be fixed... http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff Roland can you update your patch with this verson? Done (I've changed it slightly though since you can use fxt without the dxt library). New version: http://homepage.hispeed.ch/rscheidegger/dri_experimental/mesa_r200_rade on _i 830_txc_cvs040607.diff.gz Library still the same: http://homepage.hispeed.ch/rscheidegger/dri_experimental/libtxc_dxtn040 52 4. tar.gz Do not apply after latest Mesa CVS update. I've removed the i830 stuff from your latest patch (applies with only one off) but get this: quake3 * after the splash screen finished there is a white background behind the menu. * 'console' is empty (white), too * icons are wrong * all textures are missing in game seta r_ext_compressed_textures 0 cure it Hmm. Forgot to update the patch, will do it next week. Not sure why it wouldn't work though currently (with the i830 stuff removed). Here are the (relevant) changed files from 10.06.2004 (22:00:00) to 12.06.2004. (backwards) P src/mesa/main/buffers.c P src/mesa/main/context.c P src/mesa/main/image.c RCS file: /cvs/mesa/Mesa/src/mesa/main/mtypes.h,v retrieving revision 1.178 retrieving revision 1.177 Merging differences between 1.178 and 1.177 into mtypes.h P src/mesa/main/teximage.c P src/mesa/main/texstate.c P src/mesa/swrast/s_auxbuffer.c P src/mesa/swrast/s_texture.c Appart from S3TC I get this with Celestia: * fonts are off by (one?) * textures are wrong for distance That looks to be the same problem as the one reported with Freespace? (see thread Mesa bug in new teximage code) It stays for very long on r200. -Dieter --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFT] texcyl - 'Reflect' do not work
Am Sonntag, 13. Juni 2004 09:01 schrieb Dieter Nützel: Empty black window. With 'Point' and 'Linear' Filtered. Mesa (LIBGL_ALWAYS_INDIRECT) works. Argh, I've forgotten to mention the hardware... r200 -Dieter --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 733] kernel total freeze switching X-fb (matrox)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://freedesktop.org/bugzilla/show_bug.cgi?id=733 --- Additional Comments From [EMAIL PROTECTED] 2004-06-13 07:00 --- (In reply to comment #3) no preemption now: seems stable. freezed again (without preemption) after 1 week of stability.. i have noted that i was using some turbo settings for RAM timing.. i'll try with more stable settings. -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Martijn Sipkema [EMAIL PROTECTED] wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? Where can I find more information about mesa-solo? Is this the same as miniglx? Same thing. http://mesa3d.sourceforge.net/fbdev-dri.html Keithp is hard at work converting xserver to run on OpenGL. We already have the render engine on top of of OpenGL finished in the glitz project. All we are missing is pbuffer support in the mesa hw drivers and some support for multi-head mode setting. In the xserver on OpenGL model XAA disappears. Does mesa-solo handle multiple rendering surfaces or just a single redering surface that is the whole framebuffer? Are multiple visuals supported? This is a work in progress. mesa-solo is the same code as DRI. Any DRI features should work in mesa-solo provided the needed code has been made to work in the solo environment. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 03:07, Jon Smirl wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? For one, in the two years that is going to take to bear fruit, we need a working X server. Two because mesa-solo isnt supported on most of the Xorg platforms. The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't get to work on a response. Getting mesa-solo running everywhere wouldn't take two years if more people would pitch in and quit arguing. Right now we should have a working xserver/mesa-solo this summer, even sooner if there was more help. I'm not sure if you mean platforms as in OS or platform as in cards, but mesa-solo runs on the fbdev driver using software mesa. Between fbdev and the accelerated drivers that covers all of the more common hardware. All of the pieces needed to get xserver running on mesa already exist; all we need to do is pull everything together. xserver on GL is an architecture that will be good for at least another ten years while the current XAA architecture is close to the end of it's life. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sun, Jun 13, 2004 at 08:34:46AM -0700, Jon Smirl wrote: --- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 03:07, Jon Smirl wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? For one, in the two years that is going to take to bear fruit, we need a working X server. Two because mesa-solo isnt supported on most of the Xorg platforms. The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't get to work on a response. Getting mesa-solo running everywhere wouldn't take two years if more people would pitch in and quit arguing. Right now we should have a working xserver/mesa-solo this summer, even sooner if there was more help. Forgive me if I am going to say something stupid here, as I am mostly watching from the side lines, but maybe someone will be nice enough to put me in place ;-) First of all it looks like linux is suffering from a bunch of different attempts at solving/implementing the desktop issue. The name I am aware of: Xfree vs. Xorg, the difference I know of is the licensing issue, don't know where else they differ. DirectFB and mesa-solo which it is not clear whether they are just similar, related, or neighbors. Then of course there is the frame buffer which seems to be the ideal base point since it allows all sorts of embedded devices to produce some graphics. Part of the problem seems to be that people are going all over the place, users don't really know what the options are and getting accelerated graphics seem to be more vodoo then science at the moment. The whole graphics thing need to be designed properly from the grounds up preferably using existing layers but defining the relationship properly and to somehow to get all the people from the different solutions working together and hopefully drastically reduce the bloatware that is currently known as X in the process. The problem is that it needs to support current programs with minimal changes on the one hand or people won't switch, and support high quality gui interfaces and 3D gaming which is what will pull people and as a result companies and then people again to linux. I'm not sure if you mean platforms as in OS or platform as in cards, but mesa-solo runs on the fbdev driver using software mesa. Between fbdev and the accelerated drivers that covers all of the more common hardware. All of the pieces needed to get xserver running on mesa already exist; all we need to do is pull everything together. xserver on GL is an architecture that will be good for at least another ten years while the current XAA architecture is close to the end of it's life. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: You have no solution to non 3D heavy cards, you have no solution to non-Linux hardware platforms. Most of your linux ideas have been thrown out repeatedly as half-baked on multiple lists. mesa-solo is a *research* project. If it works out then in two years time its going to be rather cool. In the mean time trying to stop people doing important work to cripple what you perceive as a rival is just wrong. I don't know why I continue to waste my time on this project. The MS Longhorn UI is clearly a generation better than anything available on Linux. Right now Linux is starting to get a foothold on the desktop. All of the desktop effort will be wasted if Linux has an obviously inferior UI for several years and Linux's desktop acceptance backslides during that period. Of course things might easily go the other way if Linux beats or ties MS's GUI efforts. So if my ideas are so bad, why don't you propose your own solution to the Longhorn problem? I have no attachment to anything I've proposed, I'll work on any solution that solves the main problem. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Ely Levy [EMAIL PROTECTED] wrote: If it's like you say why not pick up the glove and create a tree for it? orginize a tree with a workplan I'm sure most people would be happy to contribute, I know I would. The work is already underway: mesa-solo is here: http://mesa3d.sourceforge.net/fbdev-dri.html xserver is here: http://www.freedesktop.org/Software/xserver glitx is here: http://www.freedesktop.org/Software/glitz mesa-solo - provides a standalone OpenGL environment without the need for X. mesa-solo has 3D hardware acceleration for the same cards as DRI. For non-3D cards it uses software mesa to write to the framebuffer. xserver - keithp's next generation X server. It know about things like alpha blending natively. glitz - an implementation of the Cairo API on OpenGL. Glitz has also implemented the X render engine in OpenGL. keithp is in the middle of adding the the OpenGL render engine to xserver. The basic idea is, you start with a standalone OpenGL stack. OpenGL is a high level API with lots of room for future hardware improvement. The OpenGL stack may either be the freedesktop one or one from Nvidia/ATI. On top of that runs xserver. xserver does all of it's drawing via OpenGL. This means everything will be accelerated. Remote X, xft, etc are still there - xserver is just a variation of XFree86 with XAA removed. xlib still works, xserver just uses OpenGL to do the drawing. Cario/Glitz is the next layer. xserver exposes the OpenGL layer in the same way DRI works. Glitz is written to use OpenGL in a fully accelerated, direct rendered environment. It will also work remotely. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Alan Coopersmith [EMAIL PROTECTED] wrote: But fbdev only covers one of the supported OS'es right? Xorg runs on the BSD's, Solaris, Windows/Cygwin, MacOS X, and many other platforms without fbdev, so it's very premature to say that work on anything else is wasted. The work that would be wasted is extending the XAA 2D drivers to use the 3D hardware to accelerate render. fbdev dependence is a very small part of mesa-solo that I would like to remove. fbdev is only used to set the video mode and control the cursor. Both of these of done in user space in the current XFree XAA drivers. There are three main solutions to mode/cursors problem that no one can agree on: 1) leave fbdev in charge of mode setting and cursor, port it around to other architectures. 2) copy of the user space code from XFree86 into a standalone library - now you have to be root to play with the chip. 3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the work as possible in user space and just pass final register values to the IOCTLs. I would like to see #3. I have implemented #3 locally for the radeon but there is no acceptance for adding it to main DRM drivers. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Alan Cox wrote: On Sul, 2004-06-13 at 16:34, Jon Smirl wrote: The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't get to work on a response. Getting mesa-solo running everywhere wouldn't take two years if more people would pitch in and quit arguing. Right now we should have a working xserver/mesa-solo this summer, even sooner if there was more help. This isn't relevant to the Xorg server. need to do is pull everything together. xserver on GL is an architecture that will be good for at least another ten years while the current XAA architecture is close to the end of it's life. You have no solution to non 3D heavy cards, you have no solution to non-Linux hardware platforms. Most of your linux ideas have been thrown out repeatedly as half-baked on multiple lists. At least he is trying. There's no need for bashing people who try to implement new ideas. -- -Torgeir --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
-Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED] Sent: 13 June 2004 20:04 To: [EMAIL PROTECTED] Cc: Jon Smirl; Eric Anholt; Alex Deucher; DRI Devel; [EMAIL PROTECTED] Subject: RE: [Xorg] DRI merging On Sul, 2004-06-13 at 20:47, Matt Sealey wrote: Linux basically falls behind on two simple fronts at the moment: it has no simple 2D or 3D framework capable of much more than I deal with embedded Linux people on a daily basis. I think they would disagree. For 2D it has several in heavy use - Keith's tiny X server work - Nanogui (2D down to about 50K RAM) - DirectFB (particularly strong at multimedia) For 3D you end up looking back at the mesa-solo work and it shares that same interest with the X over mesa people. Agreed, but DirectFB doesn't work with Qt, and the company I work for has a perfectly good OS for multimedia work (http://www.morphos.net :) We need a low-level kernel graphics API (much like Windows Unfortunately for a lot of hardware the entire design is different per card. You have to deal with an incredible range of hardware and its a tribute to the X DDX and XAA design how well it has coped with this. Fortunately we have APIs like OpenGL to relieve us of the front end API worries. What you do in back.. well that's up to the author and card vendor. As long as there is a simple API for it all (I could mention VESA as a good example of 2D acceleration that works and is still in good use and practice..) that does everything everyone could expect. 2D graphics have hit a peak now, I dare say it's not going to improve beyond the current acceleration features specified by modern APIs (of which GDI+ and the X Render extension are probably the most current bitblt and geometry APIs and still state of the art after how many years?) What remains is to build on top of an advancing 3D API - which offers silly but useful tricks as using the Z-buffer and/or stencils to order windows, thereby eliminating overdraw and layering in a single swoop. That alone raises the efficiency of windowing systems. We have currently got something which is halfway between what we had and what people want - 2D APIs based on framebuffers and DRI support for 3D layered on top - and they restrict everyone not using X to a full-screen 3D environment. What I am talking about is an environment where you can use 2D without having a 3D card (re low end like ATI IMAGEON..) but also implements 3D in a desktop way - like you can put Mesa output in a window under X, you should be able to portion your display and run multiple accelerated 3D applications in different sections. Borders on windows? Up to the OS and user! :) Secondly every line of code you put in the kernel has to be audited, analysed and can introduce security holes or crash the machine. Its harder to debug and its harder to write in the first place. There are very good reasons (see the original DRI paper) for putting as much as you can in user space. The Mesa X work also tries to keep as much as possible in user space - including designs for mode computation by kernel-user callback. Userspace would be just as good. I'm not sure how much it really matters these days in the world of 3.2GHz processors, 10 gigabyte per second data buses, and GPUs with more power than the CPU, but at one point userspace graphics was dog slow. I am from a world where we use stuff under a Gigahertz, low power, low cost, i.e. not a $3000 gaming box on every desktop. When someone comes along and says they want to make a cost-reduced console based on Linux, it should be possible, not laughable, for instance.. ;) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
I agree with both you guys :) Linux basically falls behind on two simple fronts at the moment: it has no simple 2D or 3D framework capable of much more than simple framebuffer support. So, unless you buy Qt, the deeply embedded market is out from an out of the box standpoint, where developers need to define new custom interfaces for specific graphics chips in order to succeed. I don't think Linux is going to survive much inbetween the desktop and router segments in that case. The other thing it is hampered by is X - not the XFree vs. X.org argument, not a licensing issue, just the X protocol, X libraries and everything else as a suite. Again, as an embedded product, X provides many features and functionalities that are well beyond the environment - networked GUI support via TCP/IP and UNIX sockets, client-server architecture, it really won't work on small devices (see Qtopia's dominance in the very very small Linux PDA market for an example of people needing alternatives..) Having a capable accelerated 2D and 3D architecture, something like DirectFB but at more of a core and commercial level would benefit everyone. Building a single DDX driver to interface with this would simplify support for X - no drivers in the X tree but one! Console Framebuffers could be built on top of the same low-level graphics API. In the end losing the 4-driver system for each card would both simplify and optimise the Linux graphics experience. We need a low-level kernel graphics API (much like Windows has, although Windows favours microkernels with high-level kernel functionality, rather than monolithic kernels with user-level functionality.. the two philosophies are at odds) which can perform and accelerate the expected functionality of everything from router to PDA, past desktop to display of remote-served apps. ATI and nVidia could release a single, binary driver, and have it support everything. Not just XFree86, not just a console driver, but everything that runs on this API. (oh, and of course restricting it to Linux would just be mean, FreeBSD, NetBSD et al. should be catered for, but with a more user-mode API as Linux philosophy currently dictates that should not be a problem). Okay, I'll stop rambling now :) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jon Smirl Sent: 13 June 2004 20:14 To: Alan Cox Cc: Eric Anholt; Alex Deucher; DRI Devel; [EMAIL PROTECTED] Subject: Re: [Xorg] DRI merging --- Alan Cox [EMAIL PROTECTED] wrote: You have no solution to non 3D heavy cards, you have no solution to non-Linux hardware platforms. Most of your linux ideas have been thrown out repeatedly as half-baked on multiple lists. mesa-solo is a *research* project. If it works out then in two years time its going to be rather cool. In the mean time trying to stop people doing important work to cripple what you perceive as a rival is just wrong. I don't know why I continue to waste my time on this project. The MS Longhorn UI is clearly a generation better than anything available on Linux. Right now Linux is starting to get a foothold on the desktop. All of the desktop effort will be wasted if Linux has an obviously inferior UI for several years and Linux's desktop acceptance backslides during that period. Of course things might easily go the other way if Linux beats or ties MS's GUI efforts. So if my ideas are so bad, why don't you propose your own solution to the Longhorn problem? I have no attachment to anything I've proposed, I'll work on any solution that solves the main problem. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Jon Smirl wrote: --- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 03:07, Jon Smirl wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? For one, in the two years that is going to take to bear fruit, we need a working X server. Two because mesa-solo isnt supported on most of the Xorg platforms. I'm not sure if you mean platforms as in OS or platform as in cards, but mesa-solo runs on the fbdev driver using software mesa. Between fbdev and the accelerated drivers that covers all of the more common hardware. But fbdev only covers one of the supported OS'es right? Xorg runs on the BSD's, Solaris, Windows/Cygwin, MacOS X, and many other platforms without fbdev, so it's very premature to say that work on anything else is wasted. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sun, 13 Jun 2004, Alan Cox wrote: On Sul, 2004-06-13 at 16:34, Jon Smirl wrote: The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't get to work on a response. Getting mesa-solo running everywhere wouldn't take two years if more people would pitch in and quit arguing. Right now we should have a working xserver/mesa-solo this summer, even sooner if there was more help. You have no solution to non 3D heavy cards, you have no solution to non-Linux hardware platforms. Most of your linux ideas have been thrown out repeatedly as half-baked on multiple lists. Xorg already work better on linux Nvidia's drivers are for fbsd and linux from ATI I saw only linux binary drivers and so on. I think making a common xserver and a high quality openGL based server might be a good idea, if we can keep most the code the same and compatible with each other both groups could enjoy. I know people would think it's a waste of resources but maybe that would be appropiate job for the stable branch of kdrive. Ely --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Alan Coopersmith wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? For one, in the two years that is going to take to bear fruit, we need a working X server. Two because mesa-solo isnt supported on most of the Xorg platforms. I'm not sure if you mean platforms as in OS or platform as in cards, but mesa-solo runs on the fbdev driver using software mesa. Between fbdev and the accelerated drivers that covers all of the more common hardware. But fbdev only covers one of the supported OS'es right? Xorg runs on the BSD's, Solaris, Windows/Cygwin, MacOS X, ... HP-UX, IRIX, BeOS, AIX etc ... and many other platforms without fbdev, so it's very premature to say that work on anything else is wasted. I agree with Alan. Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
If it's like you say why not pick up the glove and create a tree for it? orginize a tree with a workplan I'm sure most people would be happy to contribute, I know I would. Ely Levy System group Hebrew University Jerusalem Israel On Sun, 13 Jun 2004, Jon Smirl wrote: --- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 03:07, Jon Smirl wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? For one, in the two years that is going to take to bear fruit, we need a working X server. Two because mesa-solo isnt supported on most of the Xorg platforms. The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't get to work on a response. Getting mesa-solo running everywhere wouldn't take two years if more people would pitch in and quit arguing. Right now we should have a working xserver/mesa-solo this summer, even sooner if there was more help. I'm not sure if you mean platforms as in OS or platform as in cards, but mesa-solo runs on the fbdev driver using software mesa. Between fbdev and the accelerated drivers that covers all of the more common hardware. All of the pieces needed to get xserver running on mesa already exist; all we need to do is pull everything together. xserver on GL is an architecture that will be good for at least another ten years while the current XAA architecture is close to the end of it's life. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ xorg mailing list [EMAIL PROTECTED] http://freedesktop.org/mailman/listinfo/xorg --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: Secondly every line of code you put in the kernel has to be audited, analysed and can introduce security holes or crash the machine. Its harder to debug and its harder to write in the first place. There are very good reasons (see the original DRI paper) for putting as much as you can in user space. The Mesa X work also tries to keep as much as possible in user space - including designs for mode computation by kernel-user callback. There is a fine line to walk with the user space versus kernel split. For example the X server should not be changing the PCI bus routing from user space like it currently does. It should also not be capable of moving things like the framebuffer address around in PCI space. The kernel provides an API for doing those things and X should be using it. You just can't move hardware around without telling the kernel and then expect hotplug to work. If things aren't where the kernel expects them to be the kernel may assign the hotplug device addresses on top of them. On the other hand you shouldn't put too much into the kernel. Mode setting is an example of this. It takes a lot of code to read a monitor's DDC and then compute the mode. This code can easily run in user space and then use an IOCTL to set the final result into the hardware. fbdev is trying to do all of this in kernel space. Finally there is the issue of needing root priv. With a properly designed kernel driver the X server does not need to map the hardware into user space and run as root. DRM + mode + cursor equals a driver capable of support a non-root X server. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 20:20, Torgeir Veimo wrote: At least he is trying. There's no need for bashing people who try to implement new ideas. I'm not. I'd rather he listened to new ideas and took feedback but that is his business and the community has ways of dealing with that problem that work (see GGI, or Eric Raymonds new kernel config tool) I'm listening. What is your proposal for getting Linux into a position where it can fully utilize 3D hardware acceleration engines? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
--- Matt Sealey [EMAIL PROTECTED] wrote: We need a low-level kernel graphics API (much like Windows has, although Windows favours microkernels with high-level kernel functionality, rather than monolithic kernels with user-level functionality.. the two philosophies are at odds) which can perform and accelerate the expected functionality of everything from router to PDA, past desktop to display of remote-served apps. I'm not proposing a new kernel graphics API. Instead I am proposing that the primary user space graphics API be OpenGL. This make no comment on what the kernel API would look like. In fact I would expect that there will be many variations on the kernel API. The proposal is simply that the OpenGL API becomes the primary user space API for programming the graphics hardware. This does not mean that X is dead. xserver is in the middle of implementing xlib and render on top of the OpenGL drawing API. OpenGL would be used to replace XAA in the current XFree system. All existing X apps won't notice the change except that drawing gets faster. Some points in favor of OpenGL as the primary user-space graphics API 1) accelerated graphics hardware is designed to accelerate OpenGL 2) it is standardized and controlled by the ARB, OpenGL is well designed. 3) free implementations exist 4) it is taught in schools 5) books on it are widely available 6) It is higher level than XAA. This provides more room for hardware integration over time. For example filters. 7) It can run on 2D hardware - software mesa 8) It can be made tiny - OpenGL-ES is 100K and it is shipping in cell phones 9) Key vendors - ATI/Nvidia already own OpenGL drivers Try making a list like this for other solutions like directfb or kgi and see how they compare. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
--- John Dennis [EMAIL PROTECTED] wrote: With a properly designed kernel driver the X server does not need to map the hardware into user space and run as root. How do you efficiently control the hardware then without incuring the overhead of user/system transition on ioctl's? How many iotcl's and at what granularity are you suggesting? Are you assuming a device which can read and execute register settings from a memory buffer, e.g. the dma ring buffer style devices? Of course the dma ring buffer devices are the best and decent, modern cards implement it that way. On modern processors the user/system transition is minor compared to the time needed for a bitblt over the PCI bus. Doing everthing in user space was important on a 286, but is it still a significant performance gain vs the security issues of running X as root? You can always batch the drawing operations to reduce the ring transition overhead. If performance is that critical spend $35 for a DMA based card. These arguments are different for an embedded device where everything runs as root. Go ahead and program everything from user space to get the performance gain. Worms and trojans aren't as big of problem for embedded devices. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Around 21 o'clock on Jun 13, Philipp Klaus Krause wrote: There would be no 2d drivers, only some basic mode switching and cursor support and OpenGL? For systems which would support OpenGL, this would be all that was required. However, we still need to deal with the unwashed masses yearning to run X who don't have OpenGL-enabled systems. For them, we're stuck with a 2D-only driver, perhaps with a bit of Render acceleration to make Composite tolerable on them. -keith pgpKTnURGSLOy.pgp Description: PGP signature
Re: [Xorg] DRI merging
Around 20 o'clock on Jun 13, Alan Cox wrote: Secondly every line of code you put in the kernel has to be audited, analysed and can introduce security holes or crash the machine. The same is (alas) all too true for code within the X server as well. An ideal situation would have the X server running unprivledged on top of a kernel driver that validated commands to the graphics card. That's one of the motivations to moving to a DRI-like environment for the X server. Using the OpenGL API provides that in a more vendor neutral way than going directly to DRI. However, even for plain 2D only X servers, I would advocate a similar driver architecture, albiet with a significantly simpler kernel module. Do everything possible in user mode, but no more. -keith pgp1kg3pcf1C2.pgp Description: PGP signature
Re: [Xorg] DRI merging
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 13 June 2004 20:22, Keith Packard wrote:
Around 10 o'clock on Jun 12, Eric Anholt wrote:
I am definitely in favor of the DRI X tree stuff being a branch on the
X.Org tree.
me too.
A question is how the future modularization of the system would impact this
process. I'm hoping the answers will be mostly positive, but discussion
is welcome.
-keith
Daniel Stone and I have been working on modularising the Xorg server in the
nascent 'debrix' project. Some cleanup to the lib{dri,drm,glx,GLcore} set
will assuredly be necessary - if for no other reason than to make it work
with the libdl-based module loader (bugs 377, 400, and 600 are relevant, in
case anyone wants the details). Since I'll be doing that anyway, I can push
those changes to the DRI xc module until such time as we move to a branch off
Xorg.
Note to DRI people: this _will_ break some ABIs, so some version adjustment
will be necessary. I don't think anyone's doing anything exciting on the
server side, so that's not a huge deal, but it's an issue and I'd rather not
see the same version number used to mean two different things. Probably I'd
branch off our tree and push debrix changes to that, merging once we're
stable, and then anyone using the branch in the meantime would be doing so on
the understanding that they'll lose any versioning fights.
Fixing up the server-side to load the *_dri.so modules instead of GLcore (and
subsequently removing the GLcore module entirely) is also on my list. Even
with X as a GL app we'll still need a server-side component to handle the
indirect rendering case, and I still want to see accelerated indirect
rendering. That will probably come later though.
Does this sound like a reasonable plan?
- - ajax
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAzQdwW4otUKDs0NMRAhj8AJ41ss8J7mPK5CnHOxDeluTBjX+xRACgoVsa
D4/rtH/raGnDasmsK+vDXuw=
=8LQw
-END PGP SIGNATURE-
---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sun, Jun 13, 2004 at 08:47:37PM +0100, Matt Sealey wrote: Having a capable accelerated 2D and 3D architecture, something like DirectFB but at more of a core and commercial level would benefit everyone. Building a single DDX driver to interface with this would simplify support for X - no drivers in the X tree but one! Console Framebuffers could be built on top of the same low-level graphics API. In the end losing the 4-driver system for each card would both simplify and optimise the Linux graphics experience. [..] We need a low-level kernel graphics API (much like Windows has, although Windows favours microkernels with high-level kernel functionality, rather than monolithic kernels with user-level functionality.. the two philosophies are at odds) which can perform and accelerate the expected functionality of everything from router to PDA, past desktop to display of remote-served apps. Careful. I think it is wise to consider the difference between what needs to be in the kernel, versus what is convenient to have an API for. For instance, it is possible to have a mode setting API without it being in the kernel -- just have a library that talks to a trusted userspace arbiter. Same for a 3D locking and command serialization. The only real difference between implementing such an API over a trusted userspace process or over kernel ioctls is that the userspace process might crash (and leave the system running, unlike a kernel crash) or be killed by the kernel; so you would need to plan for such a scenario and be able to recover from it. I don't particularly like the 1 driver to rule them all approach, especially if it's going in the kernel. I like the idea of nailing down exactly what resources the multiple drivers would be in competition for, and providing methods for permitted entities to cooperatively share those resources and to recover from failure. Putting everything in the kernel would enforce a lot of policy and doesn't guarantee it will all work right anyway. otoh, doing everything by disparate userland processes which each assume the hardware is their own doesn't work too well either, because graphics hardware has too much state. It seems like the sanest thing to do is to provide a userland server which maps the hardware and which graphical programs can talk to via a socket or library to get things done. That way all the policy ends up in userland, and all the server does regarding the kernel is to lock the hardware so i.e. two servers can't accidentally run at the same time. The problem with this approach is not only that the process could be killed, but what about scheduling? If I dispatch a command to it, what guarantees me that it gets done reasonably soon? Because of that it would probably have to run at realtime priority like jack does for audio processes. This still doesn't save you the overhead of a context switch compared to a uniform userspace driver, unfortunately. But you can use shared memory to e.g. dispatch big DMA lists or maintain a ring buffer. Like I said, this is also a cooperative approach. This has its advantages but its drawbacks as well. For instance, I ask the arbiter what the physical address of the framebuffer for the primary display is and to lock other people out from it. Its policy is to only give me the address if nobody else has said they are going to map the framebuffer directly. If someone else has already and it returns false, there is nothing to stop me from just finding the fb address and mapping it myself, possibly scrambling someone else's display or locking up the hardware. So the users of this arbiter need to not be hostile, which means there needs to be a security policy. I think the current DRM idea of having a device node for security would suffice for that security policy. Open /dev/display/*, then talk to the arbiter. If it believes you should get the access you want, it tells that to the kernel (via its own interface), then when you ioctl(.. MMAP_FB) the kernel can just look up whether or not the arbiter has granted your process access for that or not, and if so, mmap the framebuffer (or MMIO registers, or BIOS, or whatever) and give you a pointer. This way, direct hardware access need not be done as root (meaning less opportunity to abuse the system), but the user of the kernel API only gets access depending on the arbiter's policy, not policy embedded in the kernel. The great thing is that the arbiter's policy can be based on intimate knowledge of the hardware and arbitrarily complicated. For instance, it can know the state of the 3D engine while a game is running (via Mesa/DRI), and if another process (such as a XAA driver) requests an operation that is unsafe if the 3D engine is in a particular state, it can defer that until the time is right. Or maybe it knows that there must be a delay after a particular operation, so it defers any other accesses until then. This is stuff that is trivial to do in
Re: [Xorg] DRI merging
X on GL has no impact on remote X. Tests with glitz show a 100:1 speed improvement for local drawing. --- Daniel Stone [EMAIL PROTECTED] wrote: On Sun, Jun 13, 2004 at 12:13:43PM -0700, Jon Smirl wrote: So if my ideas are so bad, why don't you propose your own solution to the Longhorn problem? I have no attachment to anything I've proposed, I'll work on any solution that solves the main problem. Project Utopia, fixing window managers to do things like use XSync() whereever possible, migrate toolkits to use XCB and hand-optimise for common paths, et al. I think that's going to buy you a lot more than X on top of GL, for a lot less work. Because you know why? X on GL still requires not-insignificant work on the desktop to make it workable and coherent. More than what I've proposed, I dare say. -- Daniel Stone [EMAIL PROTECTED] freedesktop.org: powering your desktop http://www.freedesktop.org ATTACHMENT part 2 application/pgp-signature name=signature.asc = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
X on GL won't ship anywhere for at least a year. It will probably be two years before it is in wide spread use. You can get good 3D cards for $35 now, in two years due to Longhorn all systems will be shipping with them. I still own an 8086 based machine with no protected mode, does that mean that Linux should not support protect mode? You can;t look backwards at hardware support, if you do you will never add any new features. There are plans for supporting non-accelerated cards, but you can't expect them to perform like a decent 3D one. No amount of software is going to make my 8086 play a reasonable game of Quake. --- Daniel Stone [EMAIL PROTECTED] wrote: On Sun, Jun 13, 2004 at 10:07:59PM -0700, Jon Smirl wrote: X on GL has no impact on remote X. Tests with glitz show a 100:1 speed improvement for local drawing. ... on 3D-heavy cards, no? I wonder what those same tests would show for the S3 Trio64 my sister runs, or the ATI RageIIC my mother runs. I'm not disparaging your efforts, but: * A first-class windowing system is wasted if all the apps around are crap, or don't make use of it, or both. * Have you tested on lower-end cards, or only the new, insane, 3D-centric cards? A performance hit on already-slow graphics hardware would be bad. -- Daniel Stone [EMAIL PROTECTED] freedesktop.org: powering your desktop http://www.freedesktop.org ATTACHMENT part 2 application/pgp-signature name=signature.asc = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
