This Is What Started AMD's Open-Source Strategy
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:
At first an initial driver will be implemented which will:
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:
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.
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.
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.
Latest Articles & Reviews
Latest Linux News
Most Viewed News This Week