Messages in this thread | | | Date | Mon, 13 Nov 2023 08:22:18 +0100 | Subject | Re: [PATCH drm-misc-next v8 09/12] drm/gpuvm: reference count drm_gpuvm structures | From | Christian König <> |
| |
Am 10.11.23 um 17:57 schrieb Danilo Krummrich: > On 11/10/23 09:50, Christian König wrote: >> [SNIP] >>>> >>>>> >>>>> Another issue Christian brought up is that something intended to >>>>> be embeddable (a base class) shouldn't really have its own >>>>> refcount. I think that's a valid point. If you at some point need >>>>> to derive from multiple such structs each having its own refcount, >>>>> things will start to get weird. One way to resolve that would be >>>>> to have the driver's subclass provide get() and put() ops, and >>>>> export a destructor for the base-class, rather than to have the >>>>> base-class provide the refcount and a destructor ops. >>> >>> GPUVM simply follows the same pattern we have with drm_gem_objects. >>> And I think it makes >>> sense. Why would we want to embed two struct drm_gpuvm in a single >>> driver structure? >> >> Because you need one drm_gpuvm structure for each application using >> the driver? Or am I missing something? > > Right, *one*, but not more than one. Wasn't that the concern? Maybe I > misunderstood something. :)
Well, there is the use case of native context with XEN/KVM. In that situation QEMU opens tons of driver file descriptors on behalves of the virtual environment clients.
In this use case you have many drm_gpuvm instances for a single application. So you can't assume that you only have one VM per PID/TGID or something like that.
AMD already made that mistake with KFD and I strongly suggest not to repeat it :)
Regards, Christian.
| |