AMD Releases Additional R600 GPU Programming Documentation

[phoronix]

Phoronix: AMD Releases Additional R600 GPU Programming Documentation

In the second NDA-free documentation dump, AMD has just released programming data on the M76 and RS690 graphics processors. While the RadeonHD developers have already had these documents, this information will help the free software community in understanding the internal workings of AMD's graphics processors. In this article, we have information on this just-released data as well as what else the community can expect in the way of documentation in the near future.

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

[yoshi314]

sweet. it just can't get any better. unless ati releases more docs ;)

AMD will be open-sourcing part of their new proprietary OpenGL driver and will be in a state so that it can be patched into the existing R300+ Mesa driver.does that mean that we can get new fglrx opengl core on top of mesa, or only the opensourced part of it, whatever it is?

Next week AMD will likely be making a mirror of the data on their website.finally. i was afraid that xorg site might go down again, like the last time ;-)

[givemesugarr]

Phoronix: AMD Releases Additional R600 GPU Programming Documentation

In the second NDA-free documentation dump, AMD has just released programming data on the M76 and RS690 graphics processors. While the RadeonHD developers have already had these documents, this information will help the free software community in understanding the internal workings of AMD's graphics processors. In this article, we have information on this just-released data as well as what else the community can expect in the way of documentation in the near future.

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

well, i think that the release was what john told us about in his posts, so there wasn't much surprise, if not for the opensourcing of part of fglrx code. if i remember well this wasn't specified until now, and it's quite a good news to hear. when also the tcore would be ready then maybe we'll see some speedup in the developing process.

does that mean that we can get new fglrx opengl core on top of mesa, or only the opensourced part of it, whatever it is?

on this i think that we'll see the opensourced part in the mesa driver and we'll see fglrx reducing its size and going on top of mesa. but i don't expect it to happen until 2-3 months considering the development cycle we all know about. the issue that makes me worry is the imminent kernel bump which will let us know if the fglrx devs would catch up with the new kernel fast.

[chrisr]

Phoronix: AMD Releases Additional R600 GPU Programming Documentation

In the second NDA-free documentation dump, AMD has just released programming data on the M76 and RS690 graphics processors

OK, so while it's good to see AMD continuing to honour its commitment, there's nothing here for R[1-5]00 owners yet, is there. It's the 2D/3D stuff that we're all craving out here...

[givemesugarr]

OK, so while it's good to see AMD continuing to honour its commitment, there's nothing here for R[1-5]00 owners yet, is there. It's the 2D/3D stuff that we're all craving out here...

r100-200 should already be good and done (at least that's what i've read around).
the opensourcing of fglrx is a good thing for r300-r500 parts.
the issue is that i suspect that the documentation for the r3-400 is full of ndas while the r500 isn't working so bad and it should also benefit from code for the first r600 series at least in the 2d engine. maybe until the end of the year there will be releases for older hw. let's just hope that the docs will arrive for all the boards until the end of the year.

[Svartalf]

r100-200 should already be good and done (at least that's what i've read around).


There's some speed boost still being left on the floor- if they could hand out HyperZ stuff (one of the main pieces missing that we've not been able to figure out cleanly on our own), there'd be a bit more speed left to add to the R100/R200 family. I think there's a few other obnoxious omissions, but the HyperZ would be nice, I think.

[bridgman]

>>It's the 2D/3D stuff that we're all craving out here...

Just wanted to remind everyone that the 2d acceleration on the RS690 and the R5xx family is pretty much unchanged from earlier chips. The 2d acceleration code in the radeon driver is actually running on R5xx parts today.

3d acceleration on RS690 is also unchanged from the 4xx parts other than the lack of vertex shaders.

2d acceleration on R6xx parts and 3d acceleration on 5xx/6xx parts are next on the documentation list.

[chrisr]

To quote one of the Mesa developers:Feel free to open an enhancement bug for reading/writing depth with hyperz, but don't expect anyone to fix it...

[TechMage89]

I think the part of fglrx that will be open-sourced is similar to a Gallium3d driver in that it is an "instruction parser" without a state machine or high level api. This probably makes it appropriate as a starting point for a Gallium3d driver. Bridgman says there are architectural differences that might require substantial work before this will work, but it is nonetheless likely an easier, cleaner process than building a tradition mesa driver. In addition, OpenGL 3.0 support will be able to be added fairly quickly after the spec is finalized because of Gallium3d's modularity.

Bridgman, one question though. I've taken a look at the 2d acceleration bits in the radeon driver, and although XAA does work on my x1600, the code looks incomplete and hacky, and EXA isn't functional (at reasonable speeds) at all. Large parts of XAA aren't accelerated, or only partially so. I'm wondering if there is some original 2d engine documentation I can refer to, because I don't think the radeon driver is using all of the card's functionality.

As for EXA, I'm not sure what's causing the issue, I need to try some performance profiling.

I'd like to get some 2d acceleration working for radeonhd, but without a better source than the radeon driver, I don't think the results will be worth the effort. Ultimately, I expect glucose will be the winner (much simpler, resolves lots of issues) but until there's a fully working 3d engine, I want to try putting together a holdover.

[Berniyh]

on this i think that we'll see the opensourced part in the mesa driver and we'll see fglrx reducing its size and going on top of mesa. but i don't expect it to happen until 2-3 months considering the development cycle we all know about. the issue that makes me worry is the imminent kernel bump which will let us know if the fglrx devs would catch up with the new kernel fast.
I think, that this is (at least partly) already the case since 8.42.3.
Because when I set the opengl profile to xorg-x11/mesa, so it uses libGL.so from mesa and not the one from fglrx, 3D acceleration will still work.

[Kano]

I really hope that the open source drivers will get better soon. But I have doubts if they could ever run gl2benchmark without glitches. fglrx is in a heavy broken state, especially for Xserver 1.4. Since new codebase gl2benchmark test 3/4 do not run and with Xserver 1.4 and 64 bit it just segfaults... 8.40.4 worked btw... Let's see how long it will take to get really good drivers.

[Berniyh]

I really hope that the open source drivers will get better soon. But I have doubts if they could ever run gl2benchmark without glitches. fglrx is in a heavy broken state, especially for Xserver 1.4. Since new codebase gl2benchmark test 3/4 do not run and with Xserver 1.4 and 64 bit it just segfaults... 8.40.4 worked btw... Let's see how long it will take to get really good drivers.
I'm running xorg-server 1.4 + fglrx for slightly over 1,5 months now, without problems. I only had problems with newer xorg-server versions.

[Kano]

try this then (compiled for 32+64 bit):

add this to /etc/apt/sources.list (works with sid too, gutsy/hardy not tested):

deb http://kanotix.com/files/fix/gl2benchmark.lenny ./
deb-src http://kanotix.com/files/fix/gl2benchmark.lenny ./

apt-get update
apt-get install --allow-unauthenticated gl2benchmark

If you have problems you can always do:

apt-get build-dep gl2benchmark
apt-get source -b gl2benchmark

to build it for currently unsupported systems.

[Berniyh]

try this then (compiled for 32+64 bit):

add this to /etc/apt/sources.list (works with sid too, gutsy/hardy not tested):

deb http://kanotix.com/files/fix/gl2benchmark.lenny ./
deb-src http://kanotix.com/files/fix/gl2benchmark.lenny ./

apt-get update
apt-get install --allow-unauthenticated gl2benchmark

If you have problems you can always do:

apt-get build-dep gl2benchmark
apt-get source -b gl2benchmark

to build it for currently unsupported systems.
gl2benchmark won't compile on my Gentoo system.
But actually I don't care about some benchmark, that doesn't run (or whatever it does/doesn't). I care about the apps and games, that I run and I don't have problems with those.
(There are problems, don't get me wrong, though. ;))

[Kano]

It needs openscenegraph 2 as build depend. It is not really a benchmark as it is interactive with mouse movement/button press but also a graphic feature test for correct rendering. New fglrx code base totally ignores point sprites for example. Last test only works correctly in fullscreen mode.

[val-gaav]

>>It's the 2D/3D stuff that we're all craving out here...

Just wanted to remind everyone that the 2d acceleration on the RS690 and the R5xx family is pretty much unchanged from earlier chips. The 2d acceleration code in the radeon driver is actually running on R5xx parts today.

3d acceleration on RS690 is also unchanged from the 4xx parts other than the lack of vertex shaders.

That makes me wonder why there is no (almost complete in functions) open source driver for RS690 uptill now? Parts are more or less ready and what's left is to combine them, so what's stoping the devs ? I mean it could have been done along the reverse engineering of r4xx chips.

and BTW radeonhd is for r5xx r6xx cards if RS690 is so much closer to r4xx then it does make sence to put it into radeon (r2xx r3xx r4xx) driver instead. I'm a bit confused about why it's in the radeonhd dirver now.

[givemesugarr]

That makes me wonder why there is no open source driver for RS690 uptill now? Parts are more or less ready and what's left is to combine them, so what's stoping the devs ?

and BTW radeonhd is for r5xx r6xx cards if RS690 is so much closer to r4xx then it does make sence to put it into radeon (r2xx r3xx r4xx) driver instead ? I'm a bit confused about it now.

well, to put it in simple ways:
- radeonhd is totally developed from the source with the addition of some working code from radeon parts.
- radeon code has been written in its majority from reverse engineering the old fglrx code.

the thing that board are similar doesn't imply that they're the same and john pointed out some differences. the main problem is that radeonhd is developed entirely on the new r600 series and works with some older r500 that are similar to the r600. the radeonhd could work also on other chips but the devs don't know about it since they never tried testing it on r300 or 400 for example. but for the moment it's likely that it won't work on these boards without harm.
the radeon branch instead is working for boards till r500 and is adding various support for newer features and boards. it's known that with time we'll have just one driver but for now the 2 codes from the 2 drivers are different and until the radeonhd doesn't finishes its code for the new boards i don't think that it will converge into the radeon, while the radeon branch will continue to increase its features, stability and speed for the older cards also through utilities from radeonhd and specs from amd and one day it will absorb radeonhd, but i don't see this happening this year.

[highlandsun]

What about MPEG2 acceleration? Some of us don't give a damn about gaming or 3D effects, but faster video decoding would be nice...

[airlied]

Bridgman, one question though. I've taken a look at the 2d acceleration bits in the radeon driver, and although XAA does work on my x1600, the code looks incomplete and hacky, and EXA isn't functional (at reasonable speeds) at all. Large parts of XAA aren't accelerated, or only partially so. I'm wondering if there is some original 2d engine documentation I can refer to, because I don't think the radeon driver is using all of the card's functionality.

As for EXA, I'm not sure what's causing the issue, I need to try some performance profiling.



What do you mean looks incomplete and hacky? I assume you are basing this on your years of experience writing XAA/EXA drivers? or just on the fact that you can't understand the codepaths?

XAA is functionally complete in that it provides accel for anything it can.

EXA is still a work in progress and the missing bit is Composite support which actually requires using the 3D engine not the 2D engine. We only support Composite on r100/r200 so far and I'd like to add r300 support at some point. R500 needs some info on the fragment shader pipeline to happen.

XAA also has some support for composite operations but we might not bother implementing that (maybe someone will, they mainly make gnome-terminal go faster).

Really EXA isn't a great final solution as-is, we require a unified memory manager like TTM to really make it shine. Otherwise we end up with the current texture/pixmap VRAM split etc...

[airlied]

That makes me wonder why there is no (almost complete in functions) open source driver for RS690 uptill now? Parts are more or less ready and what's left is to combine them, so what's stoping the devs ? I mean it could have been done along the reverse engineering of r4xx chips.

and BTW radeonhd is for r5xx r6xx cards if RS690 is so much closer to r4xx then it does make sence to put it into radeon (r2xx r3xx r4xx) driver instead. I'm a bit confused about why it's in the radeonhd dirver now.


rs690 modesetting is the same as the r500 parts, so it needs atombios or radeonhd support to set modes. the 3D engine is like the 3D engine on rs480, but there is also a large chunk of work just programming the memory controller on these chips. Setting up the memory controller is tricky (maybe atombios will make it easier).

Once the memory controller is working, the current Mesa r300 driver should work on top of it all fine, however the current Mesa r300 driver doesn't fully support "vertex shader"-less cards, googleearth and many games work, compiz however has resisted fixing, I'd hope to remedy this situation since I wrote the current "vertex shader"-less codepaths, but time as ever is the enemy.

[Ze..]

2d acceleration on R6xx parts and 3d acceleration on 5xx/6xx parts are next on the documentation list.
Excellent.

It'll be good to see how this evolves. I'm actually quite interested in seeing how it all happens. When I get more time I think I'll start contributing to the driver (even though ewwww plain old c :p)

[bridgman]

Bridgman, one question though. I've taken a look at the 2d acceleration bits in the radeon driver, and although XAA does work on my x1600, the code looks incomplete and hacky, and EXA isn't functional (at reasonable speeds) at all. Large parts of XAA aren't accelerated, or only partially so. I'm wondering if there is some original 2d engine documentation I can refer to, because I don't think the radeon driver is using all of the card's functionality.

As for EXA, I'm not sure what's causing the issue, I need to try some performance profiling.

The manual that came with the R200 info seemed pretty good and gives a pretty good intro to programming the parts. I'm going to try to re-release that some time soon. I was flipping through it over the weekend (while ice fishing ;)) trying to figure out how much work it would take to bring it up to date for 5xx if not 6xx.

re: EXA, there seems to be some agreement that EXA may need better memory management to work well. I'm not 100% sure of that but it does seem likely.

re: XAA, I have been told by a couple of devs that a lot of the benefit comes from accelerating just a few functions. At XDS there was some talk about mismatches between the current 2d acceleration APIs and the functions which are actually used heavily -- I think the comment was "XAA accelerates all the stuff that nobody uses any more".

[Svartalf]

What do you mean looks incomplete and hacky?

Yow... Guess you told him Dave. :D Good to see you around here- *I* don't think the work's hacky or kludgy. :D

[Svartalf]

When I get more time I think I'll start contributing to the driver (even though ewwww plain old c :p)

What's wrong with a bit of "C" coding? C++ is nice, but it's got some small issues in it's use with drivers. To be sure, it's not as bad as some make it out to be, but it's easier in some ways to do very, very brain-dead things in C++ when you're talking about code for the driver space on an OS- which is a part of why the Linux kernel crowd vehemently oppose the use thereof.

As it stands, I've got a couple of things to get off my plate before I can consider doing some stuff- but it's on my shorter list of things to do. :D

[TechMage89]

Ok, ok, maybe the language I used was a little too strong, especially given the fact I don't have a lot of experience with C, but when I see lots of comments like "we can't fully accelerate this operation" or "someone needs to find a better way to do this" I do begin to suspect that the code needs some work. (those are rough quotes, I haven't got the code in front of me)

Granted, maybe the operations aren't that important, so no one thought them worth the effort to fix, but I'm afraid I'm a bit of a perfectionist :p.

Also, I'm not entirely sure what's a silicon problem and what's a coding problem (mainly because I haven't got the docs.)

I'm an object-oriented programmer by training, so when I try to understand a large amount of code, I try to compartmentalize things, but that doesn't seem to work too well on the radeon driver.

Maybe I've bitten off a bit more than I can chew and should just go back to application programming :p.

At any rate, I regarding EXA, I don't just mean that the performance isn't that good on my card, I mean it's unusable.

[agd5f]

The radeon ddx was written with documentation or directly from ati code drops. Really the only things that were reverse engineered were the XPRESS (RS480) chips and that was more trial and error than reverse engineering. The 3D (mesa) code is another matter. r100 and r200 were written with documentation, r300 (covers r400 as well) was reverse engineered.

The 2D accel code is solid. XAA exposes just about every feature of the 2D engine (fills, blits, image transfers, lines, color expansion, etc.), however, no modern toolkit really uses 2D feature other than fills and blits. As such the only EXA hooks that use the 2D engine are fills, blits, and image transfers. The EXA composite hooks require the 3D engine, so it is a lot more work to get running. We have full support for r100/r200 (in fact it was the HW we used for EXA development since these chips had the best documentation available).

[TechMage89]

My bad, it looks like most of the non-accelerating stuff is trivial. And hardware limited :o

Another thought: if the 2d engine is no longer included in the r600, does using the 3d engine for 2d acceleration reduce performance over older cards? Would 2d performance be better? If so, could the same method also be used for older cards that don't require it (eg. R500)?

[agd5f]

My bad, it looks like most of the non-accelerating stuff is trivial. And hardware limited :o

Another thought: if the 2d engine is no longer included in the r600, does using the 3d engine for 2d acceleration reduce performance over older cards? Would 2d performance be better? If so, could the same method also be used for older cards that don't require it (eg. R500)?

You could use the 3D engine for blits, etc. on any of the older cards, it's just a lot more complicated to program. There's a slight bit more overhead using the 3D engine as more state programming is involved, but it's probably pretty negligible in practice. Plus with modern composited desktops you want to use transforms and blends anyway which are not available on the 2D engine. Those come for free (more or less) when using 3D.

[bridgman]

In general the 3d engine is faster these days. That wasn't always the case a few generations ago.

[chrisr]

There are far simpler programs than Compiz that have trouble with the Mesa R300 driver. Try the "rubik" hack from xscreensaver, for example...

And I'm not sure if this message is trying to warn me of a driver bug or a hardware limitation either:File r300_texstate.c function r300SetTexImages line 301
DXT 3/5 suffers from multitexturing problems!

Has any of the new documentation allowed for the R300 driver to be enhanced further without reverse engineering?

[highlandsun]

What info is needed to implement e.g. XvMC support?

[glisse]

There are far simpler programs than Compiz that have trouble with the Mesa R300 driver. Try the "rubik" hack from xscreensaver, for example...

And I'm not sure if this message is trying to warn me of a driver bug or a hardware limitation either:

Has any of the new documentation allowed for the R300 driver to be enhanced further without reverse engineering?

Well as a programmer who did spend quite bit of time on r300 i would say that current r300 driver is dead end. The code is ugly, wrongly designed and with lot of hack all around. Truly what is needed is a rewrite and i see gallium as an opportunity to do so and do it right from the beginning. Unfortunately we are in a business with short time frame and i am sure more manpower will be put into patching r300 to have somethings working as soon as possible.

Regarding the problem you face the message is pretty explicit: multi-texturing is broken with dxt compressed texture.

[val-gaav]

rs690 modesetting is the same as the r500 parts, so it needs atombios or radeonhd support to set modes. the 3D engine is like the 3D engine on rs480, but there is also a large chunk of work just programming the memory controller on these chips. Setting up the memory controller is tricky (maybe atombios will make it easier).

Once the memory controller is working, the current Mesa r300 driver should work on top of it all fine, however the current Mesa r300 driver doesn't fully support "vertex shader"-less cards, googleearth and many games work, compiz however has resisted fixing, I'd hope to remedy this situation since I wrote the current "vertex shader"-less codepaths, but time as ever is the enemy.

Thanks for the clarification on this. Now I understand why rs690 is in the radeonhd driver.

[bridgman]

What info is needed to implement e.g. XvMC support?

Info on how to set up and use the IDCT/MC hardware. Some of this will be covered in the tcore drop but the bulk of the info will come after we get 3d info out there, since 3d is a pre-requisite for a lot of the video rendering stuff.

[lucky_]

Info on how to set up and use the IDCT/MC hardware. Some of this will be covered in the tcore drop but the bulk of the info will come after we get 3d info out there, since 3d is a pre-requisite for a lot of the video rendering stuff.
Is the schedule of each documentation release, defined by the progress of radeonhd ?
You said that tcore was almost ready to publish but you needed to keep it for some reason.
My questions is do we need to wait for the radeonhd driver to take complete advantage of the doc before a new release of doc happens ?

[yoshi314]

Well as a programmer who did spend quite bit of time on r300 i would say that current r300 driver is dead end. The code is ugly, wrongly designed and with lot of hack all around.well, since this time more documentation will [hopefully] be available, i'd say a total rewrite is not such a bad idea.

i didn't think that the driver is such a mess, though. it "just works" for me all the time.

[bridgman]

Is the schedule of each documentation release, defined by the progress of radeonhd ? You said that tcore was almost ready to publish but you needed to keep it for some reason.
My questions is do we need to wait for the radeonhd driver to take complete advantage of the doc before a new release of doc happens ?

When we are preparing (or, in the case of tcore, sanitizing) information for release we give it to the radeonhd developers when we think it is "pretty much the same as what we are going to release publicly" but before the final review. The final review and cleanup takes a variable amount of time depending on what we find in the review. In the case of tcore we found more references to unreleased ASICs and parts from other non-PC business units than I initially expected so we're still cleaning it up.

This is why I'm not publishing a schedule for documentation releases, just a sequence and a rough idea of when things will happen. Until we actually get deep into the reviews and discussions we don't really know how long each activity will take. Modelling effort requirements (and hence schedule) for documentation cleanup is actually proving to be harder than modelling and scheduling software development, which is another interesting surprise. It's certainly more like modifying a large legacy code base you have never seen before than designing and writing code from scratch.

[chrisr]

Regarding the problem you face the message is pretty explicit: multi-texturing is broken with dxt compressed texture.So is that "broken" as in "It's a bug in the code, and we can fix it", or as in "It's a bug and we don't know how to fix it"? Or maybe "The particular hardware doesn't support that functionality"? Or perhaps even "The hardware should support that functionality, but doesn't for some unknown reason."?

So many possibilities...

[pzad]

So is that "broken" as in "It's a bug in the code, and we can fix it", or as in "It's a bug and we don't know how to fix it"? Or maybe "The particular hardware doesn't support that functionality"? Or perhaps even "The hardware should support that functionality, but doesn't for some unknown reason."?

So many possibilities...

It is r300 driver limitation.

https://bugs.freedesktop.org/show_bug.cgi?id=8056

[highlandsun]

Info on how to set up and use the IDCT/MC hardware. Some of this will be covered in the tcore drop but the bulk of the info will come after we get 3d info out there, since 3d is a pre-requisite for a lot of the video rendering stuff.

Thanks for the response. I'll keep an eye out for those milestones.

[Noboutlifob]

the Best site


I like your site
Thank for your work for us!

Thank you, I will add it to my bookmarks




best regards

Dolly


___________________
earn money on the internet (http://hyip-catalog.com)