Register XvMC video decoding acceleration

[Michel Dänzer]

On Don, 2011-07-14 at 13:50 +0200, Christian König wrote: 
> Am Donnerstag, den 14.07.2011, 13:23 +0200 schrieb Michel Dänzer:
> > > diff --git a/src/radeon_video.c b/src/radeon_video.c
> > > index 58e3920..edd6d54 100644
> > > --- a/src/radeon_video.c
> > > +++ b/src/radeon_video.c
> > > @@ -315,6 +315,16 @@ void RADEONInitVideo(ScreenPtr pScreen)
> > >      if(num_adaptors)
> > >         xf86XVScreenInit(pScreen, adaptors, num_adaptors);
> > >  
> > > +    if(texturedAdaptor) {
> > > +       XF86MCAdaptorPtr xvmcAdaptor = RADEONCreateAdaptorXvMC(pScreen, texturedAdaptor->name);
> > > +       if(xvmcAdaptor) {
> > > +           if(!xf86XvMCScreenInit(pScreen, 1, &xvmcAdaptor))
> > > +               xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "[XvMC] Failed to initialize extension.\n");
> > > +           else
> > > +               xf86DrvMsg(pScrn->scrnIndex, X_INFO, "[XvMC] Extension initialized.\n");
> > > +       }
> > > +    }
> > > +
> > >      if(newAdaptors)
> > >         free(newAdaptors);
> > >  
> > 
> > Should this only be done under circumstances where the client side XvMC
> > components can actually work? (KMS and >= R300 3D engine?)
> Having textured (non overlay) Xv adapter around is the only prerequisite
> for the server side I have found so far.
> We could add an additional check that's at least an R300+ chipset and
> DRI is available, but KMS isn't a really necessary at all.

Maybe in theory, but in practice it's unlikely that the client side bits
will ever be implemented without Gallium, and that the Gallium bits will
ever work without DRI2. Right?


> > What will happen if this gets initialized but the client side can't
> > work?
> Nothing dangerous, the original idea behind XvMC was to have an
> additionally client side library to decode the video in hardware and
> then render it with Xv to the display but only a minority of the current
> implementation does it this way today.
> 
> Instead we just tell the client to use direct rendering (all callback
> functions inside the XF86MCAdaptorRec are NULL), with this in place the
> client application/wrapper library calls the CreateContext function
> directly and we don't have to worry about mostly anything on the server
> side.
> 
> Then the client side CreateContext function can still tell the
> application that some combination of hardware/codec/parameter isn't
> supported, resulting in a clean fallback to Xv (at least xine does it
> this way).

Okay, then I guess the above doesn't really matter that much for now.
I'll try to give this a spin and push it, unless Alex beats me to it as
usual. :)


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer