[PATCH] drm/ttm: Don't delete the system manager before the delayed delete

Zack Rusin zackr at vmware.com
Mon Sep 20 14:59:41 UTC 2021



> On Sep 20, 2021, at 02:30, Christian König <christian.koenig at amd.com> wrote:
> 
> Am 17.09.21 um 19:53 schrieb Zack Rusin:
>> On some hardware, in particular in virtualized environments, the
>> system memory can be shared with the "hardware". In those cases
>> the BO's allocated through the ttm system manager might be
>> busy during ttm_bo_put which results in them being scheduled
>> for a delayed deletion.
> 
> While the patch itself is probably fine the reasoning here is a clear NAK.
> 
> Buffers in the system domain are not GPU accessible by definition, even in a shared environment and so *must* be idle.

I’m assuming that means they are not allowed to be ever fenced then, yes?

> Otherwise you break quite a number of assumptions in the code.

Are there more assumptions like that or do you mean there’s more places that depend on the assumption that system domain bo’s are always idle? If there’s more assumptions like that in TTM that would be incredibly valuable to know. I haven’t been paying much attention to the kernel code in years and coming back now and looking at a few years old vmwgfx code it’s almost impossible to tell the difference between: “this assumption breaks the driver” and “this driver breaks this assumption”.

z



More information about the dri-devel mailing list