[Mesa-dev] [PATCH 2/3] xorg/xvmc: Only set decode buffer when available

Younes Manton younes.m at gmail.com
Mon Aug 29 16:44:25 PDT 2011

2011/8/29 Maarten Lankhorst <m.b.lankhorst at gmail.com>:
> Hey,
> On 08/29/2011 10:08 AM, Christian König wrote:
>> Am Montag, den 29.08.2011, 00:36 -0400 schrieb Younes Manton:
>> [snip]
>>> Well, that was what the last discussion was all about, whether or not
>>> decode buffers should be handled internally by each driver or
>>> externally. It was decided to handle it externally, to simplify life
>>> for drivers that want/need multiple buffers and to keep most of the
>>> ugliness in XvMC, since VDPAU and VA don't have the same kinds of
>>> problems.
>>> Anyway, your patch is cleaner for the driver that doesn't want to
>>> support multiple decode buffers, but now every state tracker has to
>>> deal with drivers with decode buffers and drivers without, and we have
>>> to do these if checks at init/cleanup and every frame. The alternative
>>> is that you support create_buffer, etc, and just return the same
>>> decode buffer each time, and if you don't want to bother creating a
>>> new type to represent a decode buffer you can just return anything
>>> non-null, like the decoder itself, and just implement the other
>>> functions as emty no-ops, that way the state trackers only have to
>>> deal with one interface.
>>> Anyway, I don't have a strong preference either way, and since we
>>> currently only have 2 drivers and 2 state trackers, it doesn't matter
>>> much. I'll push this in a couple of days if no other comments.
>> I have implementing the vaapi state tracker on my todo list, but not as
>> with very high priority. So we would end up with 3 state tracker and 2
>> drivers, but honestly my preferences aren't going strongly into the one
>> or another preference either.
>> So I think it is ok to push the patch as it is, since it doesn't make so
>> much of a difference.
> Well I suppose I can just return NULL, and nop the others, it doesn't
> seem like the create call is being error checked?
> ~Maarten

It should be error checked. If you return NULL the state tracker won't
be able to tell if the call failed because of error or because the
driver doesn't support it.

Anyway, pushed. It can always be revisited later.

More information about the mesa-dev mailing list