AMD Releases R600/700 3D Documentation

[Vighy]

Wow, nice to see people wanting to get involved.

I'm one of those that wasn't born when X was around. (I'm only 20!) I got into this kind of work because AMD put out the r5xx documentation, and at the time my only working computer was an Asus laptop with a Radeon Mobility X1700.

So, being the enterprising entity that I am, I walked into the IRC channel (#radeon on Freenode), and inquired. Turns out that there wasn't really anybody working on it, but there was only one piece of the puzzle missing, so if somebody could write a fragment program compiler for r5xx, it should all just magically work.

So I did. It was not exactly easy; it took me a few months before I came anywhere near actual understanding of the code. I knew C, but I didn't *know* C. But, as I worked, I kept reading code, and reading docs, and bugging airlied and glisse with stupid questions, and eventually, things started to come together.

I'll even dish a few pointers for free. Doing r6xx support on Mesa is kind of silly in my opinion, but Gallium work requires a bunch of experimental pieces, and there's still bugs here and there. If I were to start r6xx drivers today, I'd start by getting a mug of hot chocolate and sitting down with the r6xx docs, and read those front to back a few times.

~ C.

If I had time to devolve to this, I would certainly do the same.

How much did you worked on it per day?

[tball]

If I had time to devolve to this, I would certainly do the same.

How much did you worked on it per day?

I would like to hear that too. Got a spare time job and Im a student already. But really like to help.

[bugmenot]

Great news! Now the next point should be power management.

I have one question: If there is a developer out there who wants to implement an OpenCL driver for radeon graphics chips, are the necessary docs for that already available?
Would it be possible/make sense to put OpenCL into Gallium3d? Similar to OpenGL.
Thanks!

[TechMage89]

Having an OpenCL state engine for Gallium3D would make the most sense since they do similar things. The main thing you would need to know would be the instruction set for the shader engine (which I think is available.) You can use GEM/TTM for memory management.

[Louise]

I don't think so. Everyone has "announced support" (rah rah !!), but AFAIK nothing has been released yet.

Will the OpenCL implementation on Linux be a kernel module?

Reading the OpenCL announcement I couldn't quite understand if AMD/nVidia/Intel also would be working together on a Linux driver. And if so will it be open source?

If not, who would likely be the ones that would write the driver then?

It would be quite cool if Linux had OpenCL support when Matlab, Mathematica, and Maple have OpenCL support

My bet is, that Mathematica will be the first to support OpenCL. The latest version (7.0) have officially Compiz support

[bridgman]

I expect that any OpenCL implementation would be in userspace, interacting with the GPU through the drm (kernel) module. If you think about it as being "just like OpenGL" you won't be that far off.

All of the participating companies worked together on the spec but I am not aware of any plans to work together on the implementation. One of the requirements for OpenCL is the ability to share data with OpenGL, which more-or-less requires that the OpenCL implementation be tied to the OpenGL implementation for that specific GPU family.

I haven't heard about any plans to implement an open source OpenCL implementation yet; presumably if one were to be created it would be based on or work with the Mesa OpenGL driver because of the need for OpenCL/OpenGL data sharing. A am starting to wonder if it would be worth doing an initial OpenCL implementation which did not directly support interoperability with OpenGL in order to allow more design options.

TechMage; I agree that implementing over Gallium3D probably makes the most sense; the unknown question is how closely the implementation would need to be integrated with an OpenGL implementation also running over Gallium3D; I suspect that building it around Mesa-over-Gallium3D is the way to go.

bugmenot; AFAIK all necessary information has already been released, including the new double-precision opcodes (in the latest r600isa manual available on the AMD Stream site) :

http://ati.amd.com/technology/stream...g/R600_ISA.pdf

[The_Monkey_King]

<yawn> So now we get what was in the hands of the main developers for months before. I wonder if Mark Shuttlesworth is going to throw some money at this to make it on par or better with nVidia's claim to H.264 standards?

[Louise]

I expect that any OpenCL implementation would be in userspace, interacting with the GPU through the drm (kernel) module. If you think about it as being "just like OpenGL" you won't be that far off.

That makes it a bit easier

All of the participating companies worked together on the spec but I am not aware of any plans to work together on the implementation. One of the requirements for OpenCL is the ability to share data with OpenGL, which more-or-less requires that the OpenCL implementation be tied to the OpenGL implementation for that specific GPU family.

If OpenCL requires data sharing with OpenGL, does that mean that game developers for Windows that use D3D won't be able to use OpenCL in their games?

Or was OpenCL never meant for games, but for scientific number crunching only?

I haven't heard about any plans to implement an open source OpenCL implementation yet; presumably if one were to be created it would be based on or work with the Mesa OpenGL driver because of the need for OpenCL/OpenGL data sharing. A am starting to wonder if it would be worth doing an initial OpenCL implementation which did not directly support interoperability with OpenGL in order to allow more design options.

That is great news for us Linux users, that just want things to work out-of-the-box

AFAIK all necessary information has already been released, including the new double-precision opcodes (in the latest r600isa manaul available on the AMD Stream site) :

http://ati.amd.com/technology/stream...g/R600_ISA.pdf

Cool! So the release of 3D specs for R600/R700 is even bigger news than I though.

I hope Phoronix will keep an eye on the OpenCL development, and write a review once there is news in this feild.

[bridgman]

If OpenCL requires data sharing with OpenGL, does that mean that game developers for Windows that use D3D won't be able to use OpenCL in their games? Or was OpenCL never meant for games, but for scientific number crunching only?

I think it would be fair to say that OpenCL was meant for games, but more for OpenGL games than for DX games

It should be possible to use OpenCL with DX graphics, but the developer would have to pull results back from OpenCL and push them into DX, while OpenCL and OpenGL can share data structures directly.

DX11 will have a similar mechanism, called Compute Shaders. I'm not sure if this feature will be available on DX10 and 10.1 hardware or only on DX11 GPUs. There are strong statements both ways.

I imagine DX game developers will tend to use Compute Shaders while OpenGL game developers will tend to use OpenCL, simply because more of the integration work between physics and graphics will be done for them that way.

[Louise]

I think it would be fair to say that OpenCL was meant for games, but more for OpenGL games than for DX games

Wow! From what I have read it was Apple that was the driving factor behind OpenCL, and then got AMD and nVidia to drop their Close To Metal and CUDA.

So now that I have learned about the data sharing between OpenCL and OpenGL, it makes a lot of sense for Apple to have OpenCL

It should be possible to use OpenCL with DX graphics, but the developer would have to pull results back from OpenCL and push them into DX, while OpenCL and OpenGL can share data structures directly.

Okay, so that is how it will work on Windows. Interesting.

DX11 will have a similar mechanism, called Compute Shaders. I'm not sure if this feature will be available on DX10 and 10.1 hardware or only on DX11 GPUs. There are strong statements both ways.

I imagine DX game developers will tend to use Compute Shaders while OpenGL game developers will tend to use OpenCL, simply because more of the integration work between physics and graphics will be done for them that way.

So that was what John Carmack was talking about in regards to the future of Close To Metal and CUDA for games at QuakeCon 2008.

He said that no one know how it will work out, and what's get laid down by Mircosoft's Direct Computing.

I hope OpenCL is a better API than Compute Shaders, so DX developers will use OpenCL because it is a better API.