[Mesa-dev] GBM and the Device Memory Allocator Proposals
nhaehnle at gmail.com
Fri Dec 1 18:34:04 UTC 2017
On 01.12.2017 18:09, Nicolai Hähnle wrote:
>>> As for the actual transition API, I accept that some metadata may be
>>> required, and the metadata probably needs to depend on the memory
>>> which is often vendor-specific. But even linear layouts need some
>>> transitions for caches. We probably need at least some generic
>>> usage" bit.
>> I've started thinking of cached as a capability with a transition.. I
>> think that helps. Maybe it needs to somehow be more specific (ie. if
>> you have two devices both with there own cache with no coherency
>> between the two)
> As I wrote above, I'd prefer not to think of "cached" as a capability at
> least for radeonsi.
> From the desktop perspective, I would say let's ignore caches, the
> drivers know which caches they need to flush to make data visible to
> other devices on the system.
> On the other hand, there are probably SoC cases where non-coherent
> caches are shared between some but not all devices, and in that case
> perhaps we do need to communicate this.
> So perhaps we should have two kinds of "capabilities".
> The first, like framebuffer compression, is a capability of the
> allocated memory layout (because the compression requires a meta
> surface), and devices that expose it may opportunistically use it.
> The second, like caches, is a capability that the device/driver will use
> and you don't get a say in it, but other devices/drivers also don't need
> to be aware of them.
> So then you could theoretically have a system that gives you:
> GPU: FOO/tiled(layout-caps=FOO/cc, dev-caps=FOO/gpu-cache)
> Display: FOO/tiled(layout-caps=FOO/cc)
> Video: FOO/tiled(dev-caps=FOO/vid-cache)
> Camera: FOO/tiled(dev-caps=FOO/vid-cache)
FWIW, I think all that stuff about different caches quite likely
over-complicates things. At the end of each "command submission" of
whichever type of engine, the buffer must be in a state where the kernel
is free to move it around for memory management purposes. This already
puts a big constraint on the kind of (non-coherent) caches that can be
supported anyway, so I wouldn't be surprised if we could get away with a
*much* simpler approach.
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
More information about the mesa-dev