On 3 July 2017 at 13:49, Daniel Stone <dan...@fooishbar.org> wrote: > Hey Emil, > > On 3 July 2017 at 13:36, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> Not familiar with the linux-dmabuf protocol - Dan, any ideas if we can >> "get away" w/o using u_vector? > > What would you suggest instead of u_vector? > > When the client connects, for each format, it will receive a series of > 'modifier' events, advertising one modifier supported for that format. > The number of events which will be received for each format is not > known beforehand. I need to later use these as an array of uint64_t, > one per format, to hand to the driver in > DRIImage->createImageWithModifiers(), so the driver can decide which > modifier to use. > > Given that, what would you use instead? My understanding of u_vector > vs. u_dynarray is that u_dynarray should be used for dynamic > grow/shrink, and u_vector pretty much just for append-only. I couldn't > find anything else except open-coding my own malloc() / realloc() / > num_elements / array_length implementation, which seemed worse. > Initial train of thought was - there's some guarantee that there won't be more than X unprocessed events. In which case one could simply make it a fixed size array and avoid the (implicit if using u_vector) malloc/realloc.
It sounds like that's not the case, so it's either u_vector or open-coding it. Whichever you and others are happy with. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
