[Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

[Lucas Stach]

Hi Daniel, et. al,

Am Dienstag, den 25.06.2019, 16:27 +0100 schrieb Daniel Stone:
> Hi,
> 
> > On Tue, 25 Jun 2019 at 16:07, Jason Ekstrand <jason at jlekstrand.net> wrote:
> > > > On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone <daniel at fooishbar.org> wrote:
> > > > > > On Tue, 25 Jun 2019 at 07:26, Simon Ser <contact at emersion.fr> wrote:
> > > > > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did
> > > > > have usage at first but it was removed during the review. I'm having
> > > > > trouble digging what was the reason for this?
> > > > 
> > > > I'm not sure either. Daniel said it was a mistake.
> > > > 
> > > > Adding the 63bd2ae7452d4 folks to the discussion. Ben, do you remember
> > > > the details?
> > > 
> > > We decided to remove it since we decided that modifiers were a good
> > > enough proxy for usage; no need to pass SCANOUT or TEXTURE anymore,
> > > because we already get the scanout modifiers from KMS and the texture
> > > modifiers from EGL.
> > > 
> > > In hindsight, I think this was a mistake since it only handles buffer
> > > layout, and not buffer placement or cache configuration.
> > 
> > 
> > It's not great but modifiers should be able to handle that as well.  You can have _CONTIGUOUS versions of the modifiers supported by scanout and scanout will only advertise those and the caller has to know to place them in contiguous memory.  That's just an example but I think it would probably work for a lot of the cases.  If not, I'd love to know why not.
> 
> Sometimes it's _CONTIGUOUS, sometimes it's _ON_THIS_PCIE_DEVICE.
> Either way, it does seem like a bit of an abuse: it has nothing to do
> with internal buffer layout, but how and where the backing pages are
> sourced.
> 
> Given that it's completely orthogonal, I wouldn't like to go trying to
> combine it into the same namespace.

If this is about the specifics of the backing store placement, I fear
that a simple uint32_t usage won't get us far at all. It might be able
to cover the most pressing "I really need contig" issue, but it will
break down shortly after this.

At the risk of opening a big can of worms: has anyone thought about
describing the usage as a set of allocator [1]
constraints/capabilities? I feel like those are in a much better
position to actually cover the use-cases you touched above.

Regards,
Lucas

[1] https://gitlab.freedesktop.org/allocator/allocator