If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Unfortunately Linux puts microcode in a folder called "firmware", which makes things confusing right from the start. The microcode that gets loaded into the chip is a binary image, just like the microcode that is permanently burned into devices. It's part of the hardware block design.

All of the driver code (ie everything that runs on the CPU) is open source. This is the same model as the rest of the graphics drivers.

Okay so everything that can be open sourced IS open sourced. Is the performance of the UVD controlled more by the microcode or by the driver? Meaning: will Catalyst and Radeon have equal decoding / encoding performance for the simple fact they both use the same microcode and the driver is just saying "Hey! Decode this!" and throwing video at UVD. Or does the driver actually have a hand in the decoding / encoding and its performance?

(Asking as much for myself as others, figured this would be a good way to hit up questions others might have)

Good question. The UVD microcode is the same as Linux Catalyst uses and decode performance should be identical, although I expect system-level performance should be better with radeon because the memory manager is more capable. IIRC the driver passes slices to the UVD hardware and gets back decoded images in NV12 format.

All that said, there will probably be issues found as the code gets more widely used and some of those issues could be performance related, but the informal testing done so far suggests that the decode acceleration works pretty well.

Good question. The UVD microcode is identical and decode performance should be identical, although I expect system-level performance should be better with radeon because the memory manager is more capable. IIRC the driver passes slices to the UVD hardware and gets back decoded images in NV12 format.

All that said, there will probably be issues found as the code gets more widely used and some of those issues could be performance related, but the informal testing done so far suggests that the decode acceleration works pretty well.

Does the microcode decide what can be decoded / encoded, with very specific hardware functions that can only do MPEG, h.264 and whatever the last one was? Or does the driver decide what can be decoded / encoded and UVD is basically just a separate, dedicated, processor to not block the 3D engine and use up shaders?

It's really the hardware that determines which formats can be decoded. If there's a tiny change to a video standard then occasionally a microcode update can support it by taking advantage of unused logic in the decode hardware blocks, but that's about it.

You can't add VP8 support to existing UVD hardware, for example.

The main benefit of a dedicated decode acceleration block is offloading the entropy decode step, which is both complex and inherently serial (so not a great fit for shaders). The remaining offload steps (IDCT, filtering etc..) are nice-to-have because it can be done with lower power consumption on dedicated hardware than on CPU or shader core but it's the entropy decode where you get the real benefits of fixed-function hardware.

It's really the hardware that determines which formats can be decoded. If there's a tiny change to a video standard then occasionally a microcode update can support it by taking advantage of unused logic in the decode hardware blocks, but that's about it.

You can't add VP8 support to existing UVD hardware, for example.

The main benefit of a dedicated decode acceleration block is offloading the entropy decode step, which is both complex and inherently serial (so not a great fit for shaders). The remaining offload steps (IDCT, filtering etc..) are nice-to-have because it can be done with lower power consumption on dedicated hardware than on CPU or shader core but it's the entropy decode where you get the real benefits of fixed-function hardware.

2 last questions Bridgman, one general and 1 personally specific.

1) Why VDPAU? I'm not complaining mind you, it'll be nice to have access to all the other VDPAU-enabled software out there. But does this signal AMD giving up on XvBA or....?

2) I've got a 4000 series AMD card in my laptop using radeon, whenever i watch flash videos the temperature sky rockets and the fans drown out the audio. Assuming youtube videos are done in h.264 like I think they are, will this UVD work help to reign in the CPU / GPU usage and stop creating a fire hazard in my bedroom? =P

Is there any chance of integrating this somehow in the Catalyst driver? VDPAU is supported by most video players already while native xvba works only in FernetMenta's Xbmc branch AFAIK.

PS Better let Flash be without acceleration. They are uncapable of delivering anything that works fully.
I had a nvidia 8200 (VDPAU B) and i had tons of issues because of it - blue people on youtube, transparent black areas that wouldnt go away even after the browser was closed, playback speed isues (non-fullscren). Only a handful of videos were working ok-ish. I had to disable hardware support altogether to get rid of it (and i got tearing videos...).