[Mesa-dev] GBM and the Device Memory Allocator Proposals

[Nicolai Hähnle]

On 01.12.2017 18:09, Nicolai Hähnle wrote:
[snip]
>>> As for the actual transition API, I accept that some metadata may be
>>> required, and the metadata probably needs to depend on the memory 
>>> layout,
>>> which is often vendor-specific. But even linear layouts need some
>>> transitions for caches. We probably need at least some generic 
>>> "off-device
>>> 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)
[snip]

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.

Cheers,
Nicolai

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.