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
