AMD Releases R600/700 3D Documentation

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

[mirza]

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

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

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

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

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

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

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

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

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

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?