On Tue, Nov 16, 2021 at 10:09:44AM +0100, Christian König wrote: > Am 16.11.21 um 10:00 schrieb Thomas Hellström: > > On 11/16/21 09:54, Christian König wrote: > > > Am 16.11.21 um 09:33 schrieb Thomas Hellström: > > > > On 11/16/21 09:20, Christian König wrote: > > > > > Am 16.11.21 um 08:43 schrieb Thomas Hellström: > > > > > > On 11/16/21 08:19, Christian König wrote: > > > > > > > [SNIP] > > > > > > > > > > Well my long term plan is to audit the code base once more > > > > > and remove the limbo state from the SYSTEM domain. > > > > > > > > > > E.g. instead of a SYSTEM BO without pages you allocate a BO > > > > > without a resource in general which is now possible since > > > > > bo->resource is a pointer. > > > > > > > > > > This would still allow us to allocate "empty shell" BOs. But > > > > > a validation of those BOs doesn't cause a move, but rather > > > > > just allocates the resource for the first time. > > > > > > > > > > The problem so far was just that we access bo->resource way > > > > > to often without checking it. > > > > > > > > So the driver would then at least need to be aware of these > > > > empty shell bos without resource for their move callbacks? > > > > (Again thinking of the move from empty shell -> VRAM). > > > > > > My thinking goes more into the direction that this looks like a BO > > > directly allocated in VRAM to the driver. > > > > > > We could of course also make it a move, but of hand I don't see a > > > reason for it. > > > > As long as there is a way to provide accelerated VRAM clearing if > > necessary the directly allocated view sounds fine with me. (Looking at > > amdgpu it looks like you clear on resource destroy? I'm not fully sure > > that would work with all i915 use cases) > > In amdgpu we have both. The AMDGPU_GEM_CREATE_VRAM_CLEARED flag clears the > memory on allocation and AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE flag makes > sure it is wiped on release. btw how does this work when there was random previous stuff in that memory region previously? Like the more we do hmm style integration the more you cannot assume that critical memory is cleared on free/release, because that's just not how core mm/ works, where pages are all cleared on alloc before userspace sees them. Entirely sidetrack discussion :-) -Daniel > Wiping on release is sometimes faster because you don't need to wait for the > clear to finish before you can first use it. > > But thinking about it once more it might be a good idea to have move > callbacks for empty shells and freshly allocated BOs as well, so that the > driver is informed about the state change of the BO. > > Regards, > Christian. > > > > > /Thomas > > > > > > > > > > Christian. > > > > > > > > > > > Thanks, > > > > > > > > /Thomas > > > > > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
