On Wed, Jul 26, 2017 at 8:15 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > On 26.07.2017 08:29, Michel Dänzer wrote: >> >> On 25/07/17 05:28 PM, Nicolai Hähnle wrote: >>> >>> On 22.07.2017 14:00, Daniel Stone wrote: >>>> >>>> >>>> I don't have any great solution off the top of my head, but I'd be >>>> inclined to bundle stride in with placement. TTBOMK (from having >>>> looked at radv), buffers shared cross-GPU also need to be allocated >>>> from a separate externally-visible memory heap. And at the moment, >>>> lacking placement information at allocation time (at least for EGL >>>> allocations, via DRIImage), that happens via transparent migration at >>>> import time I think. Placement restrictions would probably also >>>> involve communicating base address alignment requirements. >>> >>> >>> Stride isn't really in the same category as placement and base address >>> alignment, though. >>> >>> Placement and base address alignment requirements can apply to all >>> possible texture layouts, while the concept of stride is specific to >>> linear layouts. >> >> >> Also, the starting address of shareable buffers is generally aligned to >> at least the CPU page size anyway. Do we know of any cases requiring >> higher alignment than that, and if so, which address space does the >> requirement apply to? > > > Only tiling modes, as Marek mentioned. We don't do tiling shares across > different GPUs right now. > > Maybe we can do it in the future with gfx9 GPUs. But then the alignment > requirements should be known on both sides based on the tiling mode anyway > -- if they even apply for non-VRAM textures.
We should be able to do some 1D tiling modes. That doesn't have any per sku alignment dependencies. Alex > > >>>> Given that, I'm fairly inclined to punt those until we have the grand >>>> glorious allocator, rather than trying to add it to EGL/GBM >>>> separately. The modifiers stuff was a fairly obvious augmentation - >>>> EGL already had no-modifier format import but no query as to which >>>> formats it would accept, and modifiers are a logical extension of >>>> format - but adding the other restrictions is a bigger step forward. >>> >>> >>> Perhaps a third option would be to encode the required pitch_in_bytes >>> alignment as part of the modifier? >>> >>> So DRI3GetSupportedModifiers would return DRM_FORMAT_MOD_LINEAR_256B >>> when the display GPU is a Raven Ridge. >>> >>> More generally, we could say that fourcc_mod_code(NONE, k) means that >>> the pitch_in_bytes has to be a multiple of 2**k for e.g. k <= 31. Or if >>> you prefer, we could have a stride requirement in elements or pixels >>> instead of bytes. >> >> >> Interesting idea. FWIW, I suspect we'd need to support specifying the >> requirement in both bytes or pixels, since one or the other alone may >> not be sufficient to describe the constraints of all hardware. > > > From what I've seen, modifiers are always specified together with one > specific format, so the bytes-per-pixel are always known, so I don't think > we need both. Specifying it in bytes is a bit more natural for our hardware, > that's all. > > Cheers, > Nicolai > -- > Lerne, wie die Welt wirklich ist, > Aber vergiss niemals, wie sie sein sollte. > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev