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 <[email protected]> wrote: > > > > On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone <[email protected]> > > > > wrote: > > > > > > On Tue, 25 Jun 2019 at 07:26, Simon Ser <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
