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