I’ve just pushed initial evergreen (Radeon HD5xxx) modesetting support to xf86-video-ati. There are still some issues to be sorted out with multi-head, and displayport doesn’t quite work yet, but these will be worked out soon. Initial evergreen KMS modesetting support is also just about done and will be released soon. Acceleration is not available yet.
Just got it working
It’s still pretty slow due to using memcpy for buffer swaps, but that should get fixed up soon.
mesa from git master, drm kernel modules from my r6xx-r7xx-3d drm branch.
Over the last few days Richard, Cooper, and I have sorted out the last major issues with getting the r6xx/r7xx code ported from our original code base to the radeon-rewrite model. Today we finally solved the issues with buffer aging and now gears is working again! Most of the code is in place so from now on it should mostly be a matter of bug fixing. Note the the current code does not perform very well for double buffered applications as we are using memcpy to do buffer swaps which really hurts when doing vram to vram copies. I’m getting about 15 fps on gears with memcpy. Playing around with gpu accelerated copies easily got me a 100x improvement. Same goes for texture uploads. The clear code calls back into mesa to clear similar to the kms paths in the other radeon and intel 3d drivers. The clear color does not get set right yet on r6xx chips, so the clear color will likely be wrong for most r6xx users. You’ll need the radeon driver from git master or the 6.12-branch or radeonhd driver from git and the r6xx-rewrite branch of mesa (http://cgit.freedesktop.org/mesa/mesa/?h=r6xx-rewrite) along with the r6xx-r7xx-3d branch of my drm tree (http://cgit.freedesktop.org/~agd5f/drm/?h=r6xx-r7xx-3d). The drm kernel modules only build against 2.6.27 or 2.6.28 at the moment. I’ll create a patch against the kernel when things are further along.
UPDATE: R6xx/RS780 is now working. Apparently on R6xx, you always need to emit a fetch shader even if you are not using it.
UPDATE2: The r6xx-rewrite branch of mesa has moved to master, so from now on use mesa master.
There have been a number of requests for information about the power management on radeon chips. Most of the information is out there, it just hasn’t been taken advantage of it yet. Here is a brief overview of the functionality and how to use it. For more information about the atombios command and data tables see atombios.h. Information on the pre-atom command and data tables is available in radeontool.
1. Engine clock scaling - Reducing the engine clock reduces power usage at the expense of performance. Chips with atombios have a command table (SetEngineClock) to adjust the engine clock. On pre-atom chips, I’ve provided a function to do this in xf86-video-ati (RADEONSetEngineClock() in radeon_pm.c).
2. Memory clock scaling - Reducing the memory clock reduces power usage at the expense of bandwidth. When adjusting the memory clock you need to make sure you have enough bandwidth available to meet the needs of all current memory clients (displays, 2D engine, 3D, engine, overlays, etc.). Chips with atombios have command tables (SetMemoryClock) to adjust the memory clock. I have some code to do this on pre-atom chips, but you need execute oem specific memory reset and dll tables in the bios to properly initialize and reset the memory controller. I haven’t sorted these out yet in clean way yet.
3. PCIE lane adjustment - Reducing the number of active PCIE lanes reduces power usage at the expense of bandwidth. I’ve provided code in xf86-video-ati for changing the number of PCIE lanes on all PCIE capable asics (RADEONSetPCIELanes() in radeon_pm.c).
4. Voltage adjustment - Chips with atombios have command (SetVoltage) and data (PowerPlayInfo and IntegratedSystemInfo) tables regarding voltage control. I haven’t had time to dig into how they work yet. On pre-atom chips, the voltage is controlled via a gpio which is specified in the bios powerplay and integrated systems tables. Voltage scaling is only available on chips that have a voltage regulator (oem dependent).
5. Clock Gating - Enabling clock gating allows the asic to dynamically turn off the clock to parts of the chip when they are not in use. Chips with atombios have a command table (DynamicClockGating) to enable this. Support for pre-atom chips is in xf86-video-ati (LegacySetClockGating() in radeon_pm.c).
6. Pixel clock scaling on laptop LCD panels - Slower pixel clock programmed just like the normal pixel clock. Tables (PowerPlayInfo in atombios and powerplay table in pre-atom) in the bios specify whether or not this is supported and what clock should be used.
7. Thermal sensors and fan control chips - Third party chips controlled by i2c. The chips, i2c slave addresses, and gpio info for i2c are all specified in the bios data tables (PowerPlayInfo and GPIO_I2C_Info tables in atombios; powerplay and overdrive tables on pre-atom chips). Documentation for most of the 3rd party chips are available from the manufacturer’s websites.
The current xf86-video-ati driver takes advantage of some of these options (engine clock scaling, pcie lanes, and clockgating) with my recent power management changes. xf86-video-radeonhd as also picked up support for engine clock scaling. However fully dynamic power management will need to be implemented in the new KMS (kernel modesetting) enabled drm since only that driver has the full view of the hardware necessary for fully dynamic state transitions (e.g., making sure power state is appropriate to support the requested rendering (2D, 3D, and video) and display operations (dual head vs. single head, etc.)). Also, the drm can take advantage of existing i2c sensor drivers and infrastructure that are already part of the kernel for exposing things like temperature and fan control.
Since there have been a number of bug fixes as well as a lot of experimental code in xf86-video-ati master since 6.12.2 was released, I’ve created a 6.12 stable branch (6.12-branch) with all of the bug and stability fixes since 6.12.2 was released. This should be useful for distros that just want to track bug and stability fixes since the last major release.
I’m pleased to announce the release of the initial sample 3D driver for R6xx/R7xx hardware. It’s available on the r6xx-r7xx-support branch of mesa:
To test this branch, you will need updated drm kernel modules and radeon drm headers from the r6xx-r7xx-3d branch of my drm tree:
This will be moving to the main drm tree soon.
We will be syncing this code up with the work going on in the radeon-rewrite branch of mesa over the next few weeks:
Many thanks to Richard Li and Cooper Yuan as they have done most of the work on this so far.
The driver is currently incomplete and only runs a few mesa demos at the moment, but development will be picking up and continuing in the main mesa tree.
I’ve just pushed a major textured video rework for radeon. Many thanks to Roland Scheidegger for getting the ball rolling on this and for doing the initial implementation of Xv controls for brightness, hue, contract, etc. What’s new:
- Native support for planar formats (no more swizzling to packed)
- Xv attributes for brightness, contrast, hue, saturation, gamma, colorspace (BT.601, BT.709)
Note, the new attributes do not work in conjunction with bicubic filtering yet, so you’ll need to disable bicubic filtering to use the attributes.
I’ve just pushed some basic power saving code for radeon. I’ve unified and cleaned up the clock gating code (former option DynamicClocks) and changed the option to ClockGating to better reflect what it does. In addition there is now a DynamicPM option that will reduce power usage when the computer is idle, and a ForceLowPowerMode option that forces a low power mode all the time. See the updated radeon man page for more information.
I just merged the R6xx/R7xx EXA/Xv code to the master branch of xf86-video-ati. It’s disabled by default. If you want to test it you’ll need an updated drm: either the drm-next branch of Dave’s drm-2.6 tree or the r6xx-r7xx-support branch of the drm tree.
Update: for those of you that prefer radeonhd, I’ve merged r6xx/r7xx accel to master there too now.
For those of you with RS600 (Intel-based X1200/X1250 IGP systems), I’ve just pushed (untested) support for those chips. You’ll need xf86-video-ati from git (master branch), and drm from git (r6xx-r7xx-support branch). The RS600 GART setup is more like R6xx/R7xx chips than the older IGP chips, hence the drm code being on the r6xx-r7xx-support branch of the drm. I don’t have an RS600-based system, so this is untested and may need a bit more work. If you have such a system, please test and let me know how it goes.
UPDATE: I’ve gotten confirmation that this indeed works! I’ve pushed a mesa patch as well to enable 3D on rs600 chips and Dave has queued the drm patches. Also, to clarify, the RS600 pci ids are: 0×793F, 0×7941, 0×7942. If you have an X1200/X1250/X1270 IGP system with another pci id, they you have an RS690 which is already supported.