As many of you know, I've been doing a lot of thinking lately about the GLX part of XFree86 & DRI. In that process I've come across a few stumbling blocks. A few things that make forward progress more difficult. To this point my efforts have been focused on the client-side of things. Some of the recent changes in the texmem-0-0-1 branch have brought some significant improvements to the level of GLX support in XFree86. However, improvements to GLX can only go so far without also looking at the server-side.
On the server-side there are two major ehancements to be made: adding support for GLX 1.3 (and a few other GLX extensions) and adding support for accelerated rendering. My initial consideration has been based on adding support primarilly for SGIX_fbconfig and SGIX_pbuffer. These, along with SGI_make_current_read, are the major stumbling blocks to GLX 1.3 support. Currently, server-side accelerated rendering is a secondary issue.
In the current GLX visual mechanism, the DDX driver exports an array of __GLXvisualConfigRec objects that is used by the GLX extension. This is done because the DDX driver is the only place in the server that knows what display modes the hardware can support. There are two significant problems with this, but only the first was initially apparent to me.
There is no easy way for the DDX driver to export the extended visual information needed for fbconfigs to the GLX layer. The primary issue is binary compatability. The size of the __GLXvisualConfigRec structure cannot be changed, and I have not been able to find a way to communicate version information between the GLX layer and the DDX driver.
The other problem is even more grave. Not only do the GLX layer and the DDX driver have to agree on interface-level support, the DDX driver and the DRI driver have to agree on hardware-level support. Here's an example. Assume that some way is found to export fbconfig data from the DDX driver to the GLX layer. The first version of this will likely only support fbconfigs that are the "same" as the currently supported set of GLX visuals. At some point we may wish to add support for floating point depth buffers to the Radeon driver. To support this, the fbconfig code in the DDX driver would need to be updated AND code in the DRI driver would need to be updated. Since the DRI driver is never loaded into the server, there is absolutely NO WAY for this information to be communicated.
Ah yes, good point. There's versioning from the 2d driver to the 3d driver, though it's little used, but there's nothing going the other way.
After the "lively" discussion with Philip Brown (aka bolthole) in yesterday's #dri-devel chat, I got to thinking. The current method is used because the DDX driver is currently the only thing on the server-side that has hardware-specific knowledge. Since the DRM module, the DDX driver, and the DRI driver need compatable information about the hardware, why not move the visual and fbconfig knowledge into the DRI driver and have the GLX layer load the DRI driver?
Sounds tasty.
I don't think that all of the DRI / 3D related knowledge in the DDX driver should be moved to the DRI driver, but I think that this piece should.
There are initialization tasks that have dependencies on the rest of the X server, and there are others that are pretty self contained. Some could be moved to the 3d driver.
This would also allow use to create and control our own method for communicating version information between the GLX layer and the DRI driver. It also eliminates a number of the potential binary compatability problems. Enacapsulating this information in the 3D driver should also be helpful to the embedded driver branch.
Yes. Another aspect of the embedded branch is that the drivers there do the whole initialization themselves - there is probably then an overlap between the inits that could be moved out of the 2d driver and those implemented by the embedded driver.
This could also pave the way for the X server to use the new memory manager that is being developed. We could make some sort of a conduit for the X server to call into the DRI driver to allocate graphics / AGP memory. There are other ways to achieve this, but this would be an easy way.
Yes, very nice.
Utah did have some stuff going for it. It was designed as a server-side-only accelerated indirect renderer. My "innovation" was to figure out that the client could pretty easily play a few linker tricks & load that server module with dlopen(), and then with minimal communication with the server, do 90% of the direct rendering tasks itself. (This was after my first encounter with PI, I think, until then I hadn't heard of direct rendering).
The nice thing about this was that the same binary was running the show on both the client and the server. That really was obvious in the communication between them -- all the protocol structs were private to one .c file.
If we could get something similar going, where the 3d driver binary got to do its own initialization, that could resolve some version skew issues.
The final point that I would like to make is that we're going to NEED to load the DRI driver on the server-side at some point in order to support accelerated server-side rendering. We could then implemented a server-side software-only "DRI" driver. This driver could then export a wide variety of fbconfigs (16-bit/32-bit/floating-point per channel color for pbuffers) that the underlying hardware doesn't support.
It really shouldn't be that hard. Against it are:
- XFree's dislike of native library functions, which the 3d driver uses with abandon.
- XFree's love of their loadable module format, which the 3d driver isn't...
In other words, because XFree modules are OS independent and can (allegedly) load and run on any system running XFree86, there might be some resistance to loading in this tainted, non-os-independent piece of code.
Keithh
------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
