Egbert Eich - The first release of the ATI RadeonHD driver is out!

Egbert Eich - The first release of the ATI RadeonHD driver is out!

Egbert Eich

[	userinfo	\|	livejournal userinfo	]
[	archive	\|	journal archive	]

The first release of the ATI RadeonHD driver is out!

[Nov. 30th, 2007|02:05 am]

[	Tags	\|	amd, novell, opensuse, radeonhd, x.org	]
[	Current Mood	\|	accomplished	]

The first release of the ATI RadeonHD driver is out!

Well, we did it! - We have just released xf86-video-radeonhd-1.0.0.

Sources can be found here.
More information can be found on the official radeonhd wiki.

The RadeonHD developers made the source code available to the public on September 18th (CET).
Since then a lot of people have picked up the code from the source code repository built and tested it. Some even packaged it for several popular Linux distributions and made those packages available.

A community of supporters, testers and developers have assembled around this driver. Various people have submitted code. Others are providing valuable testing feedback.

For graphics hardware this is probably needed more than for any other sort of hardware as graphics cards are shipped by a number of vendors which all provide their unique set of features to distinguish themselves from their competitors.

This release could have been done some weeks ago, but we were waiting to get feedback from users to fix problems and issues.
No driver will ever be completely free of issues and bugs of course but at least we could fix a number of things and make more users happy.

This driver supports:

Full mode setting driver for ATI Radeon R5xx and R6xx capable of driving multiple monitors.
Full RandR 1.2 support (with early RandR 1.3 property support).
Full libpciaccess support.
Supported subsystem:

Outputs: DVI-A, DVI-D, DVI-I, VGA.

Hardware cursor.

I2C for DDC.

Shadow framebuffer.

AtomBIOS support for initialization, data tables.
Backward compatibility to at least X.Org R6.9.

We would like our users and testers for all the valuable feedback we have received.
Also a special thank you goes to Hans Ulrich Niedermann (ndim) for thoroughly taking over build environment :)

Now there is some time to answer some questions that have been asked several times:

Why do we do a separate driver?

We have been asked by many people why we have created a separate module instead of extending the existing driver
for Radeon chipsets in the ATI driver for X.Org. There were several reasons:

Starting afresh gives the opportunity to cleanly. The Radeon driver has largely been rewritten for RandR 1.2 support but it supports a long list of chipset generations of which the earlier ones have not much in common with the latest one.
There will always be some overlap in subsystems between chipset generations but one should think twice to use this argument to add more and more generations of chipsets to the same driver module.
The step from R4xx to R5xx provided a good opportunity to start with a new driver module:
The mode setting interface has changed with R5xx hardware compared to earlier hardware. As mentioned above the video overlay engine of earlier chipset generations is gone.
The 2D and 3D engines are pretty much identical to earlier hardware. However 3D is only relevant to the extent as it is used for 2D acceleration in the X.Org driver anyway.
Core components of the code for 2D acceleration could well be shared between the two drivers if this is desirable.
Libpciaccess should offer support to automatically identify and load the correct driver module using the PCI vendor and device IDs from the drivers - pretty much as done already in the kernel. Therefore having one driver module per hardware vendor to simplify configuration for the user is an argument that becomes pretty much irrelevant in the near future.
I don't think we will be opposed to put the RadeonHD driver under a common umbrella with the other drivers for ATI hardware.
There has been a wrapper that probes for the hardware and loads the appropriate module which may be interesting to use if libpciaccess doesn't perform this job already. This loader module needs some serious cleanup before though.

When will feature XYZ arrive?

This mainly depends on the availability of documentation. ATI has made a tremendous job to prepare the documentation in a way that it can be released to the community without any strings attached (read no NDA required).
However this effort was driven largely by a single person at ATI - John Bridgman - who tirelessly worked to make this
initial release happen.
ATI has hired Alex Deucher - one of the leading developers of the free radeon driver - who will help to improve the information flow between ATI and he free software community.
We expect that ATI will release more information on hardware soon and the after processes for this have been fully established we will see documentation being released at a faster pace.

Here are some features people have been asking for:

2D acceleration (XAA/EXA). For R5xx this should be rather easy to implement as it is rather similar to earlier chipset generations and is actually on our TODO list.
XAA will be required for backward compatibility. At least until the very recent Xserver releases EXA still had issues so it was not enabled by default.
3D support (DRI/DRM). Here again R5xx is not much different from earlier Radeon chipset generations thus support for this should be easy to do.
This is not so much the concern of the X.Org driver as this is only involved in subsystem initialization.
Video overlays
Also video hardware overlay support as known in earlier hardware does not exist any more. In fact the video scaler is not available any more, only overlay support and some limited color space conversion is still available where the latter is rather irrelevant as these operations can be performed by modern CPUs at almost no cost.
Full video overlay support requires some 3D support to perform the scaling of the video to the size of the window.
TV Output.
This is actually something what is on our todo list.
Power management.
This will require some more documentation also.

Why don't we make more use of AtomBIOS?

We are making extensive use of AtomBIOS data tables to obtain information on hardware details which are card specific. This has been very useful however we have already come across data tables which contained data which we believe does not correctly reflect the hardware situation on the card.
We use AtomBIOS code tables to initialize uninitialized hardware on secondary cards which are not POSTed at boot time.

For most hardware subsystem we are programming the hardware directly instead of using AtomBIOS code tables after having done a thorough analysis of the code tables involved.

It is claimed that AtomBIOS code will provide support for new generations of hardware without the need to adapt the driver. This is true to some extent - however new generations of hardware may require an extension to the API of the table so the driver will still need to be fixed.
Furthermore we have found several cases where the API of the AtomBIOS call tables has changed between different BIOS generations in a way not reflected in the header.
We have found cases where code in the call tables contained bugs. We assume that AtomBIOS code has been tested to the extent the ATI Catalyst driver uses it.
Several call tables are not sufficiently atomic. Thus subsystems that should be treated independently cannot be handled this way.
For instance SetPixelClock which programs the PLL parameters to the pixel clock also calls EnableCRTC. This functionality should clearly be left to the component handling the CRTC subsystem.
AtomBIOS does not provide save/restore functionality. Since it is unknown which registers are touched by an AtomBIOS table it is hard to save and restore the text mode.
Using AtomBIOS will probably work in the majority of cases but numerous users might run into problems which are hard to control as control over a released BIOS is very limited.
Thus we expect that using AtomBIOS - although very compelling from a distance - may lead into a workaround nightmare.

Link

Comments:

From:

hexapod
2007-11-30 01:39 am (UTC)

(Link)

yay!

FWIW, with sample size N=1, there are people who will buy ATI (or Intel) vs NV until their driver situation improves. (Just replaced my video card with 2600XT because of this driver work)

Edited at 2007-11-30 01:41 am (UTC)

Great work! Thanks to everybody involved!

Re: Great work! Thanks to everybody involved!

Who's doing 3D

Re: Who's doing 3D

Re: Who's doing 3D

Re: Who's doing 3D

My blog about health and wealth

xanax 2 mg

buy cheap xanax

dxkrPhsMCCVFWqgjQBz

demand for

QdPsMYJOeGFAjXYARa

JBrqxzmxrloIvaam

FBPfNAKAmmMOo

Advertisement