[Intel-gfx] [PATCH 48/59] drm/vgem: Ditch attach trickery in the fence ioctl

[Daniel Vetter]

On Tue, Jun 18, 2019 at 2:31 PM Chris Wilson <chris at chris-wilson.co.uk> 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 at intel.com>
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
>
> 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