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

[Maarten Lankhorst]

Hey Christian,

Op 04-01-12 11:42, Christian König schreef:
> 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.
Ok. I wont block it any more then. Do you have a followup patch to get 
rid of quant matrix and separate reference pictures too? Or should I 
resend it, I kind of lost my rebased git tree, so if you already have 
the followup patches it would be nice if you could post them.

Cheers,
Acked-by: Maarten Lankhorst <m.b.lankhorst at gmail.com>