Unix Device Memory Allocation project

[Christian König]

Am 04.01.2017 um 16:47 schrieb 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.)

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.

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 that 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).

So if we want to cover everything we essentially need to support all 
variants of one plane per BO as well as all planes in one BO with 
DMA-Buf. A bit tricky isn't it?

Regards,
Christian.

>
> BR,
> -R
>
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel