lkml.org 
[lkml]   [2023]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [Nouveau] [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces
From
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.
>

\
 
 \ /
  Last update: 2023-03-27 00:11    [W:0.252 / U:1.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site