If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

AMD Releases Additional R600 GPU Programming Documentation

01-04-2008, 10:50 AM

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.

Comment

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.

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.

Comment

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.

Comment

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.

Comment

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.

Comment

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.

Comment

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.