Re: [PATCH] drm/xe: Fix unnecessary host-side population of ttm_tt on non-TT resources
Nathan Bourgeois <[email protected]>
| Newsgroups | org.freedesktop.lists.intel-xe,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAMpTW2eXS9tBzppJvvfZ-FiwoJ5MKOAdB9sqYgCDPVQ_+___ZA@mail.gmail.com> |
> Shouldn't we just be calling xe_bo_validate() here instead of > ttm_tt_populate? (With the correct xe_validation_guard() wrapping). > Yes, this might be a better solution, making ttm_bo_setup_export() > completely unnecessary. If ttm_bo_setup_export() is unnecessary, I'm happy to change the patch or make a new patch. I will attempt to implement and test this locally. > This part looks good as different patch from what I'm assuming will be a > TTM fix. Regarding this, what do you recommend I do, assuming the patch remains local to drm/xe? I'm still learning the ropes of contributing. Nathan On Thu, Aug 20, 2026 at 9:08 PM Dave Airlie <[email protected]> wrote: > > > Yes, this might be a better solution, making ttm_bo_setup_export() > > completely unnecessary. > > > > It's also a bit odd that, in flows where we don't have backing storage > > on export, we populate with pages and charge the system memory cgroup, > > only to move the data to VRAM when the import attach is triggered, > > resulting in a copy and a change in cgroup charging. > > > > I guess the question is why was ttm_bo_setup_export() introduced over > > just a validation at export? > > > > I'd like to think I had an answer for that, but I don't. Likely > because I wasn't thinking about VRAM charging at all, and just > worrying about making sure we had populated some pages for system > memory ones, so the other side couldn't DoS us. > > Dave.