DRI without X
Can DRI run without X?
The first question you have to ask is whether you really should throw out X11. X11 does event handling, multiple windows, etc. It can also be made quite light weight -- it's running in 600k on an IPAQ.
If you decide you do need to throw out X, then you have to ask yourself if the DRI is the right solution for your problem. The DRI handles multiple 3D clients accessing hardware at the same time, sharing the same screen, in a robust and secure manner. If you don't need those properties then DRI isn't necessarily the right solution for you.
If you get to this point, then it would be theoretically possible to remove the DRI from X11 and have it run without X11. There's no code to support that at this point, so it would require some significant work to do that.
What would be the advantages of a non-X version of DRI?
| Pros | Cons |
| Eliminate any performance bottlenecks the X server may be causing. Since we are 3D only, any extraneous locking/unlocking, periodic refreshes of the (hidden) 2D portion of the display, etc., will cause unexpected slowdowns. | If the X server never does any drawing then the overhead is minimal. Locking is done around hardware operations. A lock check is a single CAS instruction. Assuming your 3D window covers the X root, then there are no 2D portions to redisplay. |
| Eliminate wasted system memory requirements. | Yes, there will be some resources from the X server, but I think not much. |
| Eliminate on-card font/pixmap/surface/etc caches that just waste memory. | If you don't use them they aren't taking any resources. Right now, there is a small pixmap cache that's statically added to 2D. Removing that is a trivial code change. Making it dynamic (3D steals it away from 2D) is not too tough and a better solution than any static allocation. |
| Eliminate the need for extra peripherals, such as mice. | Allowing operations without a mouse should be trivial if it isn't a configuration option already. |
| Reduction in the amount of software necessary to install/maintain on a customer's system. Certainly none of my customers would have been able to install XFree86 4.0 on their own. | XFree86 4.0 installs with appropriate packaging are trivial. What you're saying is that no one has done the packaging work for you, and that's correct. If you create your own stripped DRI version you'll be in for a lot more packaging work on your own. The impact of the X server is on the 3D graphics pipeline is very little. Essentially none in the 3D pipeline. Some resources, but I think not much. Realize the CAS is in the driver, so you're looking at creating a custom version of that as well. I think effort spent avoiding the CAS, creating your own window system binding for GL, and moving the DRI functionality out of the X server would be much better spent optimizing Mesa and the driver instead. You have to focus resources where they provide the biggest payoff. |
I would like to make a X11 free access to 3D...
See:
- MiniGLX
- DirectFB
- FBDRI Another option is to make the DRI work with TinyX. TinyX runs in 600k and gives you all of X. It should be a fairly straight forward project. As soon as you want more than one window, it makes a lot of sense to use the X framework that already exists.