using the existing driver framework to achieve a composited x desktop

Using The Existing Driver Framework To Achieve a Composited X Desktop

XDevConf, February 8, 2006Andy Ritger, NVIDIA Corporation

Copyright © NVIDIA Corporation 2004

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


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


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


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


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



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


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


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



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


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


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


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?


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


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



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


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


Arguments & Rebuttals

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


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.



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


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


Response: That is certainly not true in the case of NVIDIA.


Future Directions

OpenGL-based composite managersNeed to resolve the “output window” questionNeed 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 windowsOpenGL implementers: add support for texture_from_pixmapContinue to improve Render acceleration

EXA is making great progressNVIDIA will continue to improve its Render support

Address Xv + CompositeFix remaining Composite bugs in X.Org serverEnable Composite by default


Future Directions (cont.)

Establish industry standard benchmarksDoes 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 testsIs rendercheck exhuastive?

Should rendercheck be folded into VSW?

Correctness tests for texture_from_pixmap


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


Questions?

http://developer.nvidia.com/object/xdevconf_2006_presentations.html

using the existing driver framework to achieve a composited x desktop

Documents