AMD Releases R600/700 3D Documentation

[phoronix]

Phoronix: AMD Releases R600/700 3D Documentation

In late December, AMD had released open-source R600/700 code used to begin supporting 2D and 3D acceleration for the latest ATI graphics processors under Linux using an open-source. This code in its initial form just provided basic but fast 2D acceleration and on the 3D side was only able to draw triangles...

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

[GreatWalrus]

Awesome, I'm excited! Thanks for the news Phoronix.

[bulletxt]

when I say boom boom boom you say bam bam bam!

go amd go go:D

http://it.youtube.com/watch?v=1ldhBBQ_KlM&feature=PlayList&p=4D19DDCA2E8B5BA6&playnext=1&index=1

cheers and lets celebrate with that link song:D

[Melcar]

This is the stuff dreams are made of :). Can't wait.

[hax0r]

Man, can we expect anything similar from nvidia?

[BhaKi]

So NOW R700 becomes capable of BSD. Way to go.

[BlackStar]

Good, good, GOOD!

Powerplay next, pretty please?

Man, can we expect anything similar from nvidia?
We can only hope at this point, but maybe they will take the step if the market pressure increases. This is a wild guess, but the netbook market (Nvidia's Ion) might be the turning point.

[krazy]

fantastic!! :D:D:D

[sylware]

Really those guys really sucks.
Hey! nvidia! Time to wake up! Where are the specs?!

[mirv]

Excellent. I'm no video card driver developer myself, but I do hope this helps those who are. Thankyou AMD!

[curaga]

Phoronix was down for me yesterday evening. Must've been the Phoronix & Slashdot effects combined on this news item :)

[yoshi314]

looks like it's finally time to start saving money for some affordable r600/r700 card in a few months.

[mirza]

So far so good, AMD ! :cool:

[colo]

Thank you, AMD/ATI. I will buy from you again. ;)

[MostAwesomeDude]

Excellent. I'm no video card driver developer myself, but I do hope this helps those who are. Thankyou AMD!

Now's a great time to get involved.

Seriously, though, the current problem is not documentation, it's manpower. While it's great to see the docs out in the open, none of us were waiting on them; we've all got various things on our plates already.

[Michael]

Phoronix was down for me yesterday evening. Must've been the Phoronix & Slashdot effects combined on this news item :)

No, just some server problems earlier in the day :(

[entropy]

Now's a great time to get involved.

Any suggestions on what's the best way to do this?

Where to focus first, etc..

I mean there are a lot of people with good C skills
but kernel/driver design is a completely different story.

[GreatWalrus]

Thank you, AMD/ATI. I will buy from you again. ;)

Me too, I will be upgrading soon. ATI will be on my list again.

[Pfanne]

hell YEAH!

[Loris]

Any suggestions on what's the best way to do this?

Where to focus first, etc..

I mean there are a lot of people with good C skills
but kernel/driver design is a completely different story.

I'm after this, too.

[bridgman]

AFAIK everyone starts by fixing simple bugs which happen to annoy them... ask questions, pick through the code, ask more questions, pick through the code, make a patch, propose it, have someone suggest a better solution, implement that, propose it...

... and suddenly you're an X developer !

[rbmorse]

Someone with skillz could start by updating the wiki

[Loris]

AFAIK everyone starts by fixing simple bugs which happen to annoy them... ask questions, pick through the code, ask more questions, pick through the code, make a patch, propose it, have someone suggest a better solution, implement that, propose it...

... and suddenly you're an X developer !

Nah, I won't fall for it. You mean no studying of obscure ancient knowledge, and no sacrifices under a full moon are involved?

Damn, I hoped for them to be required. :D

[bridgman]

Obscure ancient knowledge is definitely a requirement.

Heck, X has been around long enough to qualify as "ancient" to most people... there's an entire generation of developers who weren't even *born* when X was first introduced.

Sacrifices under a full moon were prohibited by EU regulations a few years ago, but AFAIK there is still a monthly ritual sacrifice of beer instead.

[sundown]

What will be released next, apart from r800?

[bridgman]

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.

[sundown]

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.

Oh yeaaaah... :cool:

[Louise]

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.

Power management is going to be so cool! Get it? :D haha :D

Right now I can play 720p with my AMD64 2GHz and onboard R500, but 1080p is impossible.

Let's say that video decode acceleration isn't implemented, how fast a CPU and how many cores would liekly be needed to play back 720p and 1080p on a onboard R600 with the open source drivers?

[bridgman]

;)

Any of the quad-core processors seem to be able to keep up with H.264 at 1080p, at least with some software decoders. I think CoreAVC (sp ?) was the first to do this.

I believe we have already released enough information to implement both motion comp and the in-loop deblocking filter on shaders. My guess is that implementing those two would reduce the CPU load enough to let a modern dual-core CPU (like yours) handle the remaining work. Won't know for sure until we see it running, of course.

[chaos386]

Not sure about what the minimum is, but my 2.2 GHz C2D laptop can play back 1080p H.264 just fine. AFAIK, none of the open-source video players are multithreaded, either, so the number of cores shouldn't be too important.

[Louise]

;)

It seems that quad-core processors are able to keep up with H.264 at 1080p, at least with some software decoders.

I believe we have already released enough information to implement both motion comp and the in-loop deblocking filter on shaders. My guess is that implementing those two would drop CPU utilizatin enough that a modern dual-core CPU (like yours) could handle the rest. Won't know for sure until we see it running, of course.

It is not something I am proud of, but it is a single core CPU I have :)

But if quad core can handle 1080p, then no problem. AMD's roadmap says that quad core Propus 45Watt 45nm will come in maj 2009, and I read at AMDzone.com yesterday, that AM3 socket quad cores Daneb are roling out in Febuar.

[Louise]

Not sure about what the minimum is, but my 2.2 GHz C2D laptop can play back 1080p H.264 just fine. AFAIK, none of the open-source video players are multithreaded, either, so the number of cores shouldn't be too important.

Strange that no one have taken up the challenge. Shouldn't video decoding be one of those cases that is perfect for multi threading? I.e. scales almost perfect for each extra core.

[bridgman]

I took a quick skim through the forums; looks like the work has been started but is not fully there. It may be that slice-level decoding is working (for video which has multiple slices per frame) but apparently not all encoders make heavy use of slices.

Slices sure seem like the most obvious option for multi-threading and the only one which doesn't involve building and balancing a pipeline.

EDIT - here we go :

FFmpeg supports slice based threading. That means it can use as many threads as the h264 file has slices.

The implications behind that are the following :
- if you didn't create the file you want to play, you don't know whether you'll be able to play it using several threads or not before actually playing it

- recent x264 revisions use a frame based parallelism, and don't support slices anymore, so the main open source provider of h264 stream isn't "thread compatible" with ffmpeg at the present time

- most professionnal encoders use a sliced based approach to encoding. So it's highly probable that you'll be able to decode Apple's trailers, and broadcasted HD videos using both threads.

http://lists.mplayerhq.hu/pipermail/mplayer-users/2007-September/069275.html


In short words, ffmpeg supports multithreading if the video is encoded with multiple slices per frame, so the most common h.264 encoder creates video which can't be multi-threaded on the most common h.264 decoder. Boo ;)

[curaga]

What does the current -lavdopts threads=X do then? In the manpage of mplayer it mentions this option can be used for MPEG-1/2 and H.264 decoding.

[mirza]

Isn't video decoding supposed to be solved in Gallium3D in vendor-independent way? I would like AMD (Intel, Via, ...) to follow nVidia route of creating own video decoding library when there is chance to have something generic that can be reused for all current and future codecs/GPUs.

[mirza]

oh sorry, last sentance is wrong... "I would _not_ like ..."

[bridgman]

Understood. As long as decoding over Gallium continues to work out I think we would want to support that effort rather than creating something new -- the issue is that the existing APIs don't seem to run at the right level to match what we definitely know can be done in the open drivers, so something new *may* be needed anyways.

The existing video-over-Gallium3D work uses XvMC, but that won't handle H.264 or VC-1 without some API changes. There's going to be some iteration involved -- implement something, see what is feasible on a broad range of GPUs, figure out the right API level(s) and whether existing APIs can be used, adjust the implementation, retest etc...

I want to make sure we end up with something that takes full advantage of 780-class shader power, so probably MC + deblocking filter will be about right. Back-of-envelope calculations suggest that 1080p H.264 might need ~8B FLOPS* for MC+deblock and the 780 can crunch maybe 20B FLOPS when not memory-limited, so that seems reasonable.

* you don't really need floating point for video decode but modern GPUs are floating point processors so...

[steefjeqv]

Not sure about what the minimum is, but my 2.2 GHz C2D laptop can play back 1080p H.264 just fine. AFAIK, none of the open-source video players are multithreaded, either, so the number of cores shouldn't be too important.

I think Xine can multithread. You can change the number of threads in the Xine settings.
It uses both cores of my AMD 5000x2. Together with my Sapphire X550 and the latest xorg driver (ati) + ffmpeg, I can now watch 1080i BBC HD. 1080p is not possible.


Greetings,
Steven

[MostAwesomeDude]

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.

[bridgman]

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.

Heck, even we agree with that, but there's a "but..." :D

From a developer's perspective, working in the classic Mesa HW driver model is silly. Nobody feels that more strongly than the devs actually doing the work. From a user perspective, though, it's different -- until all the experimental bits and pieces fetch up in at least a few distros, anything 6xx-ish we do in Gallium is not going to be broadly accessible to them.

The best compromise we could come up with was to get the basic programming sequences worked out in classic Mesa so that users of current distros will have Compiz support, then port the working 6xx code across to Gallium and never look back.

BTW, for anyone not following IRC, not only did MostAwesomeDude implement a lot of the 5xx 3D support (including the shader compiler for ARB_vertex_program and ARB_fragment_program) but he has been working on a Gallium3D implementation for 3xx-5xx and saw the first screen output from that in the last few days.

[tmpdir]

BTW, for anyone not following IRC, not only did MostAwesomeDude implement a lot of the 5xx 3D support (including the shader compiler for ARB_vertex_program and ARB_fragment_program) but he has been working on a Gallium3D implementation for 3xx-5xx and saw the first screen output from that in the last few days.

Respect

Excellent news about the 3D documentation.

[dashcloud]

I took a quick skim through the forums; looks like the work has been started but is not fully there. It may be that slice-level decoding is working (for video which has multiple slices per frame) but apparently not all encoders make heavy use of slices.

Slices sure seem like the most obvious option for multi-threading and the only one which doesn't involve building and balancing a pipeline.

EDIT - here we go :



In short words, ffmpeg supports multithreading if the video is encoded with multiple slices per frame, so the most common h.264 encoder creates video which can't be multi-threaded on the most common h.264 decoder. Boo ;)

I'd just like to add that this is (thankfully) not totally correct: there's an experimental tree that adds frame-level parallelism decoding for mpeg1/2/4 and H264. If you check out http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt you can get that tree. It still needs some work, so if you'd like to see multi-threaded decoding of H264 videos in the main tree, poke the owner of that tree.

If you look on the ffdshow-tryout thread on doom9, you can see some benchmarking numbers for ffmpeg-mt- they're pretty good.

[Louise]

OpenCL haven't been mentioned to decode H264.

Is that because OpenCL isn't good for that?

[bridgman]

OpenCL falls into the same category as Gallium3D, CUDA, or any purely shader-based implementation. It's probably going to be quite good for the back-end part of the decoding pipe (motion comp, filtering), might or might not be good for the middle part of the pipe (inverse quantization, IDCT) depending on the implementation, and probably not good for the start of the pipe (bitstream processing, entropy decoding).

The good news is that the processing at the front of the pipe tends to be easier to do on the CPU than the processing at the end of the pipe, so with luck it will all balance out.

[Ex-Cyber]

Has an OpenCL implementation (even a non-accelerated reference implementation) even been released yet? From my perspective, it looks like that's the biggest barrier to OpenCL work right now - the spec is out, but there doesn't seem to be any way to actually run OpenCL code (unless you're a developer at ATI/Nvidia/Apple). I think that has more to do with the lack of excitement over it than anything about its technical merits.

[bridgman]

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

An unaccelerated reference implementation is a bit tricky because of the interoperability requirements with OpenGL -- you would need to either build it around an existing software OpenGL renderer or hook into the driver stack for a single GPU. Building OpenCL into Mesa would be useful in many ways.

[89c51]

First a big thanks to AMD for the docs and for supporting Open Source

:)

Secondly as stated above people with C skills want to help and don't know where to start. (sadly i fall into the category of people with lower than basic skills when it comes to C :( )

Bridgman proposed a way but wouldn't 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.)

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

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

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

[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 :D

[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/streamcomputing/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 :D


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/streamcomputing/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.

[rbmorse]

John, what do the workstation guys think about OpenCL? Is this something they care about or are they pursuing proprietary solutions?

[bridgman]

I haven't discussed this with them directly but I know that integration of compute and graphics is a big deal for workstation, and that we believe that cross-vendor APIs are the way to go.

[rbmorse]

Fair enough. I need to spend more time with Khronos.

[bridgman]

Appendix 'B' is the interesting part.

[89c51]

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.

is there any date (approximately) that we can expect the docs?

[bridgman]

Not really, we're basically starting one task when we finish the one before, ie the plan is really a sequence not a schedule. If you can live with guesses I would say somewhere between 1 and 3 months for the first 6xx/7xx power management info.

We have already released enough info to do a fair amount of video decode work on all GPUs up to and including the HD4xxx parts; that's really just waiting for a dev with the time, interest and experience to start designing and coding.

Note that current power management work on 5xx is primarily being done in the usermode X driver; while that does offer some benefits, I don't think we are really going to see comparable power savings to fglrx until the open source power management work moves to the kernel. I don't know any devs who are thinking about that right now.

[d2kx]

It seems that MostAwesomeDude has pushed a R300 Gallium3D driver to the gallium-0.2 branch of mesa/mesa. Any information on that?

[Pfanne]

It seems that MostAwesomeDude has pushed a R300 Gallium3D driver to the gallium-0.2 branch of mesa/mesa. Any information on that?

i dont think this is the right thread for this topic ;)

[MostAwesomeDude]

It seems that MostAwesomeDude has pushed a R300 Gallium3D driver to the gallium-0.2 branch of mesa/mesa. Any information on that?

Sure. We agreed on #dri-devel (on IRC) that as long as I wasn't breaking builds, that I could (and should) just keep working on gallium-0.2 instead of in a private repo.

Same warnings as nouveau apply: Developers only, don't file bugs, don't cry when it eats your babies and kills your cat, and don't install it over your system Mesa.

~ C.

[bridgman]

It's the one he's been working on for a few weeks -- Michael posted a quick article around the time the first successful build happened. AFAIK it just does "clear the screen" right now but that still needs a good chunk of the code to be present and working. MostAwesomeDude is working on RV410, I think, but another dev (zhasha) has been making changes for 5xx in parallel.

IMO this is pretty neat, 'cause in parallel we're working on the code required for 6xx/7xx 3D in classic Mesa and hopefully we'll finish that and have it in public around the same time MostAwesomeDude's 3xx-5xx code is running.

[popper]

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/streamcomputing/R600_ISA.pdf

Ohh, well theres a suprise ;) perhaps you can ask
Jason Yang,Christopher Oat, and Justin Hensley how they did that....




what you ask :)




http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=108283&enterthread=y
"That was the demo that we gave when we announced OpenCL support back in December at Siggraph Asia.
"

http://fireuser.com/blog/amd_opencl_parallel_computing_demo_from_siggraph_a sia_2008/

"AMD OpenCL parallel computing demo from Siggraph Asia 2008
Posted by Tony DeYoung on February 03, 2009
The first public demonstration of OpenCL functionality was given by AMD at Siggraph Asia 2008.

OpenCL is the new vendor-independent standard designed to extract high performance parallel computing out of GPUs, DSPs and multicore CPUs.

Basically the idea is that you can write your core computational code in OpenCL and voila! - your code scales to whatever processors are available.

OpenCL will greatly improve speed and responsiveness for a wide spectrum of applications from entertainment to scientific and 3D visualization.

...."

its not clear they were actually running CL on the GFx card or what that might have been, they talk about cores so implying CPU only for this first test code....

[popper]

Not really, we're basically starting one task when we finish the one before, ie the plan is really a sequence not a schedule. If you can live with guesses I would say somewhere between 1 and 3 months for the first 6xx/7xx power management info.

We have already released enough info to do a fair amount of video decode work on all GPUs up to and including the HD4xxx parts; that's really just waiting for a dev with the time, interest and experience to start designing and coding.

Note that current power management work on 5xx is primarily being done in the usermode X driver; while that does offer some benefits, I don't think we are really going to see comparable power savings to fglrx until the open source power management work moves to the kernel. I don't know any devs who are thinking about that right now.

perhaps it might suit some of the C coders here looking to help the ATI efforts in some way.

some tips and links to the right documentation migtht be a good way to get them reading and leaning in the right direction perhaps... some work and learning FUN is better than non after all ;), at least until any UVD review/movement happens....

[bridgman]

Ohh, well theres a suprise ;) perhaps you can ask
Jason Yang,Christopher Oat, and Justin Hensley how they did that....

what you ask :)

http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=108283&enterthread=y
"That was the demo that we gave when we announced OpenCL support back in December at Siggraph Asia. "
<snip>

its not clear they were actually running CL on the GFx card or what that might have been, they talk about cores so implying CPU only for this first test code....

Not sure I understand the question. I suspect everyone involved in the spec creation had OpenCL code running in house before the spec was finalized - we sure did. The code we are running in house is closed source, but my quoted comments were mostly about open source. The first comment (to Louise) was about *all* OpenCL implementations, both open and closed source.

Since I made those comments, Zack posted about TG's plans to release an open source implementation soon (over Gallium as we suspected), once it had passed IP review.

perhaps it might suit some of the C coders here looking to help the ATI efforts in some way. some tips and links to the right documentation migtht be a good way to get them reading and leaning in the right direction perhaps... some work and learning FUN is better than non after all ;), at least until any UVD review/movement happens....

Fair point. The big question for me is which API we should be using - there was some discussion about this at FOSDEM but nothing conclusive. The pros and cons seem to be :

XvMC :
- already supported in the X protocol, so easy to implement in the server (no multi-client drm/dri hassles)
- straightforward to implement for MPEG2 but needs a lot of work to extend for H.264/VC-1 (Via notwithstanding)

VA-API :
- API spec already covers all the formats of interest
- seems to have considered both server-side and direct-rendering implementations
- very few real-world implementations

VDPAU :
- seems to have been conceived as direct-rendering only (not sure what would be involved in a server-side implementation)
- API spec already covers all the formats of interest
- at least one working implementation on commonly available PC hardware

The big issue for me is whether we should be implementing in the X server (which removes a number of potential problems) or as a new, separate direct rendering client. It seems pretty clear that the long-term implementation will be as a direct-rendering client, but for the short term it's not so clear that multiple DRI clients (ie 3D plus the new video driver) can coexist reliably with broadly available drm code.

The good news is that the decision sequence seems pretty simple :

1. does the drm/dri code which is broadly available now (or real soon) support multiple direct rendering clients ?

2. if we reach agreement on a single open source HD video API, can support for that API be added quickly to the X protocol and server ?

3. based on the answers to 1 and 2, which protocol do we go with and do we implement in X or as a dri client ?

There appears to be broad consensus that an agreement has not yet been reached, but that we really need to do so ;)

Once we have that agreement it will be clear where to point developers on the API side. All our docs are in one place already.

[popper]

Not sure I understand the question. I suspect everyone involved in the spec creation had OpenCL code running in house before the spec was finalized - we sure did. The code we are running in house is closed source, but my quoted comments were mostly about open source. The first comment (to Louise) was about *all* OpenCL implementations, both open and closed source.

Since I made those comments, Zack posted about TG's plans to release an open source implementation soon (over Gallium as we suspected), once it had passed IP review.


ohh right, it was just when you said "you were wondering about doing an initial OpenCL implementation which did not directly support interoperability with OpenGL" ,i thought your ATI demo would help people choose the way,its closed inhouse test code though so no matter to the open devs here.

it wasnt so much a question as just bringing the first ever (ATI)OpenCL demo to peoples attention here.

[bridgman]

Got it. Thanks !

[JDorfler]

Seems to me with video formats that there needs to be a standard. A real standard, not a bunch of proprietary, look what I made up standards. Thus for video the CPU could just say, "Hey, this is video, I'll send this to the hardware decoder part of the GPU and send this audio data straight to the audio hardware audio decoder and be done with that. Job done."

This way nVidia and ATI can focus more on speed and power monitoring, instead of just throwing out hardware specks that even they can't figure out how to make work properly with all the different APIs.

A CPU shouldn't have to waist even one cycle on graphics or audio, it should just be decoded on the proper chip.

That's my thought about it. Things are more complicated than they have to be in my opinion.

It's like the advances in hardware are not keeping up in the leaps forword in software bloat.

[bridgman]

It's not a question of figuring out how to make the hardware work with all the different APIs -- most of the APIs support the same set of video formats anyways (XvMC is the exception, unfortunately).

The issue is that video acceleration is not a priority for any of the community devs right now so we're discussing ways of making it easier for new devs to get started. Given the shortage of devs interested in working on video acceleration right now, focusing resources on a single API rather than trying to implement *all* of them seems like a good idea.