Unix Device Memory Allocation project

[Rob Clark]

On Wed, Jan 4, 2017 at 9:54 AM, Daniel Vetter <daniel at ffwll.ch> 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 at fooishbar.org> 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