XDevConf, February 8, 2006. Using The Existing Driver Framework To Achieve a Composited X Desktop. Andy Ritger, NVIDIA Corporation. Introduction. Make the case for using the existing XFree86/X.Org DDX loadable driver framework to achieve a production-quality composited X desktop
Andy Ritger, NVIDIA Corporation
Make the case for using the existing XFree86/X.Org DDX loadable driver framework to achieve a production-quality composited X desktop
To frame discussion, present goals for the X Windows System
Compare and contrast the X-on-OpenGL driver model with the existing loadable driver model
Address arguments and misconceptions surrounding X-on-OpenGL
Present a roadmap for how to get from today to a production-quality composited X desktop
High level, flexible interface between DDX and loadable hardware-specific drivers
Imposes minimal restrictions on how a driver performs its rendering and modesetting
With this flexible infrastructure, vendors have provided many features, including:
Direct-rendering hardware-accelerated OpenGL
Motivated partly by lack of hardware-acceleration of the Render extension
A successful implementation of X-on-OpenGL, Xgl, is in progress
Replace XFree86/X.Org DDX with DDX that renders using OpenGL
No hardware-specific X driver
Instead use hardware-specific OpenGL driver
Traditional X driver tasks (rendering, modesetting) handled by X-on-OpenGL DDX
X-on-OpenGL DDX calls stand-alone OpenGL driver to perform low-level rendering and modesetting
For purposes of discussion, we identify several goals for the X window system
The nine goals in the following slides are based upon:
Keith Packard's paper, "Getting X Off The Hardware", OLS 2004
The interests of IHVs such as NVIDIA
General trends in the X windows community
1) Bring a compelling composited X window system to the UNIX desktop
2) Give window manager and composite manager authors the power and flexibility to explore new realms of user interfaces
3) Maintain application backward compatibility
4) Improve interaction between X and UNIX kernels, particularly in the area of PCI device management
5) Make relevant X rendering perform optimally and make best possible use of the available graphics hardware
6) Continue to support existing advanced functionality, such as hardware-accelerated direct-rendering OpenGL
7) Grant vendors the flexibility to expose vendor-specific features such as TwinView/MergedFB, Quad-Buffered Stereo, SLI, and FrameLock
8) Give users the flexibility to chose for themselves when they want a composited desktop and when they want full performance OpenGL or features like Workstation Overlays that may not be compatible with Composite
9) Bring the functionality of Damage and Composite to production quality in the near future, so that it can be shipped and enabled by default by operating system vendors
Goals 1, 2, and 3 are implicitly accomplished with either driver model, due to the design of the Damage and Composite extensions:
We have the tools to create a composited X desktop (Goal 1)
Composite managers have control over compositing policy (Goal 2)
Damage/Composite are transparent to current X applications, achieving backwards compatibility (Goal 3)
Both driver models equally satisfy these three goals
Goal 4: Improve PCI configuration interaction between between the X server and the UNIX kernels
Independent of either driver model
Work is already in progress in this area
This work will support Goal 4 equally for both driver models
Goal 5: optimal performance, and best possible use of available GPU power
Both X driver and OpenGL have access to the same hardware capabilities
Additionally, X driver has more context, and should be able to make better tradeoffs
Current mediocre Render performance:
Caused by lack of attention
Caused by out-dated XAA
Not caused by driver framework
Render performance improving with loadable driver framework:
Render getting more attention from NVIDIA:
Many improvements and stability fixes made
“RenderAccel” enabled by default in nvr85 release
Much more tuning possible and will be phased in
Current driver model atleast as capable as X-on-OpenGL to make optimal use of GPU
Goals 6 and 7 considered together; both focus on giving vendors the flexibility to support features like direct-rendered OpenGL, TwinView, Stereo, Overlays, and SLI
Existing driver model allows these features
X-on-OpenGL model poses problems for supporting these advanced features
Direct-rendering OpenGL needs a server-side component to:
Propogate drawable data from X server to client
Manage Synchronization between client and server such that client's rendering arrives in the right place at the right time
In X-on-OpenGL model, there is no vendor-provided server component
Who handles direct-rendering data propogation and synchronization in X-on-OpenGL?
Using same OpenGL library for X-on-OpenGL X server and direct-rendering client would require special communication between X server and OpenGL:
OpenGL library needs to know if it is in client or server
OpenGL library in server must manage data propogation and synchronization
Xgl supports indirect rendering only
Features such as:
depend on coordination between vendor's X driver and OpenGL client library
Implementing these in the X-on-OpenGL model would require complex back doors
The X-on-OpenGL model does not give vendors the flexibility to adequately support these features
Goal 8: give users flexibility to choose when they want a composited desktop and when they want features that may not be compatible with a composited desktop
Contingent on the ability to have those features at all
X-on-OpenGL not conducive to vendor-provided advanced features
This goal not achievable with X-on-OpenGL
With current driver framework, users can disable Composite and have full performance and functionality
Goal 9: bring composited X desktop technology to market soon
To achieve feature parity with the current available drivers (or as close as possible), the X-on-OpenGL model would require a huge investment of time and engineering resources
The existing loadable driver framework requires only minor incremental work to achieve our goals
Roadmap will be presented in a few slides
Existing driver framework can do everything that X-on-OpenGL can do
Existing driver framework requires only incremental enhancements to achieve our goals
Existing driver framework is flexible enough to support advanced features important to many UNIX users
In the following section, we review a collection of arguments and misconceptions surrounding X-on-OpenGL; each is followed by a rebuttal.
Argument: "Using accelerated OpenGL drivers will provide dramatic performance improvements for important operations now ill-supported in existing X drivers."- Keith Packard, 'Getting X Off The Hardware'
Response: An X driver within the existing loadable driver framework has access to the same hardware capabilities as an OpenGL driver. An X driver should perform at least as well as X-on-OpenGL on the same hardware.
Argument: OpenGL applications cannot work with Composite unless the X server is also using OpenGL for its rendering.
Response: The OpenGL driver must coordinate with the X server to render to the redirected window and to propogate Damage notification. The coordination is important, but how the X server performs its rendering is not relevant.
How direct-rendering OpenGL accomplishes its rendering is not dependent on how X implements its rendering.
Argument: Using OpenGL for compositing the X desktop requires that the X server use OpenGL for its rendering.
Response: The composite manager can composite however it likes (Render, OpenGL, core X primitives). A composite manager can use OpenGL by retrieving redirected windows' pixmap data, and using that data as an OpenGL texture.
In the future, GLX_EXT_texture_from_pixmap could be used for this.
How the composite manager accomplishes its rendering is not dependent on how X implements its rendering.
Argument: "...3D [hardware] is simply faster than 2D [hardware]."- Jon Smirl, 'The State of Linux Graphics'
Response: Not always true. It depends on the operation. The implementer of an X driver will assess how best to use the available hardware to accomplish the requested rendering.
Argument: "At some future point the graphics chip vendors are going to remove that dot labeled 2D and only leave us only with 3D hardware.”- Jon Smirl, 'The State of Linux Graphics'
Response: Graphics chip vendors build hardware that most effectively accomplishes the tasks at hand. One of those tasks is accelerating a modern X desktop. It is the role of the X driver implementer to assess how optimally to perform the necessary operations.
Argument: X-on-OpenGL will be easier for IHVs, because now an IHV will only need to provide a stand-alone OpenGL driver, rather than both an OpenGL driver and an X driver.
Response: If the goal were simply to accelerate X rendering, then this might be true. However, the X-on-OpenGL model makes it much more difficult for vendors to provide advanced features. From this perspective, X-on-OpenGL will not make things easier for IHVs.
Argument: X-on-OpenGL will be easier for the open source community because it lessens IHV dependence. The open source community can implement their own Render driver with X-on-OpenGL and only depend on IHVs for an OpenGL implementation.
Response: Implementing a full OpenGL driver is a huge task; implementing Render acceleration is a much smaller task.
An IHV commited enough to Linux to provide an OpenGL driver is going to be interested in having that OpenGL implementation exposed to direct-rendering OpenGL clients, and will likely be interested in also exposing vendor-specific features.
Argument: "...graphics vendors really only care about MS Windows so they do the minimum driver support they can get away with for Linux."- Jon Smirl, 'The State of Linux Graphics'
Response: That is certainly not true in the case of NVIDIA.
OpenGL-based composite managers
Need to resolve the “output window” question
Need an efficient means to use X pixmaps as OpenGL textures: GLX_EXT_texture_from_pixmap
To bring Composite to the mainstream:
OpenGL implementers: add support for direct-rendering to redirected windows
OpenGL implementers: add support for texture_from_pixmap
Continue to improve Render acceleration
EXA is making great progress
NVIDIA will continue to improve its Render support
Address Xv + Composite
Fix remaining Composite bugs in X.Org server
Enable Composite by default
Establish industry standard benchmarks
Does x11perf measure everything about Render that we care about?
As OpenGL composite manager technology matures, construct appropriate benchmarks
Encourage healthy performance competition through posting benchmark results
Ensure that driver developers and IHVs take X performance seriously
Establish industry standard conformance tests
Is rendercheck exhuastive?
Should rendercheck be folded into VSW?
Correctness tests for texture_from_pixmap
The existing loadable driver framework:
Can rovide high performance Render acceleration
Can support accelerated composited X desktop
Is flexible enough to allow vendor-provided features
Requires only incremental enhancements
Is the best driver model to achieve our goals