Re: [RFC PATCH 00/97] Basic GuC submission support in the i915

[Martin Peres <martin.peres@free.fr>]

On 11/05/2021 05:58, Dixit, Ashutosh wrote:
> On Sun, 09 May 2021 16:11:43 -0700, Jason Ekstrand wrote:
>>
>> Yes, landing GuC support may be the first step in removing execlist
>> support. The inevitable reality is that GPU scheduling is coming and
>> likely to be there only path in the not-too-distant future.  (See also
>> the ongoing thread with AMD about fences.) I'm not going to pass
>> judgement on whether or not this is a good thing.  I'm just reading the
>> winds and, in my view, this is where things are headed for good or ill.
>>
>> In answer to the question above, the answer to "what do we gain from
>> GuC?" may soon be, "you get to use your GPU."  We're not there yet and,
>> again, I'm not necessarily advocating for it, but that is likely where
>> things are headed.
>>
>> A firmware-based submission model isn't a bad design IMO and, aside from
>> the firmware freedom issues, I think there are actual advantages to the
>> model. Immediately, it'll unlock a few features like parallel submission
>> (more on that in a bit) and long-running compute because they're
>> implemented in GuC and the work to implement them properly in the
>> execlist scheduler is highly non-trivial.  Longer term, it may (no
>> guarantees) unlock some performance by getting the kernel out of the way.
> 
> I believe another main reason for GuC is support for HW based
> virtualization like SRIOV. The only way to support SRIOV with execlists
> would be to statically partition the GPU between VM's, any dynamic
> partitioning needs something in HW.
> 

FW-based command-submission is indeed a win for SRIOV and the current HW 
architecture.

Thanks for chiming in!
Martin