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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
