Re: [RFC] drm/radeon: userfence IOCTL

From: Jerome Glisse <j.glisse@gmail.com>
To: "Christian König" <deathsimple@vodafone.de>
Cc: Serguei.Sagalovitch@amd.com, dri-devel@lists.freedesktop.org
Subject: Re: [RFC] drm/radeon: userfence IOCTL
Date: Mon, 13 Apr 2015 11:31:28 -0400	[thread overview]
Message-ID: <20150413153102.GA29334@gmail.com> (raw)
In-Reply-To: <1428936737-19103-1-git-send-email-deathsimple@vodafone.de>

On Mon, Apr 13, 2015 at 04:52:14PM +0200, Christian König wrote:
> Hello everyone,
> 
> we have a requirement for a bit different kind of fence handling.
> Currently we handle fences completely inside the kernel, but in
> the future we would like to emit multiple fences inside the same
> IB as well.
> 
> This works by adding multiple fence commands into an IB which
> just write their value to a specific location inside a BO and
> trigger the appropriate hardware interrupt.
> 
> The user part of the driver stack should then be able to call an
> IOCTL to wait for the interrupt and block for the value (or
> something larger) to be written to the specific location.
> 
> This has the advantage that you can have multiple synchronization
> points in the same IB and don't need to split up your draw commands
> over several IBs so that the kernel can insert kernel fences in
> between.
> 
> The following set of patches tries to implement exactly this IOCTL.
> The big problem with that IOCTL is that TTM needs the BO to be
> kept in the same place while it is mapped inside the kernel page
> table. So this requires that we pin down the BO for the duration
> of the wait IOCTL.
> 
> This practically gives userspace a way of pinning down BOs for as
> long as it wants, without the ability for the kernel for intervention.
> 
> Any ideas how to avoid those problems? Or better ideas how to handle
> the new requirements?

So i think the simplest solution is to only allow such "fence" bo to
be inside system memory (no vram for them). My assumption here is that
such BO will barely see more than couple dword write so it is not a
bandwidth intensive BO. Or do you have a requirement for such BO to
be in VRAM ?

Now to do that i would just add a property to buffer object that
effectively forbid such BO to be place anywhere else than GTT. Doing
that would make the ioctl code simpler, just check the BO as the
GTT only property set and if not return -EINVAL. Then its a simple
matter of kmapping the proper page.

Note that the only thing that would be left to forbid is the swaping
of the buffer due to memory pressure (from various ttm/core shrinker).

Cheers,
Jérôme
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel