[Mesa-dev] [PATCH] winsys/radeon: Unmap GPU VM address range when destroying BO

[Michel Dänzer]

On 16.06.2015 17:34, Christian König wrote:
> On 16.06.2015 10:28, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daenzer at amd.com>
>>
>> But only when doing so is safe according to the
>> RADEON_INFO_VA_UNMAP_WORKING kernel query.
>>
>> This avoids GPU VM address range conflicts when the BO has other
>> references than the GEM handle being closed, e.g. when the BO is shared.
> 
> That actually doesn't really helps, it just masks the problem for now.
> The other GEM handle could still require the address space just unmapped
> and freed.

In theory, yes. In practice, I think only the Mesa driver actually uses
GPUVM addresses, not the other parts involved in these issues (the Xorg
radeon driver or the Android gralloc). The Mesa driver is careful not to
have several representations of the same BO.

Or do you expect this might cause trouble with GL<->VDPAU or GL<->CL
interop?


> What we would need to really clean that up is to make the VM mappings
> per GEM handle like you suggested or allow multiple mappings per BO like
> we did it for Amdgpu.

What kind of time-frame / effort do you think it would take to get that?


> Another alternative is to teach radeon_bomgr_free_va that a certain
> address range could be allocated to more than one handle.

What exactly do you have in mind for that? I don't think the winsys has
several representations of the same BO in the cases fixed by this patch,
and I'm not sure how it could account for external references.


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