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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
