On 07.11.2017 15:29, Mikko Perttunen wrote:
On 05.11.2017 19:43, Dmitry Osipenko wrote:
On 05.11.2017 14:01, Mikko Perttunen wrote:
In the traditional channel allocation model, a single hardware channel was allocated for each client. This is simple from an implementation perspective but prevents use of hardware scheduling.
This patch implements a channel allocation model where when a user submits a job for a context, a hardware channel is allocated for that context. The same channel is kept for as long as there are incomplete jobs for that context. This way we can use hardware scheduling and channel isolation between userspace processes, but also prevent idling contexts from taking up hardware resources.
The dynamic channels resources (pushbuf) allocation is very expensive, neglecting all benefits that this model should bring at least in non-IOMMU case. We could have statically preallocated channels resources or defer resources freeing.
This is true. I'll try to figure out a nice way to keep the pushbuf allocations.
One variant could be to have all channels resources statically preallocated in a non-IOMMU case because CMA is expensive. Then you should measure the allocations impact in a case of IOMMU allocations and if it is significant, maybe implement Host1x PM autosuspend, releasing all channels when Host1x become idle.
I think the above should be efficient and easy to implement.