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?

Please note that the patches are only hacked together quick&dirty to 
demonstrate the problem and not very well tested.

Best regards,
Christian.

Reply via email to