[Liboil] GPU-assisted Dirac (de)compression

[Younes Manton]

Hi.

On Sat, Jun 7, 2008 at 3:03 AM, Aaron Whitehouse
<lists at whitehouse.org.nz> wrote:
> Hello everybody,
>
> My key question is this:
> What is the optimal way to utilise the GPU to improve
> compression/decompression of Dirac files?
>
> I understand that Schrodinger can use CUDA to utilise the GPU on
> NVidia 8800s. What I am trying to determine is the best overall
> approach to take in order to generally improve Dirac performance on
> all graphics cards (or at least all graphics cards with a Free
> driver).
>
> As far as I can see, the best approach in a perfect world would be:
> 1) Add Dirac support to VAAPI;
> 2) Have all media applications (e.g. GStreamer) support VAAPI;
> 3) Add Dirac VAAPI support to Gallium3D softpipe; and
> 4) Add support for the Dirac VAAPI functions to the various Gallium3D
> hardware drivers (presumably in shader language in order to support
> OpenGL cards?).

I don't know much about Dirac, but for widespread support yeah it
would be better for VAAPI to support it and for media players to
support VAAPI. From what I understand the (inverse) discrete wavelet
transform can be done on a GPU, and most motion compensation schemes
can also be done on the GPU, so it seems like a good fit. Note that
your steps 3&4 aren't quite right, SoftPipe is just a driver, just
like nouveau and other hardware drivers, so if someone implements a
part of VAAPI with gallium it will theoretically work on all drivers.
I just use SoftPipe because it's easy to test with and figure out how
gallium works since it's software based and I can poke around in it
with a debugger.

> It seems that this GSOC would go a long way to sorting this:
> http://www.bitblit.org/gsoc/g3dvl/index.shtml
> http://www.bitblit.org/gsoc/g3dvl/proposal.shtml
> but nothing anywhere mentions Dirac.

Lots of other people have asked me about support for other codecs.
Since GSOC is only a few months and I'm only one person (who knew more
about GPUs than video codecs when he started), I thought it was
reasonable to stick with MPEG2 and XvMC for starters, but a lot of
that code can be applied to VAAPI and other codecs, so I'm optimistic
that VC1, h264, and others will eventually be handled.

> I'm also interested in whether any of this will help encoding (it does
> not sound like VAAPI currently intends to support encoding).

Encoding doesn't make sense on a GPU to be honest with you. The
optimal end-point for GPU processing is the screen, so decoding fits
perfectly, but for encoding we have to make a round trip from CPU to
GPU and back to CPU. I think that would offset most/all speed gains
you might get from having the GPU do the encoding. No clue about CUDA,
but I'm sure it doesn't get around the fundamental problem that the
round trip is sub-optimal. Dedicated encoding hardware is a different
story, but I get the impression that VAAPI is only intended for
decoding.

> Can anybody shed some light on this issue?

Hope that helps,

Younes