On 30/06/17 08:43 PM, Marek Olšák wrote:
>
> I don't know what is being talked about here anymore, but I wouldn't
> like to use CPU_ACCESS_REQUIRED or CPU_ACCESS_REALLY_REQUIRED in
> userspace. The reason is that userspace doesn't and can't know whether
> CPU access will be required, and the frequency at which it will be
> required. 3 heaps {no CPU access, no flag, CPU access required} are
> too many. Userspace mostly doesn't use the "no flag" heap for VRAM. It
> uses "CPU access required" for almost everything except tiled
> textures, which use "no CPU access".
FWIW, the difference between setting CPU_ACCESS_REQUIRED and not setting
it for a BO created in VRAM will be: If it's set, the BO is initially
created in CPU visible VRAM, otherwise it's most likely created in CPU
invisible VRAM.
If userspace knows that a BO will likely be accessed by the CPU first,
setting the flag could save a move from CPU invisible to CPU visible
VRAM when the CPU access happens. Conversely, if a BO will likely never
be accessed by the CPU, not setting the flag may reduce pressure on CPU
visible VRAM.
Not sure radeonsi can make this distinction though.
> I've been trying to trim down the number of heaps. So far, I have:
> - VRAM_NO_CPU_ACCESS (implies WC)
> - VRAM (implies WC)
> - VRAM_GTT (combined, implies WC)
Is this useful? It means:
* The BO may be created in VRAM, or if there's no space, in GTT.
* Once the BO is in GTT for any reason, it will never go back to VRAM.
Such BOs will tend to end up in GTT after some time, at the latest after
suspend/resume.
I think it would be better for radeonsi to choose either VRAM or GTT as
the preferred domain, and let the kernel handle it.
> - GTT_WC
> - GTT
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
