On Tue, Jun 18, 2019 at 2:31 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> Quoting Daniel Vetter (2019-06-14 21:36:04)
> > It looks like this was done purely to get a consistent place to look
> > up the reservation object pointer. With the drm_prime.c helper code
> > now also setting gem_object->resv for imported objects we can just use
> > that pointer directly, instead of first ensuring a dma-buf exists.
>
> Oh. commit 1ba627148ef5 ("drm: Add reservation_object to drm_gem_object")
> embedded a reservation_object into the struct. I was wondering what on
> earth I was doing if the code should have been so simple.
Yeah, this is the thing that started all this, plus a lot more (all
the gem locking helper functions that panfrost and v3d are using).
I think next steps might be to ditch ttm_bo.resv|ttm_resv and
i915_bo.resv|__builtin_resv in favour of the one in drm_gem_bo. But my
series here was already getting way to big. The ttm one is only really
a problem for vmwgfx, and that's easy to solve by giving them a
separate pointer. We might need to keep ttm_bo.resv pointer to make
transitioning easier.
> References: 1ba627148ef5 ("drm: Add reservation_object to drm_gem_object")
> > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
>
> Quick leave before I start ranting about the horrors of
> reservation_object.
:-)
I think it's a case of "the devil we have" and all that ...
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
