2011/11/21 Christian König <deathsim...@vodafone.de>: > On 16.11.2011 15:38, Maarten Lankhorst wrote: >> If the decode_bitstream interface is changed to get all bitstream buffers >> at the same time, >> there wouldn't be overhead to doing it like this. For a single picture >> it's supposed to stay constant, >> so for vdpau the sane way would be: set picture parameters for hardware >> (includes EVERYTHING), >> write all bitstream buffers to a hardware bo, wait until magic is done. >> Afaict, there isn't even a sane >> way to only submit partial buffers, so it's just a bunch of overhead for >> me. >> >> nvidia doesn't support va-api, it handles the entire process from picture >> parameters >> to a decoded buffer internally so it always convert the picture parameters >> into >> something the hardware can understand, every frame. > > I'm not arguing against removing the scattered calls to decode_bitstream. I > just don't want to lose information while passing the parameters from the > state tracker down to the driver. But we can also add this information as a > flag to the function later, so on a second thought that seems to be ok. >
I don't have a comment on the rest, but on this part let me point out that it's valid for a VDPAU client to pass you, for a bitstream of size N bytes: * 1 buffer of size N * N buffers of size 1 * any combination in between The only thing you're assured of, as far as I can tell, is that you have a complete picture across all the buffers. So, having the state tracker pass one buffer at a time to the driver can get ugly for everyone if a client decides to chop up the picture bitstream in an arbitrary manner. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev