[RFC] drm/radeon: userfence IOCTL

[Christian König]

On 13.04.2015 17:31, Jerome Glisse wrote:
> 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 ?

Not that I know off.

> 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.

I've also considered adding an internal flag that when a buffer is 
kmapped we avoid moving it to VRAM / swapping it out, but see below.

> 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).

Yeah, how the heck would I do that? That's internals of TTM that I never 
got into.

Thanks for the ideas,
Christian.

>
> Cheers,
> Jérôme