Rework TTMs busy handling
Hi guys, so pushed the first few patches from this series. I hope that I correctly managed to resolve the silent Xe merge conflict in drm-tip, but would be nice if somebody could double check. Then for the two remaining patches I've implemented most of what Thomas suggest, e.g. the existing functionality sticks around for eviction and hobs, but ttm_bo_validate will now try to always move things into the non-fallback placements on validation first. What I haven't done yet is to split up the preferred placement since I couldn't immediately see an use case for this, but it's really something we might do in the future as well. Please review and comment, Christian.
Re: Rework TTMs busy handling
On Tue, Jan 16, 2024 at 4:57 AM Christian König wrote: > > Am 12.01.24 um 13:51 schrieb Christian König: > > Hi guys, > > just a gentle ping on this. > > Zack any more comments for the VMWGFX parts? The new vmwgfx code looks great, thanks a lot for implementing it! In fact the entire series looks good to me. For the series: Reviewed-by: Zack Rusin z
Re: Rework TTMs busy handling
Am 12.01.24 um 13:51 schrieb Christian König: Hi guys, just a gentle ping on this. Zack any more comments for the VMWGFX parts? Thanks, Christian. same as the last time. Things I've changed: Implemented the requirements from Zack to correctly fill in the busy placements for VMWGFX. Renamed the placement flags to desired and fallback as suggested by Michel. Rebased on drm-tip instead of drm-misc-next and fixed XE as well. Please review and comment, Christian.
Rework TTMs busy handling
Hi guys, same as the last time. Things I've changed: Implemented the requirements from Zack to correctly fill in the busy placements for VMWGFX. Renamed the placement flags to desired and fallback as suggested by Michel. Rebased on drm-tip instead of drm-misc-next and fixed XE as well. Please review and comment, Christian.
Re: Rework TTMs busy handling
On 2024-01-09 09:34, Christian König wrote: > Am 09.01.24 um 09:14 schrieb Thomas Hellström: >> On Tue, 2024-01-09 at 08:47 +0100, Christian König wrote: >>> >>> I'm trying to make this functionality a bit more useful for years now >>> since we multiple reports that behavior of drivers can be suboptimal >>> when multiple placements be given. >>> >>> So basically instead of hacking around the TTM behavior in the driver >>> once more I've gone ahead and changed the idle/busy placement list >>> into idle/busy placement flags. This not only saves a bunch of code, >>> but also allows setting some placements as fallback which are used if >>> allocating from the preferred ones didn't worked. >> >> I also have some doubts about the naming "idle" vs "busy", since an >> elaborate eviction mechanism would probably at some point want to check >> for gpu idle vs gpu busy, and this might create some confusion moving >> forward for people confusing busy as in memory overcommit with busy as >> in gpu activity. >> >> I can't immediately think of something better, though. > > Yeah, I was wondering about that as well. Especially since I wanted to add > some more flags in the future when for example a bandwidth quota how much > memory can be moved in/out is exceeded. > > Something like phase1, phase2, phase3 etc..., but that's also not very > descriptive either. Maybe something like "desired" vs "fallback"? -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: Rework TTMs busy handling
Am 09.01.24 um 09:14 schrieb Thomas Hellström: Hi, Christian On Tue, 2024-01-09 at 08:47 +0100, Christian König wrote: Hi guys, I'm trying to make this functionality a bit more useful for years now since we multiple reports that behavior of drivers can be suboptimal when multiple placements be given. So basically instead of hacking around the TTM behavior in the driver once more I've gone ahead and changed the idle/busy placement list into idle/busy placement flags. This not only saves a bunch of code, but also allows setting some placements as fallback which are used if allocating from the preferred ones didn't worked. Zack pointed out that some removed VMWGFX code was brought back because of rebasing, fixed in this version. Intel CI seems to be happy with those patches, so any more comments? Looks like Xe changes are missing? (xe is now in drm-tip). I also have some doubts about the naming "idle" vs "busy", since an elaborate eviction mechanism would probably at some point want to check for gpu idle vs gpu busy, and this might create some confusion moving forward for people confusing busy as in memory overcommit with busy as in gpu activity. I can't immediately think of something better, though. Yeah, I was wondering about that as well. Especially since I wanted to add some more flags in the future when for example a bandwidth quota how much memory can be moved in/out is exceeded. Something like phase1, phase2, phase3 etc..., but that's also not very descriptive either. Going to take a look at XE as well, thanks for the notice. Regards, Christian. /Thomas Regards, Christian.
Re: Rework TTMs busy handling
Hi, Christian On Tue, 2024-01-09 at 08:47 +0100, Christian König wrote: > Hi guys, > > I'm trying to make this functionality a bit more useful for years now > since we multiple reports that behavior of drivers can be suboptimal > when multiple placements be given. > > So basically instead of hacking around the TTM behavior in the driver > once more I've gone ahead and changed the idle/busy placement list > into idle/busy placement flags. This not only saves a bunch of code, > but also allows setting some placements as fallback which are used if > allocating from the preferred ones didn't worked. > > Zack pointed out that some removed VMWGFX code was brought back > because > of rebasing, fixed in this version. > > Intel CI seems to be happy with those patches, so any more comments? Looks like Xe changes are missing? (xe is now in drm-tip). I also have some doubts about the naming "idle" vs "busy", since an elaborate eviction mechanism would probably at some point want to check for gpu idle vs gpu busy, and this might create some confusion moving forward for people confusing busy as in memory overcommit with busy as in gpu activity. I can't immediately think of something better, though. /Thomas > > Regards, > Christian. > >
Rework TTMs busy handling
Hi guys, I'm trying to make this functionality a bit more useful for years now since we multiple reports that behavior of drivers can be suboptimal when multiple placements be given. So basically instead of hacking around the TTM behavior in the driver once more I've gone ahead and changed the idle/busy placement list into idle/busy placement flags. This not only saves a bunch of code, but also allows setting some placements as fallback which are used if allocating from the preferred ones didn't worked. Zack pointed out that some removed VMWGFX code was brought back because of rebasing, fixed in this version. Intel CI seems to be happy with those patches, so any more comments? Regards, Christian.
Rework TTMs busy handling
Hi guys, I'm trying to make this functionality a bit more useful for years now since we multiple reports that behavior of drivers can be suboptimal when multiple placements be given. So basically instead of hacking around the TTM behavior in the driver once more I've gone ahead and changed the idle/busy placement list into idle/busy placement flags. This not only saves a bunch of code, but also allows setting some placements as fallback which are used if allocating from the preferred ones didn't worked. Intel CI seems to be happy with those patches, so any more comments? Regards, Christian.
