[Mesa-dev] [PATCH 0/3] GBM modifier plumbing

[Daniel Stone]

Hi,

On Mon, 13 Mar 2017 at 7:08 pm, Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Mon, Mar 13, 2017 at 11:53 AM, Kristian H. Kristensen <
> krh at bitplanet.net> wrote:
>
> Daniel Stone <daniel at fooishbar.org> writes:
>
> > I guess it depends on how much asymmetry there is between texture and
> > render formats ... if there isn't much, then we could focus on landing
> > Varad's work and use that as a jumping-off point. I was under the
> > impression that there was a pretty big difference for some hardware,
> > though I guess the GBM implementation would still rank by optimality
> > when allocating ...
>
> Right, but if it's more complicated than what
> EGL_EXT_image_dma_buf_import_modifiers exposes, do really we want to
> that logic into gbm?
>
>
> The GBM API I was thinking of was basically a GBM version of that.  The
> primary addition to the above extension being some set of usage flags.
> There shouldn't be a huge asymmetry between texture and render.  What
> concerns me more is if you tie some other API into EGL that does media or
> something (OpenMAX?) you may run into issues where something works for
> render but not for media decode.  If we don't care about anything other
> than 3D tying into EGL, then the above API should be ok.
>
OK, great. Let's just go with that then; I think any more complicated
multi-device usecases really fall under the allocator domain, and I'd
rather not reinvent that under GBM.

At the moment, the only users we care about are allocating directly for
scanout (so can go through GBM + GetPlane2), or solely for GPU, where EGL
modifiers query + GBM allocation is fine.

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170313/3cd880dc/attachment.html>