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.
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?
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.
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.
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.
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.
------------------------------------------------------- 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
