1. What help can NOVELL offer?

X.Org Driver for ATI Radeon HD 2000 series

Novell will be happy to implement a driver for AMDs R600 hardware generation for the X Window System as implemented by X.Org.

We suggest the following procedure:

Initially this driver will be developed as a separate module. This module gets loaded automatically by the current 'ati' driver wrapper or as a stand alone driver or depending on the PCI id of the hardware \u2013 once support for this is available. An independent module guarantees minimal interference with ongoing development in the existing 'radeon' driver, while allowing us to exactly match the agreed upon features without delay. Once this driver is published the code can, depending on the desires of the developers community, be merged into the existing 'radeon' driver.

Development of the driver will take place in a step by step process:

1. Basic Driver

At first an initial driver will be implemented which will:

• POST uninitialized hardware,

• perform basic device initialization (like disabling VGA compatibility),

• map and enable access to memory and I/O resources,

• save/initialize and restore of video modes.

This will be implemented to the extent required to initialize a basic single analog output mode. It will utilize the new mode setting architecture of RandR 1.2 from the outset. It will allow to support dynamic reconfiguration of modes and output devices once these are implemented.

At this point work on other subsystems can commence in parallel:

1. Multiple Output Subsystems

Support for the second display controller, I²C busses, DDC, DVI encoders, and overlay sprites (hardware cursors) will be added. Depending on the availability of hardware, support for directly linked panels (LVDS/TTL) for Mobility devices can also be added at this stage.

The code will be structured that this could easily accomplished, once people start moving mode setting out of the Xsever and into either a separate daemon or into the kernel. Of course NOVELL will be happy to support this work, too.

We estimate that the implementation of a basic driver, dual display support with analog/DVI support, I²C, DDC and overlay sprites will require roughly 3 man months. This is of course a preliminary estimate, as detailed knowledge of the underlying hardware is currently not available. It also depends on the availability of programming information and the level of support from AMD regarding questions about hardware details.

Support for the Xillion HDTV encoder, 30bit color and color correction can be evaluated and estimated later, when more information is available. Implementation of this can take place at a later stage.

1. 2D Acceleration

To the best of our knowledge the old 2D acceleration engine has been removed from the latest generation of AMD graphics hardware. In this case it will be necessary to use 3D functionalities to implement accelerated 2D rendering.
Currently three options for 2D acceleration exist:

1. The XAA (X Acceleration Architecture) has been designed as an abstraction to interface X core protocol requests onto functionalities for classical 2D acceleration engines. XAA has been extended only minimally to support the RENDER extension, which is used for most modern graphics operations and compositing. Some best efforts have been made to map RENDER operations on existing XAA functionality. Presently, for most hardware XAA provides the most reliable 2D acceleration architecture still.

2. EXA is a new architecture that has been designed to accommodate the needs of image composition (alpha blending) better. While it provides the same basic functions and raster operations (ROPs) as XAA as for screen to screen copy or solid fills it also provides infrastructure to support alpha blending.

3. Glucose: Glucose maps 2D functionalities onto OpenGL requests. Like Xgl \u2013 a fully OpenGL based Xserver implementation previously done bu NOVELL \u2013 it makes full use of an underlying OpenGL implementation to accelerate 2D operations. If such an OpenGL implementation is available no other driver support is required to accelerate 2D graphics. It uses the same code paths as Xgl and allows to intermix RENDER and OpenGL for image transformation and compositing.

While the first and second approach only require the implementation of a fixed set of functionalities on the 3D engine, the last approach will most likely require a full OpenGL implementation. On the other hand, as a full OpenGL implementation almost is a requirement today, one would get 2D acceleration practically for free. We believe that this acceleration will be sufficiently fast \u2013 if not faster \u2013 than most (incomplete) EXA implementations.

Still some basic EXA support might be required to ensure backward compatibility to older versions of X11 which do not provide Glucose.

An exact time estimate will depend on the agreed upon feature set. Basic acceleration functions like ScreenToScreenCopy and RectFill can definitely be developed in 3 to 4 man weeks for option a and b once the basic infrastructure is in place. Option c will be easier to implement once an OpenGL implementation exists. It will accelerate almost all possible raster operations but to attain the required quality of the OpenGL implementation more time will be required.

Regardless of which approach is taken, it is clear that if we fully depend on the 3D engine for even basic 2D rendering we will need to acquire some knowledge on the 3D engine and shader programming to address 2D acceleration. More detailed requirements are listed in the respective sections.