Bringing X.org's GLX Support Into the Modern Age

Transcription

1 Bringing X.org's GLX Support Into the Modern Age Ian D. Romanick Software Engineer, Linux Technology Center July 19, 2005

2 Why does GLX support need modernization? Hardware-accelerated indirect-rendering is not supported Indirect-rendering must use software Mesa IHVs must use the same path or supply own GLX infrastructure GLX 1.3 support is missing Most of the extensions in GLX 1.3 are supported, but GLX_SGIX_pbuffer is missing Additional GLX 1.3 entry-points are also missing GLX protocol code is difficult to maintain Lots of script-generated code, but no scripts!

3 GLX Protocol Code Is Difficult to Maintain Mesa contains script-generated code Python scripts and custom APIspec data file to generate dispatch code Adding fields to APIspec requires changes to unrelated code OpenGL Sample Implementation (SI) contains script-generated code Complex awk scripts generate GLX protocol code from.spec files.spec files missing data already in APIspec The.spec files are used by SGI to generate glext.h and glxext.h Without scripts, adding a single entry-point requires touching 6 files With scripts, typically only the description file must be modified by hand

4 GLX Protocol Code Is Difficult to Maintain (cont.) Replace data files! Replace.spec files and APIspec with unified XML description Use modern XML features (e.g., XInclude) to improve maintainability Replace all generator scripts! Replace Mesa's existing scripts with new scripts that use XML Write new scripts to generate client-side GLX protocol code 2,300 lines of Python generate 10,000 lines of C. Additional uses of XML description & generator scripts Generate test cases Generate display-list handing code Other uses?

5 Hardware accelerated indirect rendering is unsupported Want to load client-side DRI drivers in the server Interface between libglx and libglcore (in server) is very different from interface between libgl and DRI driver (in client) Labor not cleanly divided between libglx and libglcore Creation of GL visuals and driver's internal representation mixed together Reflects the pre-pbuffer nature of the code Entire process is very, very convoluted

6 Generate Server Side GLX Protocol Code Use the same XML to generate the server-side protocol code Many of the client-side scripts can be used as basis of server-side scripts Scripts can generate up to 26,000 of 30,000 lines of server-side protocol code Enables some server-side optimizations Some large tables used for protocol decode can be replaced Automatically enables additional functionality Some extensions aren't currently supported (e.g., ARB_vertex_program), but are supported by client-side generated code Several scripts are already written Code will be contributed after X.org 7.0 ships

7 Use Dispatch Table Use a dispatch table to call GL functions Just like the client-side! Eliminates all the static dispatch functions from libglcore Reduces size and load time of libglcore and libglx Eliminates conditional compilation in libglx Not all ports (e.g., Darwin) support all GL functions Bugzilla #2996 Some patches exist, but won't be committed until after 7.0 ships

8 Rearrange Visual Creation The current GL visual creation process is a mess. The process yo-yos in and out of the DDX, libglx, and libglcore It took me a week of continuous code spelunking to figure it out Re-model the process after the client-side DDX passes skeleton list of visuals to libglx libglx creates real GL visuals and initial fbconfigs from the skeleton list libglx passes initial fbconfigs to libglcore Just like on the client-side!

9 Adapt Client Side Interface to Server Side Few technical hurdles at this point Bring additional client-side interfaces (e.g., GLX extension mechanism) to server-side Add support for dynamically loading per-screen libglcore Rearrange the remaining interface to match client-side This will mostly be a slow process of code rearranging Anyone have a grad student they could loan out?

10 Impacted Server Side Code Non-Unix libglcore implementations Each change to interface will break non-unix libglcore implementations Both the Darwin and cygwin ports must use dispatch table Both also must use new client-side APIs DDX Parts of the old visual creation process were never used and should be gutted

11 IHV Support Get involved!!! IBM Linux Technology Center Participate in mailing lists Keep aware of future API changes Provide input on desired features Don't need to contribute code or risk IP Migrate to updated client-side interface All known closed-source drivers use old, deprecated libgl interfaces The interfaces will be removed in X.org 7.0 Moving to new interfaces on client-side is first step to being loaded on server-side

12 Questions? IBM Linux Technology Center

13 Legal Statement This work represents the views of the author and does not necessarily reflect the views of IBM Corporation. The following terms are trademarks or registered trademarks of International Business Machines Corporation in the United States and/or other countries: IBM (logo). A full list of U.S. trademarks owned by IBM may be found at OpenGL is a registered trademark of Silicon Graphics, Inc.