On Wed, Jan 4, 2017 at 9:54 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Jan 04, 2017 at 08:06:24AM -0500, Rob Clark wrote: >> On Wed, Jan 4, 2017 at 7:03 AM, Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: >> >> Speaking of compression for display, especially the separate >> >> compression buffer: That should be fully contained in the main DMABUF >> >> and described by the per-BO metadata. Some other drivers want to use a >> >> separate DMABUF for the compression buffer - while that may sound good >> >> in theory, it's not economical for the reason described above. >> > >> > 'Some other drivers want to use a separate DMABUF', or 'some other >> > hardware demands the data be separate'. Same with luma/chroma plane >> > separation. Anyway, it doesn't really matter unless you're sharing >> > render-compression formats across vendors, and AFBC is the only case >> > of that I know of currently. >> >> >> jfwiw, UBWC on newer snapdragons too.. seems like we can share these >> not just between gpu (render to and sample from) and display, but also >> v4l2 decoder/encoder (and maybe camera?) >> >> I *think* we probably can treat the metadata buffers as a separate >> plane.. at least we can for render target and blit src/dst, but not >> 100% sure about sampling from a UBWC buffer.. that might force us to >> have them in a single buffer. > > Conceptually treating them as two planes, and everywhere requiring that > they're allocated from the same BO are orthogonal things. At least that's > our plan with intel render compression last time I understood the current > state ;-) 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.) BR, -R > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
