AMD Releases R600/700 3D Documentation

[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?

[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

[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

[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.

[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!

[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.

[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?

[alec]

Power management for 6xx/7xx is next on the list, then we're going to see if we can do something to help with video decode acceleration.

Get power management done and I will never look at official catalyst again!

[tball]

I couldn't help registering at phoronix. I have followed thiese forums alot in month by now. Why? Because I am very interested in getting opensource support for my AMD / ATI card.

As a sitenote, I am a student for electronic engineer, 2 ? years left :P But I have a lot of C experience and have worked with several microcontrollers.

So I though I could help with the development? I don't know anything of programming for a gpu, but I could learn it.

So where do we start?

[MostAwesomeDude]

...be a bit easier if some of the main developers publishes something like a task list with a small description of every task (i.e. what it should do, where to start, difficulty etc.)

For classic Mesa: http://dri.freedesktop.org/wiki/R300ToDo

Gallium r300 is just starting. While it's pretty much for experienced devs at the moment, anybody looking to cut their teeth might want to start reading up.

The radeon DDX (xf86-video-ati) needs HDMI audio, EXA, and Xv support for r6xx+ ported from radeonhd and cleaned up.

If you have a specific feature that you're looking for, and it's not too much work, pitch it and it might be possible to add. For example, Xv bicubic shaders for r300-r500 were added by interested volunteers, as were Xv and EXA vsync.