AMD Releases R300 3D Register Guide

[phoronix]

Phoronix: AMD Releases R300 3D Register Guide

Last month right before FOSDEM 2008, the 3D programming documentation for the R500 GPUs (Radeon X1000) series was released. This documentation consisted of a register reference guide for the R500 GPUs as well as a programming guide covering such areas as the command processor, vertex shaders, and fragment shaders. While the register reference guide for the R600 series is still being worked on, for those with older ATI graphics processors, AMD has went back and created a register reference guide for the R300 series.

http://www.phoronix.com/vr.php?view=12022

[Svartalf]

There's an extra %20 on the end of the URL on the link to the developer GPU info page on the article, and there doesn't seem to be any R300 technical docs up just yet...

[Michael]

There's an extra %20 on the end of the URL on the link to the developer GPU info page on the article,

Oops, fixed.

and there doesn't seem to be any R300 technical docs up just yet...


They are on X.Org server right now and should be on AMD server shortly (I expect).

[agd5f]

They are on X.Org server right now and should be on AMD server shortly (I expect).

I put the request in. They should be up soon on the AMD servers. For now you can grab it from the Xorg site.

[Svartalf]

Already got it. Looks like we're going to get the 3D in there sooner than later. Makes me want to find a bit of time to help with Gallium, it does. Reading up on what the plan is, it sounds like a lot of fun.

[yoshi314]

i wasn't expecting this docs to get released so quickly. ati continues to surprise me with their commitment.

[Ole-Martin Broz]

Well, i just got a box that can put my x800 xT AGP to work soon with OSS driver :D

Looking good ati, keep up the good work to make my multi os experience EVEN better!.

I dont fancy nvidia much, even though they got good linux drivers, but laptops i go with nvidia, might be changing very very soon at this rate :D

Ati keeps suprising us all i think yoshi :p

From being the worst too soon the best i guess!

[avsa242]

They're grouped in with the R300 driver in dri/mesa sources, but I'm uncertain...does this include the dreaded XPress 200M and co., or will there be a separate RS480 dump?

Cheers,
Jesse

[agd5f]

They're grouped in with the R300 driver in dri/mesa sources, but I'm uncertain...does this include the dreaded XPress 200M and co., or will there be a separate RS480 dump?


This covers RS4xx 3D as well. The only exception is the lack of a vertex shader.

[bridgman]

For clarity, it's the RS480 which lacks the vertex shader, not the documentation ;)

[chrisr]

Is there anything standing in the way of fully-capable 3D OpenGL support for R300 cards now? And video playback too?

[Pickup]

I know R1xx-R2xx specs were (partly) released under NDA. Then I wonder, does it make any sense to keep those old chips specs "private" when the newer ones are disclosed?

[Michael]

I know R1xx-R2xx specs were (partly) released under NDA. Then I wonder, does it make any sense to keep those old chips specs "private" when the newer ones are disclosed?


I don't believe they want to invest much time in chips that old, but I think the larger problem is finding any of those NDA documents these days as I think John mentioned before.

[bridgman]

I do want to re-release the Radeon 8500 programming guide without NDA, but mostly since it is a pretty good introductary guide for new driver devs. I doubt there is a line of text in the document which has not already been used in the radeon (xf86-video-ati) driver so re-releasing the doc isn't really going to help advance the R200 driver support, but if it allows a few more people to become active developers that can make a big difference.

We have to locate the original document in the archives and change all the legal text before releasing it, and we simply felt that getting the 3d information out there was a higher priority. Other than IDCT/MC for video decoding I don't think there is much info about the R100 and R200 which isn't already known to the devs. The R200 has some programmable vertex shader (PVS) capability which isn't fully documented today but (a) the R5xx and R3xx 3d docs give a pretty good idea how it works, and (b) I don't think adding PVS support to R200 will make a big difference to users these days (but I'm open to comments there).

[pheldens]

To avoid the confusion I detect in this thread: Up to X850 was already supported by open drivers. I hope these drivers will see some quality and speedup improvements.

[Dieter]

> I doubt there is a line of text in the document which has
> not already been used in the radeon (xf86-video-ati) driver
> so re-releasing the doc isn't really going to help advance
> the R200 driver support, but if it allows a few more people
> to become active developers that can make a big difference.

Having the docs available is a good thing. Some people
actually refuse to look at existing code due to worries
about IP contamination.

> Other than IDCT/MC for video decoding I don't think there is
> much info about the R100 and R200 which isn't already known
> to the devs.

Video decoding is important.

What docs are available for the RAGE-XL?

I was reading about the 780G, it sounds promising, can we
assume that it will be documented?

As always, thank you for documenting these chips.

[chrisr]

Other than IDCT/MC for video decoding I don't think there is much info about the R100 and R200 which isn't already known to the devs.

I don't think that the devs fully understand how HyperZ works with the R100/R200 chips. I have a card with an R100 chip, and Mesa's "stex3d" demo and "zreaddraw" test programs are currently broken with HyperZ enabled.

[airlied]

Other than IDCT/MC for video decoding I don't think there is much info about the R100 and R200 which isn't already known to the devs. The R200 has some programmable vertex shader (PVS) capability which isn't fully documented today but (a) the R5xx and R3xx 3d docs give a pretty good idea how it works, and (b) I don't think adding PVS support to R200 will make a big difference to users these days (but I'm open to comments there).

IDCT/MC is probably the main missing bit, I know it changed between r200 and r300 also,

Roland already reverse engineered most of the PVS on r200 a few years ago now using the r300 as a basis, so I think he got as much out of it as possible..

Hyper-Z and PN-triangles(TruForm) were two features for r200 never documented, HyperZ I believe we have mostly reverse engineered I think the final bugs are nobody implemented z buffer readback, or disabling hyperz where that was needed, and TruForm isn't that interesting as I'm not sure many games ever actually used it. (ATI_pn_triangles I think was the extension).

[ethana2]

I have an ATi Radeon 9200SE PCI 128MB card.

It performs a lot better under windows in FOSS games like tremulous and nexuiz than it does in the same on ubuntu.
I would love to see that change.
Every little bit helps.

[airlied]

I have an ATi Radeon 9200SE PCI 128MB card.

It performs a lot better under windows in FOSS games like tremulous and nexuiz than it does in the same on ubuntu.
I would love to see that change.
Every little bit helps.


try enabling hyper-Z, in .drirc or just run

export hyperz=true before running a game..

it might get a bit faster.

[xeros]

Many people still have ATI Radeon 9200/9200SE/9200PRO cards so any improvement in the driver for these chipsets is very welcome. And I'm still waiting for improvements in R300 driver code.
Is there any date planned for new release of Radeon driver?

[dungeon]

Yes this is true, i'm try Sauerbraten with Ati 9250. In Windows water refraction/reflection not slowing things like the same game with radeon driver in Ubuntu (don't know exactly, but this is
seems to be due lack of occlusion extension (i'm read somewhare that this extension has some IP status, and because of that is hard to implement in radeon?) and because of this many games is very slow
in open areas). And yes enabled hyperz in driconf speed things a bit with some games, but have weird bugs plus, in Serious Sam (or JediKnight: JA) in Wine, or with native installer for SSam F/S (how to say) unplug/perforation/blinked lighting in areas with sun rays, lamps or similar. Also Doom3 has some problems with mirroring, that's not happen in Windows, etc... There is much room of improvements on r200, maybe that documentations help developers in some for these kind of problems and on the other hand also
with newer chips.

[glisse]

Is there anything standing in the way of fully-capable 3D OpenGL support for R300 cards now? And video playback too?

Actually, people to write the code...

[legume]

IDCT/MC is probably the main missing bit, I know it changed between r200 and r300 also

I never see anyone mention the deinterlacing capabilities that seem to have been in radeons for a long time.

Do you have any info on this, or know if my RV530 has h/w capabilities that can be exposed/documented.

I also have in other family members older PCs a 7500 and a 9600.

My wife watches interlaced DVB-T quite a lot on the 7500 and doesn't have enough CPU to do nice software deint, so it would be nice to see it work or get some info about it.

[bridgman]

I think the deinterlacing is built into the overlay block on the pre-5xx Radeons, while on 5xx and up de-interlacing is done with shaders.

[Nicolas]

That's really nice... Gives me hope of using OSS drivers on my Mobility X700!

Unfortunatelly that depends on people to code it. If I had the time and the knowledge I wouldn't mind helping, but that's no the case right now.

AMD is really surprising me with that and the latest driver, which at least fixed some lame bugs and also gave performance improvement in AIGLX.

[legume]

I think the deinterlacing is built into the overlay block on the pre-5xx Radeons, while on 5xx and up de-interlacing is done with shaders.

Thanks for the info.

It would be great if the docs for it could be released - I have never seen it work - testing R100 on windows, with vlc/directx didn't get anywhere. I thought maybe the player needed to know to spit out 50 fields/sec rather than kludge them into 25fps or something. I tried ati player, but my wifes box is old and doesn't have DVD. The DVB-T is streamed on my lan and I couldn't get it play the stream.

As for my RV530 - it would be a great feature to have as 1080i has been adopted as the HD standard here in the UK. I can do a nice framerate doubling deint in softwere (mplayer -vf yadif=1) for SD OK on my box, but it eats lots of CPU so HD won't work. An added complication being I will (if I ever get round to getting a DVB-S card) need to downscale for my monitor which judging by the HD mpeg2 test streams [1] makes interlacing artifacts look even worse.

If 5xx and up use shaders for deint I guess that holds out the posibility of a player doing the same with ARB instructions like mplayer does with -vo gl ?

I noticed on fglrx that xv still beats -vo gl for CPU usage doing yuv->rgb and scaling - is that just because the gl fragment prog is less efficient or is the gl yuv->rgb & scale very different internally to the one xv uses?

Sorry for so many questions :-)

1.

I guess the player may be at fault here aswell for apparently kludging 50 fields/sec to 25fps.

HD test streams park run and newmobilecalendar from

http://www.w6rz.net/

Some SD streams (low bitrates - x_015 are mpeg1 and high x_400 are 4:2:2 so use others which are mpeg2 4:2:0).
bbc3 is particulary nasty for interlacing artifacts on a CRT @ 1024x768.

ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/

[ssmaxss]

It will be grate if you will release specifications for PowerPlay support. Now it doesn't work on my mobile radeon 9200. For example see this bug: https://bugs.freedesktop.org/show_bug.cgi?id=7061
T

[jimik]

hello, now that amd released the register references for r3xx cards, i wonder which driver will be improved (radeonhd (maybe not)?, r300?, new_driver?) will it be dri2 only? :)
id basically like to follow development on this one, i have a 9800pro and curently use fglrx for performance. fglrx performance isnt as it could be but still much better than current r300.

[Uchikoma]

hello, now that amd released the register references for r3xx cards, i wonder which driver will be improved (radeonhd (maybe not)?, r300?, new_driver?) will it be dri2 only? :)
id basically like to follow development on this one, i have a 9800pro and curently use fglrx for performance. fglrx performance isnt as it could be but still much better than current r300.

Add this to your Bookmarks Toolbar (RSS Feeds):

Radeon:
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=rss

RadeonHD
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=rss

...and you can track the convo's in the IRC channels either by going to #radeon or #radeonhd on the Freenode IRC servers. Or you can read up on it via http://www.radeonhd.org/

Then of course, anything that's posted there and there you go ^^

[bridgman]

The largest part of the impact from the R3xx documentation will be in the 3D stack (mesa/mesa mostly, mesa/drm a bit) which is separate from radeonhd and radeon anyways. That said, most of what was traditionally thought of as "2D acceleration" (video, EXA etc..) now relies heavily on the 3D engine and the docs will also allow improvements there.

Since the radeonhd driver is aimed only at more recent chips (currently R5xx and up) you won't see R3xx/4xx work done directly in that driver, but any improvement made to the acceleration code in radeon will probably have some impact on radeonhd shortly afterwards. As an example, Alex was able to get full EXA Render working for the first time last night on R300, and that work is an important step towards providing the same functionality on R5xx and higher ASICs.

[kingos]

Hi, I would also like to ask (as ssmaxss did) when will be the PowerPlay specification released. because it is the only think that makes me use fglrx instead of radeon driver (correct me if I`m wrong, there is no xrandr support in fglr).

pK

[bridgman]

We're still figuring out how much work it will be to organize power management documentation, so we don't really have a schedule yet. I can say that it seems like it should be the next priority after R6xx 3D, but I don't know how many chip-to-chip differences we are going to have to deal with.

[kingos]

We're still figuring out how much work it will be to organize power management documentation, so we don't really have a schedule yet. I can say that it seems like it should be the next priority after R6xx 3D, but I don't know how many chip-to-chip differences we are going to have to deal with.

Hi, any progress here?

Thanks in advance

pK

[ivanovic]

Hi, any progress here?


Since r6xx 3D specs are not out so far, the power specs for the lower series ain't out either.

[Vighy]

I do want to re-release the Radeon 8500 programming guide without NDA, but mostly since it is a pretty good introductary guide for new driver devs. I doubt there is a line of text in the document which has not already been used in the radeon (xf86-video-ati) driver so re-releasing the doc isn't really going to help advance the R200 driver support, but if it allows a few more people to become active developers that can make a big difference.

We have to locate the original document in the archives and change all the legal text before releasing it, and we simply felt that getting the 3d information out there was a higher priority. Other than IDCT/MC for video decoding I don't think there is much info about the R100 and R200 which isn't already known to the devs. The R200 has some programmable vertex shader (PVS) capability which isn't fully documented today but (a) the R5xx and R3xx 3d docs give a pretty good idea how it works, and (b) I don't think adding PVS support to R200 will make a big difference to users these days (but I'm open to comments there).

mhh so no progress in this sector? :)

If r200 model is not difficult it would be a nice start since many people still own such chips ;)

[glisse]

mhh so no progress in this sector? :)

If r200 model is not difficult it would be a nice start since many people still own such chips ;)

I think this is the greatest informations GAP in the open source world, we mostly don't know what is the most common hardware on which linux run and so to which kind of hardware we should still pay attention. If you look at all the latest development in the desktop area (compiz, kde, ...) they pretty much all assume that user have some kind of recent GPU like HD2xxx or newer (r5xx at least). I think some distributions try to gather hardware informations but don't know if anyone beside them can know what is the most used hardware.

Sidenote: i hope all AGP will die quickly (quicker the better) :)

[Vighy]

I think this is the greatest informations GAP in the open source world, we mostly don't know what is the most common hardware on which linux run and so to which kind of hardware we should still pay attention. If you look at all the latest development in the desktop area (compiz, kde, ...) they pretty much all assume that user have some kind of recent GPU like HD2xxx or newer (r5xx at least). I think some distributions try to gather hardware informations but don't know if anyone beside them can know what is the most used hardware.

Sidenote: i hope all AGP will die quickly (quicker the better) :)

:( But it means we should also change the whole computer as well... and mine (AthlonXP 2600+) still works quite well (ok, firefox should start faster to make me happy... but that's not a big problem :D)

And not everybody uses the most recent fancy devourers of resources :D so old good HW is still functional sometimes. ok, I know AGP may be a problematic architecture but who designed it is the one to blame :D ;)

[signor_rossi]

I am also in the crowd that is eagerly awaiting PowerPlay support in the radeon driver for my Mobility X600 card, especially now that AMD has dropped support for that card in fglrx. :(
Any news on that matter?

[glisse]

I am also in the crowd that is eagerly awaiting PowerPlay support in the radeon driver for my Mobility X600 card, especially now that AMD has dropped support for that card in fglrx. :(
Any news on that matter?

Most of powersaving options should already be supported for X600 (R4xx) chipset (man radeon and look for anythings with clock in the name). I believe Powerplay was introduced with X1xxx (R5XX) and is part of atombios. Note that Matthew Garrett also have a couple of nice powersaving tricks available for r5xx.

[signor_rossi]

Most of powersaving options should already be supported for X600 (R4xx) chipset (man radeon and look for anythings with clock in the name). I believe Powerplay was introduced with X1xxx (R5XX) and is part of atombios. Note that Matthew Garrett also have a couple of nice powersaving tricks available for r5xx.

X600 is an RV380 chip IIRC and therefore Pre-ATOM (last time I asked a developer clarified that). This is what I get from aticonfig --lsp:

[val@tux ~]$ aticonfig --lsp

core/mem [flags]
-----------------
1: 105/122 MHz [low voltage]
* 2: 398/250 MHz [default state]

IIRC it 'low voltage' is the important thing fglrx does and radeon didn't last time I tried, not only lowering the clock but also lowering the voltage and do some PCI powersaving stuff.
This is what I get for PowerPlay from aticonfig -h:

POWERplay Options:
Following options will not change the config file.
These options will be effective immediately. Other options on
the same command line will be ignored.
--lsp, --list-powerstates
Print information about power states and exit.
--set-powerstate=NUMBER
Set a power state listed by --list-powerstates.
--auto-powerstates=on|off
Enable/disable automatic transitions between battery and performance
modes on AC/DC transitions. This automatic mode is enabled by default,
and may compete with atieventsd style power management.


It is just that switching between fglrx and radeon is not trivial on Arch (atm I would have to upgrade to xorg-server-1.6 to try xf86-video-ati 6.12.2) so I wanted not to try radeon only out of the blue and asked about the state of affairs again...

Thanks for the response.


EDIT: Is that was I was looking for?
http://www.phoronix.com/scan.php?page=news_item&px=NzIwNg

So how would I get this version of the radeon driver?

BIG EDIT: I think I will ask further question in the discussion of the article I linked to. Thanks!

[glisse]

EDIT: Is that was I was looking for?
http://www.phoronix.com/scan.php?page=news_item&px=NzIwNg

So I would have to check out from git?

aticonfig is useless with opensource driver, there is a tool called radeontool which should be somewhere on the net and maybe even available through your distribution which gives you same option as aticonfig ie to lower gpu & ram frequency and also enable other powersaving options. It's also available in lastest ddx through Xorg configuration (thus needing X restart each time you want to change configuration).