H.264 Video Encoding Interface Added To Gallium3D

[phoronix]

Phoronix: H.264 Video Encoding Interface Added To Gallium3D

Christian K?nig has added an H.264 encoding interface to the general video code for Gallium3D that will ultimately be leveraged by the RadeonSI Gallium3D driver...

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

[MWisBest]

Nice.

On a semi-related note, will the VCE in Trinity and newer APUs be supported? Technically (minus Kaveri of course), they aren't 7000-series GPUs, they're 6000-series (Cayman) GPUs, but they do include VCE from GCN-based GPUs.

[Szzz]

Hardware H.264 encoding, is it actually better than x264?

[sohofrankie]

Hardware H.264 encoding, is it actually better than x264?

I believe that H.264 is the standard and x264 is the opensource implementation that creates H.264 (ie it is a library)

[agd5f]

Nice.

On a semi-related note, will the VCE in Trinity and newer APUs be supported? Technically (minus Kaveri of course), they aren't 7000-series GPUs, they're 6000-series (Cayman) GPUs, but they do include VCE from GCN-based GPUs.

The current code supports VCE 2.0 which is found on Sea Islands parts (bonaire and hawaii dGPUs and kaveri and kabini APUs). VCE 1.0 is found on Southern Islands dGPUs and Trinity and Richland APUs and is not currently supported. We're looking into it. Can't make any promises at this point.

[Raven3x7]

Hardware H.264 encoding, is it actually better than x264?

If you're asking about IQ then it's unlikely. Encoding will likely be significantly faster than on the CPU though.

[twriter]

Encoding will likely be significantly faster than on the CPU though.

And use much less power, which is often more important (on latpops, for example), and free your CPU up for other tasks.

[MWisBest]

The current code supports VCE 2.0 which is found on Sea Islands parts (bonaire and hawaii dGPUs and kaveri and kabini APUs). VCE 1.0 is found on Southern Islands dGPUs and Trinity and Richland APUs and is not currently supported. We're looking into it. Can't make any promises at this point.

I understand it only supports VCE 2.0 at the moment, and that it may or may not ever support VCE 1.0. My question was just that since I keep reading that VCE is only being used by the RadeonSI driver, but the Trinity and Richland APUs don't use that driver as they are technically Northern Islands GPUs (Cayman/VLIW4 to be exact) and not Southern Islands GPUs, and http://xorg.freedesktop.org/wiki/RadeonFeature/ lists VCE as "N/A" under Northern Islands, so I'm wondering even if VCE 1.0 is supported, will it require more code/work to support the Trinity and Richland APUs?

I'll try and condense that...
Even if VCE 1.0 gets supported, will that also work on Trinity and Richland APUs, even though they aren't Southern Islands let alone GCN-based GPUs?

[smitty3268]

I understand it only supports VCE 2.0 at the moment, and that it may or may not ever support VCE 1.0. My question was just that since I keep reading that VCE is only being used by the RadeonSI driver, but the Trinity and Richland APUs don't use that driver as they are technically Northern Islands GPUs (Cayman/VLIW4 to be exact) and not Southern Islands GPUs, and http://xorg.freedesktop.org/wiki/RadeonFeature/ lists VCE as "N/A" under Northern Islands, so I'm wondering even if VCE 1.0 is supported, will it require more code/work to support the Trinity and Richland APUs?

I'll try and condense that...
Even if VCE 1.0 gets supported, will that also work on Trinity and Richland APUs, even though they aren't Southern Islands let alone GCN-based GPUs?

It will take a little bit of code in r600g just to make sure everything gets linked together correctly, but that kind of glue should be mostly trivial.

So yes, it shouldn't be an issue.

[twriter]

Even if VCE 1.0 gets supported, will that also work on Trinity and Richland APUs...?

We have it working on Trinity now but we don't know if/when we'll be able to release it.