AMD Documentation Drop Next Week

[phoronix]

Phoronix: AMD Documentation Drop Next Week

While we were hopeful that AMD would release the next set of GPU documentation in time for Christmas, we've just been informed that the pending M76 / RS690 specifications will be released by the end of next week. As we mentioned with the RadeonHD 1.1 driver release, this drop will also contain sample code so that DRM work can be underway for the ATI R500 and R600 series.

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

[TechMage89]

Nifty! I can't wait to see it. Maybe I have a chance of being able to help out now. If I have the time :p

[yoshi314]

let's hope they did not rush it too much.

so what exactly is coming this time. 2d only docs?

[bridgman]

There will be three or four different docs this time, depending on how much we get finished. The two easy ones are register specs for M76 and RS690, similar in content to the M56 and RV630 docs already available on x.org/docs. M76 is our internal name for the mobile version of RV630, ie "Radeon Mobility 2600" - the main difference from the RV630 doc already available is that some important blocks (mostly I2C and LVTMA, the second digital output block) are covered in the mobile docs but not in the desktop docs.

I discovered that the desktop docs were missing some important info just before the first document release back in September and replaced the 5xx doc with M56 (M56 is mobile 530 IIRC) but couldn't lay hands on M76 documentation in time so went ahead with the 630 doc instead. Clear as mud ? Anyways, first doc just fills in some gaps on the RV630/M76 registers.

The second doc is for the RS690. This is the integrated chipset whose graphics core often got described as a "Radeon X1200", "X1250" or "X1270". If you look on the amd.com site now we just talk about two chips -- the 690 and 690M (mobile) -- with a couple of variants of each, since they all have the same core albeit at different clock speeds and with some options (HDMI/DVI, sideport memory) not available on the less expensive variants.

OK ? That's the second doc.

The third doc is actually a source release with header files and some embedded documentation. It's a simplified version of the "tcore" driver we use for testing new chips before the silicon is available. The main thing that tcore brings is examples on how to set up the command processors, ring buffers for the engines, including IDCT as well as the 3d engine. It doesn't include shader programming info but it does include things like cache setup and flushing. There is also a basic display driver in the sample code but the current radeonhd driver is already quite a bit more advanced.

The radeonhd devs already have the above info under NDA, btw.

The fourth piece of documentation (which may not be ready in time) is info about 2d acceleration on 6xx. As I have mentioned earlier, the 6xx doesn't include dedicated 2d acceleration hardware but the command processor (cp) emulates most of the 2d commands using precompiled shaders on the 3d engine. The fourth info package will describe how this works and which commands are emulated, along with sample code for setting up the canned shaders and a precompiled shader blob. I expect that we will replace the shader blob with source code when we start pushing out more 3d info.

There was a question on IRC about whether "we would wait until 2d docs were out for all chips before releasing 3d info". Quick answer is no -- a better way to describe it would be that our top priority now is enabling 3d development but we are continuing to push 2d docs out while we are working on 3d.

[teroedni]

Wow thanks for the update Bridgman:)

2008 will be a good Year for Amd and linux thats for sure:D

[mlau]

The third doc is actually a source release with header files and some embedded documentation. It's a simplified version of the "tcore" driver we use for testing new chips before the silicon is available.

Totally OT, but I'm curious as how you test that "driver". I assume you have an array of FPGA's where you load the Verilog model of a particular chip, connected to a windows box, so the driver devs can
have something to play with, although slow?

[puntarenas]

Thanks bridgman, having an AMD employee here on Phronix besides RadeonHD and the effort AMD puts now into fglrx development turned the scales for me.

Although I already ordered a HD3870, there is still one open question about Power Play and maybe you can give me a clue. On techPowerUp (http://www.techpowerup.com/reviews/Sapphire/HD_3870/23.html) I read the following about power management of the RV670:
AMD uses a new form of power management on their RV6xx ASICs called DPM. The GPU independently senses the GPU load and will pick from a set of predefined clocks according to load. Also clock gating is used which turns off unused parts of the silicon and quickly turns them on when they are needed. Unlike the 2D/3D switching on previous ATI cards where the driver manually switched clocks as soon as a 3D fullscreen application is started this process is completely transparent to the software and the driver. This also means that windowed 3D applications will run at the intended performance.

However other reviews tell things still work driver dependent, so if changing power states is still a driver job, does it work with fglrx and will those specifications also become availiable for the RadeonHD team or are these processes completely transparent to the software now?

Thanks in advance
puntarenas

[koolmanoncampus]

The fourth piece of documentation (which may not be ready in time) is info about 2d acceleration on 6xx. As I have mentioned earlier, the 6xx doesn't include dedicated 2d acceleration hardware but the command processor (cp) emulates most of the 2d commands using precompiled shaders on the 3d engine. The fourth info package will describe how this works and which commands are emulated, along with sample code for setting up the canned shaders and a precompiled shader blob. I expect that we will replace the shader blob with source code when we start pushing out more 3d info.


Does 2d on the R500 fall into this category or does it fall into the R300/400 category? (or into its own category)

[bridgman]

Does 2d on the R500 fall into this category or does it fall into the R300/400 category? (or into its own category)

The 5xx family and the RS600/RS690 have the same 2d engine as the R300/400 family, so the 2d acceleration code in the "radeon" driver should work with only minor changes. I believe that 2d acceleration is already running on 5xx parts in the current "radeon" driver, so porting that over to radeonhd shouldn't be a lot of work.

However other reviews tell things still work driver dependent, so if changing power states is still a driver job, does it work with fglrx and will those specifications also become availiable for the RadeonHD team or are these processes completely transparent to the software now?

My understanding is that there is still some driver involvement, but the new HW capabilities on 6xx parts allow faster and more fine-grained power-down than the driver can do on its own so overall power savings can be improved. We will be making this information available to open source developers. In parallel, support is being added (or has been added) to fglrx although I'm not sure of the exact status.

[puntarenas]

Thanks, really good news :)

[Kano]

The news is good, but maybe 1 year too late for buying current cards. Today the only hotfix for ppl with ATI problems is buying another card or lose too many features which would work fine with Win.

[korpenkraxar]

Fantastic to get so much details directly from the AMD/ATi team! Thanx!

I've been fairly grumpy on this forum myself, but fglrx on the Mobile X1400 has really been problematic too. With AMD developers taking part of the discussions around here, I am sure some of the heated arguments (mostly stemming from disappointment and desperation due to lack of information where things are going) will cool down a bit.

Anyways, great news dudes!

[Ze..]

There was a question on IRC about whether "we would wait until 2d docs were out for all chips before releasing 3d info". Quick answer is no -- a better way to describe it would be that our top priority now is enabling 3d development but we are continuing to push 2d docs out while we are working on 3d.
Out of interest what is involved in pushing out these docs? Are you reworking existing internal docs? or making up new documentation from a wide variety of internal sources?

[Mithrandir]

Out of interest what is involved in pushing out these docs? Are you reworking existing internal docs? or making up new documentation from a wide variety of internal sources?

As I've understood fglrx developers use the same specs, but they need to be sanitized.

[bridgman]

For the initial doc release (and some of the next round of docs) I was able to find existing docs which were a good starting point. We basically read through them, pulled out any sensitive DRM-related stuff, and replaced all the scary NDA/confidentiality notices with new wording worked out with our legal folks.

Going forward, particularly for 3d, "making up new documentation from a wide variety of internal sources" is probably closer to the mark. We can rely on existing docs for filling in knowledge gaps in older chips but we don't have a "Young Person's Guide to Writing Drivers for the Latest Radeon Chips" document lying around.

[clicks]

Great news, I will definitely reward AMD's open source engagement and it's new open information politic in all my buying decisions in 2008. If you manage to wipe out the last bugs in the Quadcore Systems I will replace some of our office workstations with new AMD/ATI systems.

[Dandel]

The news is good, but maybe 1 year too late for buying current cards. Today the only hotfix for ppl with ATI problems is buying another card or lose too many features which would work fine with Win.

It's not to late for current cards, as more details are released, less and less of the ATI graphics cards are left to trail and error information gathering, just look at how fast the Radeon HD3xxx series was added, it's already at the same level as the Radeon HD2xxx and Radeon X1xxx series... just give it time, and it will progress.

[puntarenas]

I had my hands on a HD3870 for a few hours but it seemed to me Power Play was not working. I had no voltmeter but I could hear the fan was driving faster under Linux with Catalyst 7.12 than under Windows XP, both Idle on the Desktop.

So if you want painless operation with all features working and you need it right now, the news come to late. On the other hand we will see the RadeonHD driver rise and fglrx improve. In a few month it could be a pity not to own a Radeon from a Linux users point of view.

[TechMage89]

It may take a year until total (closed source) support is as good as nvidia. On the the other hand, open source support will likely pass nvidia in the next few months (as soon as 2d and really basic 3d stuff is done.) I'd like to see 2d/EXA get a bit more emphasis, as ati cards are now the only kind that have no (working support). The radeon driver's EXA is massively slow and buggy on my r500 and I'm afraid of being "caught in the gap" between older chips that have EXA working under radeon, and newer chips which will benefit from this doc release and use shaders to emulate it.

Once 3d is working, it likely won't be to hard to patch in glucose acceleration, but I do wonder how long the 3d end will take.

I do want to get a look at the new docs to see if they bring forward anything in my grokking range so that I can help out. The radeonhd code doesn't have any acceleration in it, and the radeon code looks like it needs work and also looks a bit "magicky" in places.

[koolmanoncampus]

Going forward, particularly for 3d, "making up new documentation from a wide variety of internal sources" is probably closer to the mark. We can rely on existing docs for filling in knowledge gaps in older chips but we don't have a "Young Person's Guide to Writing Drivers for the Latest Radeon Chips" document lying around.

After you finish that you guys should write a "How to make your own 3d Radeon Driver For Dummies" book. I predict it being a best seller.

[Michael]

After you finish that you guys should write a "How to make your own 3d Radeon Driver For Dummies" book. I predict it being a best seller.

When they are "finished", there will be a working driver with 2D, 3D, and video playback support. I am not sure how many users at that point would then be interested in writing their "own" driver, plus even with the documentation in hand it still would be very time intensive and require much work.... and lead to fragmentation.

[lucky_]

All of this sounds very sweet, in a few months here will be no reason to buy nvidia for linux desktop.
There is now some reason to delay some shopping, just to wait for the best AMD stuff.
Does anyone have any estimation of how long it could take ?
Few months can be 6 months or 2 years...

Anyway thanks to AMD and to M. Bridgman for his insider point of view, it very nice to see a company involving with the community.

[EmbraceUnity]

All of this sounds very sweet, in a few months here will be no reason to buy nvidia for linux desktop.
There is now some reason to delay some shopping, just to wait for the best AMD stuff.
Does anyone have any estimation of how long it could take ?
Few months can be 6 months or 2 years...

Anyway thanks to AMD and to M. Bridgman for his insider point of view, it very nice to see a company involving with the community.

I was so impressed with AMD recently thanks to what I've seen here that I have invested a bit in the company. Assuming they maintain their interest in Open Source, my next board will definitely be AMD.

[Dandel]

I am looking forward to this dump, because it will not only effect linux but other free operating systems to get better 3d support with newer radeon video cards.

[koolmanoncampus]

When they are "finished", there will be a working driver with 2D, 3D, and video playback support. I am not sure how many users at that point would then be interested in writing their "own" driver, plus even with the documentation in hand it still would be very time intensive and require much work.... and lead to fragmentation.

Naturally... My comment was intended with a pinch of sarcasm.

[Michael]

Naturally... My comment was intended with a pinch of sarcasm.

Ah, okay :)

[bridgman]

This was something we discussed at the start of the project. The conclusion was that (a) since we didn't have all the information in one place, it would probably make more sense to write the document *after* the first driver was written, and (b) as Michael said, once we had the driver the need for the document was questionable.

On the other hand, documentation *could* help new developers to get started working on graphics drivers, but that would be a very different document from one which showed how to take advantage of every aspect of the chip. Right now the graphics driver world seems pretty scary to anyone not already working on drivers, and it would be good if we could do something to "lower the bar" for new people getting started.

My current belief is that a really small driver (smaller and less functional than radeonhd, designed only for experimentation not day-to-day use) might be a better use of time than a standalone document -- what do you think ?

[duby229]

This was something we discussed at the start of the project. The conclusion was that (a) since we didn't have all the information in one place, it would probably make more sense to write the document *after* the first driver was written, and (b) as Michael said, once we had the driver the need for the document was questionable.

On the other hand, documentation *could* help new developers to get started working on graphics drivers, but that would be a very different document from one which showed how to take advantage of every aspect of the chip. Right now the graphics driver world seems pretty scary to anyone not already working on drivers, and it would be good if we could do something to "lower the bar" for new people getting started.

My current belief is that a really small driver (smaller and less functional than radeonhd, designed only for experimentation not day-to-day use) might be a better use of time than a standalone document -- what do you think ?

Mind you, I'm not a programmer, but my take on this would be something along the lines of "what's good for the goose is prolly good for the gander, but not necessarily good for anything else"

I know its a cliche, however it fits in this case. You are already planning on releasing a minimal driver as an example in the next documentation drop. That should be good enough to fill the role of helping new developers get used to driver structure and general design. However a very minimal driver will absolutely not help new developers get anywhere beyond noobs. It'll gve them a taste but that is all it will be able to do.

In the end I believe that nothing less then a small example driver --with-- accompanying documentation will be acceptable. In this case the documentation should --not-- be a direct correlation with the driver, because the driver should be commented appropriately. Instead t should be written independently, but with the same goal as the example driver. So in the end the example driver and the documentation will be two different implementations of the same thing. This I can promise you will be far more effective then either one of these options alone. I believe they are both equally needed.

[bridgman]

No argument there. Only question is whether the documentation should be standalone or embedded in the code. My experience has been that really well documented code is more useful than separate doc & code, but that's just personal experience not fact.

[Michael]

My experience has been that really well documented code is more useful than separate doc & code, but that's just personal experience not fact.

I'd agree with that too.

[duby229]

No argument there. Only question is whether the documentation should be standalone or embedded in the code. My experience has been that really well documented code is more useful than separate doc & code, but that's just personal experience not fact.

I'm not a programmer, but I think that the code should be commented by the programmer that wrote it with the purpose of clarifying the code, and there should also be a separately written documentation in English with the purpose of explaining why drivers are written and structured the way they are.

This should server two purposes. The code will function as an example of proper structure and coding ethics, (which will be explained in the comments) and the documentation should lay down the theory. It's just like school, you have theory classes and lab classes. The theory classes explain the why, and the lab classes explain the how.

In the same vain the documentation should explain why graphics drivers are structured the way they are, and the example driver should be commented to explain how it was structured the way it was.

[bridgman]

Ahh, now I understand. Like you, I'm a big believer in keeping architectural documentation separate from the "as built" documentation which explains the specifics of the code.

The issue here is that the "standalone documentation" in this case would *not* be describing the software architecture and design rationale; instead it would be explaining how to program the chip. That's the only reason I'm thinking embedding the high level docco might be better than a separate doc.

For normal development I agree completely that high level docs & code should be separate.

[duby229]

Ahh, now I understand. Like you, I'm a big believer in keeping architectural documentation separate from the "as built" documentation which explains the specifics of the code.

The issue here is that the "standalone documentation" in this case would *not* be describing the software architecture and design rationale; instead it would be explaining how to program the chip. That's the only reason I'm thinking embedding the high level docco might be better than a separate doc.

For normal development I agree completely that high level docs & code should be separate.

Ok I got ya. I can understand why you'll do it that way

[wiscados]

isn't the week over now...? Has any documentation come?

[Michael]

Today is the start of the week for when it will be released.

[wiscados]

oh..
ah well.. at least we get it, that's what's important...

[olivermcfadden]

I'm very much looking forward to digging through the tcore code and additional
documentation. Keep up the good work AMD and bridgman, we all appreciate it. :-)

[Ze..]

Ahh, now I understand. Like you, I'm a big believer in keeping architectural documentation separate from the "as built" documentation which explains the specifics of the code.

The issue here is that the "standalone documentation" in this case would *not* be describing the software architecture and design rationale; instead it would be explaining how to program the chip. That's the only reason I'm thinking embedding the high level docco might be better than a separate doc.

For normal development I agree completely that high level docs & code should be separate.
The problem with embedding the documentation in the code is that unless you state what is a by product of the hardware and what is a by product of the software it's much harder to rewrite parts of the driver since we won't know what's a limitation of the hardware and what's a limitation of the programmer/driver design.

Clearly documenting when something is a limitation of the hardware and of the software is actually pretty hard and could easily be just as hard as documenting the hardware separately with small snippets of code that just do what is necessary for that section, leaving the driver developer to combine/rewrite those snippets together to form a driver.

Ultimately what a developer wants is a graph of dependencies and requirements , and conceptually their driver will be one of the possible sub-graphs with a specific layout.

[bridgman]

Yeah, I was thinking the same thing. The problem is that the code will be dual-use, ie it will serve as sample (instructional) code but chunks of it will probably be pasted into other drivers.

I'm not worried about discriminating between HW and SW restrictions (we're talking about comments like "register XYZ needs to be set before ABC or the chip hangs") but loading the code up with HW-related comments is great for instructional code but not so good if the code is also being used in a production driver.

I guess this is why "not documenting" seems like the universal solution to so many people ;) ;)

[duby229]

Yeah, I was thinking the same thing. The problem is that the code will be dual-use, ie it will serve as sample (instructional) code but chunks of it will probably be pasted into other drivers.

I'm not worried about discriminating between HW and SW restrictions (we're talking about comments like "register XYZ needs to be set before ABC or the chip hangs") but loading the code up with HW-related comments is great for instructional code but not so good if the code is also being used in a production driver.

I guess this is why "not documenting" seems like the universal solution to so many people ;) ;)

Well, All I can say s thank you for all your efforts. I know that in many cases it may seem like a thankless trivial job. But in this case, "You be da man, man!!"

Keep up the great work and any way that it gets implemented is better then nothing at all.

[Svartalf]

I guess this is why "not documenting" seems like the universal solution to so many people ;) ;)

Yanno...

I've always held the position that you don't need to be band-aiding silicon bugs with driver "fixes". It might be a universal solution, but if you've got a lot of those things you might want to re-think your engineering process and quality process- because you don't have the quality there. I'd consider documenting things something of an accountability thing. If you can hide embarrassing crap with driver cover-ups, then you tend to not care as much on the silicon side with quality- when both software AND hardware honestly need to be much more dead-on than it seems to have been getting lately.

Design flaws are design flaws. You should be striving to AVOID them, not hide them.

But, I suspect I'm a preaching to the choir a bit here, aren't I? >:-) :D

[bridgman]

>>But, I suspect I'm a preaching to the choir a bit here, aren't I? >:-)

Just a bit ;)

[Svartalf]

>>But, I suspect I'm a preaching to the choir a bit here, aren't I? >:-)

Just a bit ;)

Believe me when I say I'm VERY glad that this is the case.

I just wish we'd started this journey with AMD about 6 or so months earlier- we'd be looking at a better picture, I suspect, if we had. Oh, well, it's getting much better each time we see the docs, so I'm not going to gripe TOO much... >:-) :D

[Xemanth]

One thing which I don't understand is that why do we ship code from radeon to radeonhd and from radeonhd to radeon?

Why don't we just migrate these two drivers together ^^ It would be nice easier to select appropriate driver for own use then when you just need to remember to put "ati" as driver =)

I hope that these docs which are going to be released will help my system:
00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10)
01:05.0 VGA compatible controller: ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP]

I miss only two things: dri + power saving :(

[givemesugarr]

One thing which I don't understand is that why do we ship code from radeon to radeonhd and from radeonhd to radeon?

Why don't we just migrate these two drivers together ^^ It would be nice easier to select appropriate driver for own use then when you just need to remember to put "ati" as driver =)

I hope that these docs which are going to be released will help my system:
00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10)
01:05.0 VGA compatible controller: ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP]

I miss only two things: dri + power saving :(

well, the radeonhd is pure code from the documentation and includes some code from the radeon one for things that work in about the same way. the problem is that radeon driver includes a lot of reverse engineered code which in the future won't be needed. then there's another problem with older chips which cannot be supported immediately with a new code driver as radeonhd. it was said here that in the future the oss ati drivers would merge all into one single driver, but for that we'll have to wait one or 2 years if not more.

the next documentation drop won't help your's and mine board... that board (xpress 200m) is quite known and it's reported to both work and not work. it seems that it has a proper soul and intelligence and acts accordingly to what it wants. we could say that ati has created the first artificial intelligence in the world with this board. :D:D

[Michael]

Good morning and happy documentation drop day! :D

[BlackStar]

Awesome! :D

[d2kx]

Good morning and happy documentation drop day! :D

Yarrr! :D That's how we like it!

[Svartalf]

the next documentation drop won't help your's and mine board... that board (xpress 200m) is quite known and it's reported to both work and not work. it seems that it has a proper soul and intelligence and acts accordingly to what it wants. we could say that ati has created the first artificial intelligence in the world with this board. :D:D

I'm more of the opinion that it's a touchy chip- one of those things that Jeff and I were discussing. I suspect that if you don't do things in a just-so manner with it then it won't work correctly. The reason why we see "odd" inconsistent behaviors from person to person is that each person has a different brand of desktop or laptop motherboard and the BIOS variations for start-up are causing...issues...with the driver. I suspect that the Windows driver goes and does a full-on reset of things and does it in the right "just-so" way, and the Linux driver either doesn't or can't do it reliably.

[Michael]

It's out: http://www.phoronix.com/forums/showthread.php?goto=newpost&t=7225

[lakritz]

Yeah, you show em how it's done AMD! =)

[givemesugarr]

I'm more of the opinion that it's a touchy chip- one of those things that Jeff and I were discussing. I suspect that if you don't do things in a just-so manner with it then it won't work correctly. The reason why we see "odd" inconsistent behaviors from person to person is that each person has a different brand of desktop or laptop motherboard and the BIOS variations for start-up are causing...issues...with the driver. I suspect that the Windows driver goes and does a full-on reset of things and does it in the right "just-so" way, and the Linux driver either doesn't or can't do it reliably.

hmmm.... when i was still using windoze the driver would do a black screen during which it might have setting the things properly, but also on that one (the time i switched completely was by 8.40.4) i had problems (watermark and other software stuff) and also random windoze crashes. so i think that the problem stands in the chip's architecture and that, with the presence of so many different brands for its boards, the driver cannot fix everything. i've never seen such awful board. now for some reason i don't have more than 330fps with 100% processor use, while some time ago i had more than 1000, and the things i can do with it are just basic operations. and this was true not only on linux but also for windoze. i could never use for example video editing software or play games or whatever would stress the board and i've come to use just 64mb of ram when i was using the board on windows. on linux i cannot set the memory to more than 128 (no bios setting to do manage it) and i can use only basic functionality. they work in an acceptable way, but if i'd want to use something like compiz or play games or also playing videos with dvd resolution i cannot do it, if not in an unsatisfactory way.
so i think that the problem is not in the drivers but in the chip's core. i should change the pc in some months and i'm waiting to know what does it worth buying: if amd continues the way it has in the last months then i'll definitely chose that brand, but if it starts to break fglrx more and more then i think i'll go with an 8000 serie.

[jc87]

By the way is there any chance that using the specs plus sample code provided by AMD this could lead to improvements on the radeon driver to older versions like the R200 for example?

[Michael]

By the way is there any chance that using the specs plus sample code provided by AMD this could lead to improvements on the radeon driver to older versions like the R200 for example?

Yes, it's been stated that this open support should eventually help some of the older generations.