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

Younes Manton younes.m at gmail.com
Mon Jun 13 14:18:12 PDT 2011


On Mon, Jun 6, 2011 at 12:52 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 05.06.2011 06:31, schrieb Younes Manton:
>> 2011/6/4 Jose Fonseca <jfonseca at vmware.com>:
>>> 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'm not sure if that's the right answer though, couldn't you just as
> well require a driver to handle all dimensions etc. for a given codec?
> If necessary should just use the shader stages (or cpu...) instead?

That implies that every driver wanting to do HW decoding will also
have to implement 3D decoding. But anyhow, it's really not a question
of falling back. HW decoders will have different caps based on which
codec they're decoding (and sometimes based on how many streams) and
there needs to be a way for a state tracker to get that info.


More information about the mesa-dev mailing list