Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

Michel Dänzer michel at daenzer.net
Fri Jun 30 06:51:15 UTC 2017


On 30/06/17 03:44 PM, Christian König wrote:
> Am 30.06.2017 um 03:36 schrieb Michel Dänzer:
>> On 30/06/17 12:03 AM, Marek Olšák wrote:
>>> On Thu, Jun 29, 2017 at 4:51 PM, Christian König
>>> <deathsimple at vodafone.de> wrote:
>>>> Yeah, I was thinking something similar.
>>>>
>>>> See the intention behind CPU_ACCESS_REQUIRED is to always guarantee
>>>> that CPU
>>>> access is immediately possible.
>>>>
>>>> If you ask me that is not really useful for the UMD and was never
>>>> meant to
>>>> be used by Mesa (only the closed source UMD and some kernel internal
>>>> use
>>>> cases).
>>>>
>>>> I would like to keep the behavior in the kernel driver as it is, but we
>>>> should really stop using this as a hint in Mesa.
>> So we'd have a flag in the userspace ABI which is only used by closed
>> source userspace, and which can be used to artificially create pressure
>> on CPU visible VRAM. I know somebody who would argue vehemently against
>> adding something like that. :)
> 
> Yeah, and I really tried hard to prevent that :)
> 
> But unfortunately the milk is already spilled, so not much we can do
> about that.

Right, sorry I didn't realize this issue when we added this flag.


>> What does the closed source UMD use the flag for?
> 
> Well it doesn't use the flag, but it has the concept of separate heaps
> for visible and invisible VRAM and maps that to setting the flag
> appropriately.

That doesn't require the strict semantics you're defending. John has
proven with a lot of hard work that the looser semantics work out better
in general.


> But putting the closed source UMD asside, my primary concern is rather
> in kernel users of the flag.

We can deal with that internally in the kernel, while fixing the
existing flag for userspace.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer


More information about the amd-gfx mailing list