>I get the impression that VAAPI is only intended for decoding. VAAPI can be extended to support hardware encode pipelines by passing new types of buffers (that contain control parameters) and surfaces needed by the encoder in a way similar to decode.
Jonathan Bian -----Original Message----- From: Younes Manton [mailto:[EMAIL PROTECTED] Sent: Saturday, June 07, 2008 8:25 AM To: Aaron Whitehouse Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Bian, Jonathan; [email protected] Subject: Re: GPU-assisted Dirac (de)compression Hi. On Sat, Jun 7, 2008 at 3:03 AM, Aaron Whitehouse <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Schrodinger-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
