[Mesa-dev] hardware xvmc video decoding with nouveau

[Younes Manton]

On Fri, Jul 29, 2011 at 8:15 PM, Maarten Lankhorst
<m.b.lankhorst at gmail.com> wrote:
> On 07/30/2011 01:57 AM, Younes Manton wrote:
>> On Fri, Jul 29, 2011 at 7:45 PM, Maarten Lankhorst
>> <m.b.lankhorst at gmail.com> wrote:
>>> On 07/30/2011 01:05 AM, Younes Manton wrote:
>>>> On Fri, Jul 29, 2011 at 6:46 PM, Maarten Lankhorst
>>>> <m.b.lankhorst at gmail.com> wrote:
>>>>>> 2nd patch isn't needed. You shouldn't call vl_video_buffer_create_ex,
>>>>>> you should override the create_buffer hook yourself and do what you
>>>>>> want. I'll push the 1st one later.
>>>>> What create_buffer hook do you mean? If you mean
>>>>> pipe_video_decoder->create_buffer, it creates a pipe_video_decode_buffer,
>>>>> I need to create a pipe_video_buffer.
>>>> pipe_context->create_video_buffer
>>> My current nouveau_video_buffer_create calls vl_video_buffer_create_ex
>>> with an extra flag set to indicate I want a linear resource. If no capable
>>> hardware is found normal resources are used instead. Since I added a
>>> fallback to g3dvl, it made sense to me that I just added an extra flag
>>> during creation instead of copy pasting the video buffer implementation.
>>>
>>> The only thing different between vl_video_buffer and
>>> nouveau_video_buffer_create is that the latter sets
>>> NOUVEAU_RESOURCE_FLAG_LINEAR, rest can be identical.
>> Yeah, I realize that, but look at what struct vl_video_buffer has
>> under the covers, there's a bunch of state related to shader-based
>> decoding. You don't need any of that, what's the point of creating it?
>> Besides, if/when pipe_video_decode_buffer goes away even more
>> shader-specific stuff will end up in vl_video_buffer to bridge the
>> gap. Simply define your own VPE-specific pipe_video_buffer that 1)
>> checks that the requested format is NV12, 2) creates 1 luma resource
>> and 1 chroma resource. For nv50 you can pass the linear flag, for nv40
>> it will also have to pass the linear flag, for nv30 it will need more
>> specialized version to deal with the fact that nv30 doesnt even
>> support linear or regular non-POT textures.
> The problem is that I don't know whether create_buffer is called
> for vdpau or xvmc. If it was just xvmc I'd agree with you, but
> create_video_buffer can be called for vdpau too. I can't
> guarantee that the kernel and the graphics card support PMPEG
> decoding either, in which case I do want to fall back to g3dvl.
>
> pipe_video_buffer should just contain the minimum,
> and all vl_mpeg_ related state should be split off from it.
>
> ~Maarten
>

pipe_video_buffer already contains the minimum, it's just an
interface. However vl_video_buffer_create_ex creates a
*vl_video_buffer* specific to its needs, which is why it makes little
sense to use for a HW decoder. The problem of which what to do with
that hook when you have more than one decoder is separate from that.
The create_video_buffer hook should be part of pipe_video_decoder, not
pipe_context, for exactly this sort of reason. It used to be like that
previously and is something I'll likely be moving back to deal with
this.