1 / 32

Achieving a Composited X Desktop with Existing Driver Framework

This presentation discusses using the existing XFree86/X.Org DDX loadable driver framework to achieve a production-quality composited X desktop. It compares the X-on-OpenGL driver model with the existing loadable driver model and presents a roadmap for implementation. The goals for the X window system and the benefits of the existing loadable driver framework are also discussed.

nickya
Download Presentation

Achieving a Composited X Desktop with Existing Driver Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Introduction 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

  3. 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 OpenGL TwinView/MergedFB Quad-Buffered Stereo Workstation Overlays SLI

  4. The X-on-OpenGL Model 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

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

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

  7. 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 OpenGL 7) Grant vendors the flexibility to expose vendor-specific features such as TwinView/MergedFB, Quad-Buffered Stereo, SLI, and FrameLock

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

  9. Comparison of Driver Models:Goals 1, 2, and 3 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

  10. Comparison of Driver Models: Goal 4 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

  11. Comparison of Driver Models: Goal 5 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

  12. 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 “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

  13. Comparison of Driver Models:Goals 6 and 7 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

  14. Comparison of Driver Models: Goals 6 and 7 (cont.) 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?

  15. Comparison of Driver Models: Goals 6 and 7 (cont.) 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

  16. Comparison of Driver Models:Goals 6 and 7 (cont.) Features such as: FrameLock Quad-Buffered Stereo Workstation Overlays SLI 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

  17. Comparison of Driver Models: Goal 8 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

  18. Comparison of Driver Models: Goal 9 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

  19. Comparison of Driver Models:Summary 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

  20. Arguments & Rebuttals In the following section, we review a collection of arguments and misconceptions surrounding X-on-OpenGL; each is followed by a rebuttal.

  21. Arguments & Rebuttals (cont.) 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.

  22. Arguments & Rebuttals (cont.) 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.

  23. Arguments & Rebuttals (cont.) 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.

  24. Arguments & Rebuttals (cont.) 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.

  25. Arguments & Rebuttals (cont.) 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.

  26. Arguments & Rebuttals (cont.) 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.

  27. Arguments & Rebuttals (cont.) 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.

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

  29. Future Directions 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

  30. Future Directions (cont.) 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

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

  32. Questions? http://developer.nvidia.com/object/ xdevconf_2006_presentations.html

More Related