On 6/14/23 09:58, Donald Robson wrote:
On Tue, 2023-06-13 at 16:20 +0200, Danilo Krummrich wrote:
I'm definitely up improving the existing documentation. Anything in
particular you think should be described in more detail?
- Danilo
Hi Danilo,
As I said, with inexperience it's possible I missed what I was
looking for in the existing documentation, which is highly detailed
in regard to how it deals with operations, but usage was where I fell
down.
If I understand there are three ways to use this, which are:
1) Using drm_gpuva_insert() and drm_gpuva_remove() directly using
stack va objects.
What do you mean with stack va objects?
2) Using drm_gpuva_insert() and drm_gpuva_remove() in a callback
context, after having created ops lists using
drm_gpuva_sm_[un]map_ops_create().
3) Using drm_gpuva_[un]map() in callback context after having
prealloced a node and va objects for map/remap function use,
which must be forwarded in as the 'priv' argument to
drm_gpuva_sm_[un]map().
Right, and I think it might be worth concretely mentioning this in the
documentation.
The first of these is pretty self-explanatory. The second was also
fairly easy to understand, it has an example in your own driver, and
since it takes care of allocs in drm_gpuva_sm_map_ops_create() it
leads to pretty clean code too.
The third case, which I am using in the new PowerVR driver did not
have an example of usage and the approach is quite different to 2)
in that you have to prealloc everything explicitly. I didn't realise
this, so it led to a fair amount of frustration.
Yeah, I think this is not entirely obvious why this is the case. I
should maybe add a comment on how the callback way of using this
interface is motivated.
The requirement of pre-allocation arises out of two circumstances.
First, having a single callback for every drm_gpuva_op on the GPUVA
space implies that we're not allowed to fail the operation, because
processing the drm_gpuva_ops directly implies that we can't unwind them
on failure.
I know that the API functions the documentation guides you to use in
this case actually can return error codes, but those are just range
checks. If they fail, it's clearly a bug. However, I did not use WARN()
for those cases, since the driver could still decide to use the
callbacks to keep track of the operations in a driver specific way,
although I would not recommend doing this and rather like to try to
cover the drivers use case within the regular way of creating a list of
operations.
Second, most (other) drivers when using the callback way of this
interface would need to execute the GPUVA space updates asynchronously
in a dma_fence signalling critical path, where no memory allocations are
permitted.
I think if you're willing, it would help inexperienced implementers a
lot if there were some brief 'how to' snippets for each of the three
use cases.
Yes, I can definitely add some.
Thanks,
Donald
