Messages in this thread | | | Date | Mon, 6 Feb 2023 19:20:52 +0100 | Subject | Re: [Nouveau] [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces | From | Danilo Krummrich <> |
| |
On 2/6/23 17:14, Christian König wrote: > Concentrating this discussion on a very big misunderstanding first. > > Am 06.02.23 um 14:27 schrieb Danilo Krummrich: >> [SNIP] >> My understanding is that userspace is fully responsible on the parts >> of the GPU VA space it owns. This means that userspace needs to take >> care to *not* ask the kernel to modify mappings that are in use >> currently. > > This is a completely wrong assumption! Take a look at what games like > Forza Horizzon are doing. > > Basically that game allocates a very big sparse area and fills it with > pages from BOs while shaders are accessing it. And yes, as far as I know > this is completely valid behavior.
I also think this is valid behavior. That's not the problem I'm trying to describe. In this case userspace modifies the VA space *intentionally* while shaders are accessing it, because it knows that the shaders can deal with reading 0s.
Just to have it all in place, the example I gave was: - two virtually contiguous buffers A and B - binding 1 mapped to A with BO offset 0 - binding 2 mapped to B with BO offset length(A)
What I did not mention both A and B aren't sparse buffers in this example, although it probably doesn't matter too much.
Since the conditions to do so are given, we merge binding 1 and binding 2 right at the time when binding 2 is requested. To do so a driver might unmap binding 1 for a very short period of time (e.g. to (re-)map the freshly merged binding with a different page size if possible).
From userspace perspective buffer A is ready to use before applying binding 2 to buffer B, hence it would be illegal to touch binding 1 again when userspace asks the kernel to map binding 2 to buffer B.
Besides that I think there is no point in merging between buffers anyway because we'd end up splitting such a merged mapping anyway later on when one of the two buffers is destroyed.
Also, I think the same applies to sparse buffers as well, a mapping within A isn't expected to be re-mapped just because something is mapped to B.
However, in this context I start wondering if re-mapping in the context of merge and split is allowed at all, even within the same sparse buffer (and even with a separate page table for sparse mappings as described in my last mail; shaders would never fault).
> > So you need to be able to handle this case anyway and the approach with > the regions won't help you at all preventing that. > > Regards, > Christian. >
| |