[Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)

[Younes Manton]

2011/6/4 Jose Fonseca <jfonseca at vmware.com>:
> I think we need to have a proper review round of the gallium interfaces, so that we have an interface everybody feels that we can support going forward, which did not happen last round.
>
> That said, I don't think much attention has been given to this branch outside from those working on it. So those with constructive feedback should say now, or "forever hold your peace". Because one way or the other, it doesn't make sense to have useful code on a branch.
>
> Attached is the diff between pipe-video and master for src/gallium/include/*
>
> I need to look more closely at this, but I can't help thinking that the new interfaces are quite different from the rest of gallium's 3d interfaces. Instead of being an extension to gallium 3D interfaces/objects, pipe-video seems more like a completely parallel set of interfaces/objects.
>
> - AFACIT all drivers implement pipe_video context using vl_create_context(pipe_context *). If so then it makes no sense for this to be a gallium interface. It should all be state tracker code.

This is deliberate. All current drivers implement their decoding in
terms of 3D rendering but any driver wanting to implement decoding via
dedicated hardware or other means will implement the interface
directly. That was the motivation for the pipe_video interface, for
drivers to have a suitable first-class interface that wasn't specific
to any one decoding method and for drivers wanting to implement 3D
decoding specifically to be able to share and reuse various modules
that carry out parts of the decoding pipeline via pipe_context.

>
> At very least there are ovious things that need to be fixed:
>
> - get_param / is_format_supported should not be duplicated from screen.

This is also deliberate. Params and surface formats may depend on the
codec/profile/dimensions of the video stream the context was created
to decode. There is not always enough info available in pipe_screen
alone to determine if a particular cap or surface is supported. The
current implementation largely wraps pipe_screen because again it's
using the 3D pipeline and we don't have to deal with funny decoding
hardware constraints.

I haven't kept up with all of the changes Christian has made and I'm
not going to claim the interface as I left it or as it is now is
perfect, but as of now it works on Radeon and semi-works on Nouveau
(for lack of a maintainer) and supports XvMC and VDPAU. The only thing
missing is hardware decoding, which I'm sure will require some
changes, but seeing as how both Radeon and Nvidia decoding hardware
need to be reverse-engineered we can't predict what a perfectly
suitable interface will look like.