Hi Christian, On 4 January 2017 at 16:02, Christian König <deathsimple@xxxxxxxxxxx> wrote: > Am 04.01.2017 um 16:47 schrieb Rob Clark: >> If the position of the different parts of the buffer are somewhere >> required to be a function of w/h/bpp/etc then I'm not sure if there is >> a strong advantage to treating them as separate BOs.. although I >> suppose it doesn't preclude it either. As far as plumbing it through >> mesa/st, it seems convenient to have a single buffer. (We have kind >> of a hack to deal w/ multi-planar yuv, but I'd rather not propagate >> that.. but I've not thought through those details so much yet.) > > Well I don't want to ruin your day, but there are different requirements > from different hardware. > > For example the UVD engine found in all AMD graphics cards since r600 must > have both planes in a single BO because the memory controller can only > handle a rather small offset between the planes. This is, to a large extent, also true of Intel. > On the other hand I know of embedded MPEG2/H264 decoders where the different > planes must be on different memory channels. In this case I can imagine > you want one BO for each plane, because otherwise the device must stitch > together one buffer object from two different memory regions (of course > possible, but rather ugly). Not just embedded, but quite a few platforms where the ratio of required to available memory bandwidth is ... somewhat different to larger discrete systems. Striping allocations such that luma and chroma live on different memory channels isn't uncommon. But I think this is all orthogonal. If you keep auxiliary planes in separate BOs to metadata, you can still handle both cases. How to place buffers is purely an _allocation_ concern, where single vs. multiple BO is purely about addressing them. So your allocator API may become a little more complex - something which only device-specific userspace will ever address - whilst keeping a unified addressing/handle system for the generic parts of userspace which shouldn't have to care about whether the underlying hardware demands a small offset or a completely separate allocation. Having API pegged to the single-underlying-BO concept has been a giant pain for those who can't use single BOs. I don't see anything good coming of the idea for cross-device/cross-vendor sharing either, since it encodes yet more magic implicit detail into buffer sharing. Since that detail ultimately has to be resolved _somewhere_, it's a problem avoided rather than a problem solved. Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
