AMD Releases R600/700 3D Documentation

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