On Mon, 2009-01-19 at 05:39 -0800, Younes Manton wrote:
> I've been taking a look at VDPAU and how to support it on cards with
> and without hardware support and I have some thoughts. The VDPAU API
> lets the client pass off the entire video bitstream and takes care of
> the rest of the decoding pipeline. This is fine if you have hardware
> that can handle that, but if not you have to do at least parts of it
> in software. Even for MPEG2 most cards don't have hardware to decode
> the bitstream so to support VDPAU there would need to be a software
> fallback. This is probably why Nvidia isn't currently supporting VDPAU
> for pre-NV50 cards.
>
> It seems to me that all of this software fallback business is outside
> the scope of a state tracker. I can see this state tracker getting
> very large and ugly if we have to deal with fallbacks and if anyone
> wants to support fixed function decoding in the future. I think the
> much better solution is to extend Gallium to support a very minimal
> video decoding interface. The idea would be something along the lines
> of:
>
> > picture_desc_mpeg12;
> > picture_desc_h264;
> > picture_desc_vc1;
> > ...
> >
> > pipe_video_context
> > {
> > set_picture_desc(...)
> > render_picture(bitstream, ..., surface)
> > put_picture(src, dst)
> > ...
> > };
> >
> > create_video_pipe(profile, width, height, ...)
>
> The driver would then implement the above any way it chooses. Going
> along with that would be some generic fallback modules like the
> current draw module that can be arranged in a pipeline, to implement
> things like software bitstream decode for various formats, software
> and shader-based IDCT, shader-based mocomp, and colour space conv,
> etc.
>
> An NV50 driver might implement pipe_video_context mostly in hardware,
> along with shader based colour space conv. An NV40 driver for MPEG2
> might instantiate a software bitstream decoder and implement the rest
> in hardware, where as for MPEG4 it might instantiate software
> bitstream and IDCT along with shader-based MC and CSC. As far as I
> know most fixed func decoding HW is single context, so a driver might
> instantiate a software+shader pipeline if another stream is already
> playing and using the HW, or it might use it as a basis for managing
> states and letting DRM arbitrate access from multiple contexts. A
> driver might instantiate a fallback pipeline if it had no hardware
> support for a particular type of video, e.g. Theora. Lots of
> variations are possible.
>
> Having things in the state tracker makes using dedicated hardware or
> supporting VDPAU and others unpleasant and would create a mess going
> forward; many of these decisions should be made by driver-side code
> anyway, which will simplify the state tracker greatly.
>
> Comments would be appreciated.
Younes,
This sounds very close to what we've been investigating for 2d support.
The basic idea is that we'd define a new context struct
(pipe_2d_context, pipe_video_context) that has a set of operations which
are:
1) defined in terms of existing pipe buffer, surface, etc objects
2) abstract a representative slice of current hardware
3) are useful for accelerating the functionality in question
In terms of the 2d context, the abstractions we've talked about can all
be fully accelerated in terms of the existing 3d context, so there are
only two implementation cases that are really interesting:
a) default - shared code maps 2d ops onto 3d context
b) special case - hw has some wierdness that makes default
implementation undesirable, hw just provides its own implementation of
pipe_2d_context.
In terms of video, it sounds like there's more shades of grey where
hardware provides some functionality but not others.
I'd suggest a couple of principles though -- firstly, make sure that
there is enough software support so that hardware with no video
acceleration can just plug in a software implementation of
pipe_video_context, which maps as many operations as possible onto the
3d pipe_context.
>From your description, it sounds like this is what you're proposing,
which makes a lot of sense.
Perhaps the next step would be to flesh out what pipe_video_context
looks like & post it here for comments?
Keith
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
