[Intel-gfx] About client-controlled GPU workload preemption interface.

[Wang, Zhi A]

Hi:
　Recently, we're discussing about adding some interfaces to preempt and cancel the i915 request for GVT-g. After thinking and digging for a while, It looks like the requirement are quite generic.

 In a multi-buffered rendering window system, when some events happen, it will try to re-draw the screen. During this process, it might want to discard the previous workload ASAP then start the new workload, because the a new event came and it knew the drawing buffer was out-of-date. In this case, the drawing client might want to stop and cancel the workload immediately, then decided if the workload need to be re-submitted or not.

The Microsoft Windows rendering preemption also shows the same design and requirement for better desktop responsiveness. The preemption is controlled by the DirectX Graphics Kernel, aka DXGK, which manages the GPU workload scheduling and memory management and other generic resources. It provides some preemption hooks for the kernel model driver. When it want to stop the current workload, it dispatched the preempt request to the kernel mode driver. The re-submission is handled in DXGK.

So, it’s like there are two different kinds of GPU preemption with different purposes.

The current GPU preemption implementation in i915 is for those clients which just expect a "prioritized workload submission" and don’t expect to manipulate stopping and re-submitting the request by themselves.

For clients which expect to control the preemption in a fine granularity level for better responsiveness, new interfaces are required.

We can see the two mechanism are not conflicted and overlapped with each other. Both of the "prioritized workload submission" and "client-controlled GPU workload preemption" has their own field.

Though, the client-controlled GPU workload preemption interface might be only required by GVT-g at this time, but if we can see it as a common approach for a better drawing and rendering architecture, it would be better to be implemented as common APIs not only specific for GVT-g. (Maybe currently only some kernel APIs are enough for GVT-g, but if a user mode client also wants to use it, it would be easy to have an IOCTL at that time.)

To achieve a fine granularity preemption, the requirements are summarized as below:

1. A new interface for the client to be able to stop the workload submitted ASAP. The re-submission is controlled by the client. When the interface is called, the request might be already in SW scheduler queue or flying on HW. In the 1st case, the request can be directly kicked out from the SW scheduler queue. In the 2nd case, a preemption-to-idle to the flying request is necessary.

2. The synchronization interface has to aware the cancelation of the request and signal the client if the request is cancelled.

That's all in my mind and feel free to share your opinion. :)

Thanks,
Zhi.