[Mesa-dev] [PATCH 3/3] vl: replace decode_buffers with auxiliary data field

Christian König deathsimple at vodafone.de
Wed Jan 4 02:42:09 PST 2012


On 03.01.2012 17:03, Maarten Lankhorst wrote:
> Hi Christian,
>
> 2012/1/2 Christian König<deathsimple at vodafone.de>:
>> Hi Maarten,
>>
>> first of all: Happy new Year and sorry for the late reply, have been on
>> vacation for the last week.
>>
>>
>> On 29.12.2011 16:41, Maarten Lankhorst wrote:
>>> Hey Christian,
>>>
>>> Op 26-12-11 14:00, Christian König schreef:
>>>> Based on patches from Maarten Lankhorst<m.b.lankhorst at gmail.com>
>>>>
>>>> Signed-off-by: Christian König<deathsimple at vodafone.de>
>>>>
>>>> diff --git a/src/gallium/include/pipe/p_context.h
>>>> b/src/gallium/include/pipe/p_context.h
>>>> index de79a9b..f7ee522 100644
>>>> --- a/src/gallium/include/pipe/p_context.h
>>>> +++ b/src/gallium/include/pipe/p_context.h
>>>> @@ -410,7 +410,8 @@ struct pipe_context {
>>>>                                                          enum
>>>> pipe_video_profile profile,
>>>>                                                          enum
>>>> pipe_video_entrypoint entrypoint,
>>>>                                                          enum
>>>> pipe_video_chroma_format chroma_format,
>>>> -                                                       unsigned width,
>>>> unsigned height, unsigned max_references );
>>>> +                                                       unsigned width,
>>>> unsigned height, unsigned max_references,
>>>> +                                                       bool
>>>> expect_chunked_decode);
>>>>
>>> I really don't like this part, isn't it implied from entrypoint>=
>>> PIPE_VIDEO_ENTRYPOINT_IDCT?
>> Not necessarily, I'm still trying to give this interface a more general look
>> and feel.
>>
>> So for the current use case it can be deduced from the fact that XvMC only
>> supports entry-points IDCT and MC, while VDPAU only supports bitstream, but
>> that doesn't necessary have to be always the case.
> Even if this is true, it seems like this is a limitation that only
> applies to the shader based decoder. The nouveau pmpeg xvmc
> implementation in mesa doesn't need it at all.
Not really, for UVD I have pretty much the same problem (but for 
different reasons). Also I don't really see a problem in having driver 
specific bits in the interface as long as it doesn't cause problems for 
other drivers.

Christian.


More information about the mesa-dev mailing list