Using The Existing Driver Framework To Achieve a

Using The Existing Driver Framework To Achieve a Composited X Desktop XDev. Conf, February 8, 2006 Andy Ritger, NVIDIA Corporation

Introduction Make the case for using the existing XFree 86/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-Open. GL driver model with the existing loadable driver model Address arguments and misconceptions surrounding X-on-Open. GL Present a roadmap for how to get from today to a production-quality composited X desktop Copyright © NVIDIA Corporation 2004

The Existing Loadable Driver Framework 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 Open. GL Twin. View/Merged. FB Quad-Buffered Stereo Workstation Overlays SLI Copyright © NVIDIA Corporation 2004

The X-on-Open. GL Model Motivated partly by lack of hardware-acceleration of the Render extension A successful implementation of X-on-Open. GL, Xgl, is in progress Replace XFree 86/X. Org DDX with DDX that renders using Open. GL No hardware-specific X driver Instead use hardware-specific Open. GL driver Traditional X driver tasks (rendering, modesetting) handled by X-on-Open. GL DDX calls stand-alone Open. GL driver to perform low-level rendering and modesetting Copyright © NVIDIA Corporation 2004

Goals for X Windows 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 Copyright © NVIDIA Corporation 2004

Goals for X Windows (cont. ) 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 Copyright © NVIDIA Corporation 2004

Goals for X Windows (cont. ) 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 Open. GL 7) Grant vendors the flexibility to expose vendorspecific features such as Twin. View/Merged. FB, Quad. Buffered Stereo, SLI, and Frame. Lock Copyright © NVIDIA Corporation 2004

Goals for X Windows (cont. ) 8) Give users the flexibility to chose for themselves when they want a composited desktop and when they want full performance Open. GL 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 Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: 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 Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: Goal 4: Improve PCI configuration interaction 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 Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: Goal 5: optimal performance, and best possible use of available GPU power Both X driver and Open. GL have access to the same hardware capabilities Additionally, X driver has more context, and should be able to make better tradeoffs Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: Goal 5 (cont. ) 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: EXA Render getting more attention from NVIDIA: Many improvements and stability fixes made “Render. Accel” enabled by default in nvr 85 release Much more tuning possible and will be phased in Current driver model atleast as capable as X-on. Open. GL to make optimal use of GPU Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: Goals 6 and 7 considered together; both focus on giving vendors the flexibility to support features like directrendered Open. GL, Twin. View, Stereo, Overlays, and SLI Existing driver model allows these features X-on-Open. GL model poses problems for supporting these advanced features Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: Goals 6 and 7 (cont. ) Direct-rendering Open. GL 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-Open. GL model, there is no vendor-provided server component Who handles direct-rendering data propogation and synchronization in X-on-Open. GL? Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: Goals 6 and 7 (cont. ) Using same Open. GL library for X-on-Open. GL X server and direct-rendering client would require special communication between X server and Open. GL: Open. GL library needs to know if it is in client or server Open. GL library in server must manage data propogation and synchronization Xgl supports indirect rendering only Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: Goals 6 and 7 (cont. ) Features such as: Frame. Lock Quad-Buffered Stereo Workstation Overlays SLI depend on coordination between vendor's X driver and Open. GL client library Implementing these in the X-on-Open. GL model would require complex back doors The X-on-Open. GL model does not give vendors the flexibility to adequately support these features Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: 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-Open. GL not conducive to vendor-provided advanced features This goal not achievable with X-on-Open. GL With current driver framework, users can disable Composite and have full performance and functionality Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: 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-Open. GL 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 Copyright © NVIDIA Corporation 2004

Comparison of Driver Models: Summary Existing driver framework can do everything that Xon-Open. GL 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 Copyright © NVIDIA Corporation 2004

Arguments & Rebuttals In the following section, we review a collection of arguments and misconceptions surrounding X-on. Open. GL; each is followed by a rebuttal. Copyright © NVIDIA Corporation 2004

Arguments & Rebuttals (cont. ) Argument: "Using accelerated Open. GL 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 Open. GL driver. An X driver should perform at least as well as X-on-Open. GL on the same hardware. Copyright © NVIDIA Corporation 2004

Arguments & Rebuttals (cont. ) Argument: Open. GL applications cannot work with Composite unless the X server is also using Open. GL for its rendering. Response: The Open. GL 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 Open. GL accomplishes its rendering is not dependent on how X implements its rendering. Copyright © NVIDIA Corporation 2004

Arguments & Rebuttals (cont. ) Argument: Using Open. GL for compositing the X desktop requires that the X server use Open. GL for its rendering. Response: The composite manager can composite however it likes (Render, Open. GL, core X primitives). A composite manager can use Open. GL by retrieving redirected windows' pixmap data, and using that data as an Open. GL 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. Copyright © NVIDIA Corporation 2004

Arguments & Rebuttals (cont. ) Argument: ". . . 3 D [hardware] is simply faster than 2 D [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. Copyright © NVIDIA Corporation 2004

Arguments & Rebuttals (cont. ) Argument: "At some future point the graphics chip vendors are going to remove that dot labeled 2 D and only leave us only with 3 D 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. Copyright © NVIDIA Corporation 2004

Arguments & Rebuttals (cont. ) Argument: X-on-Open. GL will be easier for IHVs, because now an IHV will only need to provide a stand-alone Open. GL driver, rather than both an Open. GL driver and an X driver. Response: If the goal were simply to accelerate X rendering, then this might be true. However, the X-on-Open. GL model makes it much more difficult for vendors to provide advanced features. From this perspective, X-on-Open. GL will not make things easier for IHVs. Copyright © NVIDIA Corporation 2004

Arguments & Rebuttals (cont. ) Argument: X-on-Open. GL 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-Open. GL and only depend on IHVs for an Open. GL implementation. Response: Implementing a full Open. GL driver is a huge task; implementing Render acceleration is a much smaller task. An IHV commited enough to Linux to provide an Open. GL driver is going to be interested in having that Open. GL implementation exposed to direct-rendering Open. GL clients, and will likely be interested in also exposing vendor-specific features. Copyright © NVIDIA Corporation 2004

Arguments & Rebuttals (cont. ) 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. Copyright © NVIDIA Corporation 2004

Future Directions Open. GL-based composite managers Need to resolve the “output window” question Need an efficient means to use X pixmaps as Open. GL textures: GLX_EXT_texture_from_pixmap To bring Composite to the mainstream: Open. GL implementers: add support for direct-rendering to redirected windows Open. GL 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 Copyright © NVIDIA Corporation 2004

Future Directions (cont. ) Establish industry standard benchmarks Does x 11 perf measure everything about Render that we care about? As Open. GL 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 Copyright © NVIDIA Corporation 2004

Conclusion 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 Copyright © NVIDIA Corporation 2004

Questions? http: //developer. nvidia. com/object/ xdevconf_2006_presentations. html Copyright © NVIDIA Corporation 2004