[Mesa-dev] hardware xvmc video decoding with nouveau

Younes Manton younes.m at gmail.com
Fri Jul 29 16:57:12 PDT 2011

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.

More information about the mesa-dev mailing list