[Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

[Dmitry Rogozhkin]

On 5/5/2017 8:44 AM, Kenneth Graunke wrote:
> On Thursday, May 4, 2017 7:46:34 PM PDT Dmitry Rogozhkin wrote:
>> On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
>>> MediaSDK is not a benchmark.  If I'm not mistaken, it's a userspace
>>> driver produced by Intel engineers, one which Intel has the full
>>> capability to change.  What you're saying is that Intel's MediaSDK
>>> engineers are unwilling to change their software to provide better
>>> performance for their Linux users.
>>>
>>> That's pretty mental.
>> You are mistaken. Media SDK is not a driver. It is a user space library
>> which talks to the user space driver. And Media SDK does not set _any_
>> caching policies you are discussing here. That's the driver who sets
>> these policies. I don't want to go further here who supports this
>> driver, Intel or not, but there are mediasdk engineers whom you blame to
>> not willing to do something and who actually only indirectly are related
>> to this topic. Please, if you mean driver, say a driver.
> Sorry, that's my mistake - and I think a number of other people in the
> thread were similarly confused.  So, the suggestion isn't to change
> MediaSDK at all - it's to change the closed-source libva driver that's
> setting MOCS values that aren't supported by the upstream kernel.  IIRC
> the upstream libva-intel-driver does not have this bug.
Mistakes happen. I hope this is clarified now.
>
> My point largely stands, when redirected - someone is developing a
> broken closed source userspace driver and is apparently unwilling to
> change it.  That's the real problem.
Broken? Have you ever attempted to run functional and performance 
competitive between closed source and open source user space drivers? I 
attempted and a number of others have attempted that. Result is that 
open source driver has significantly worse encoding quality, worse to 
the degree that any performance comparisons start to make no sense. 
(Yep, work in progress to try to fix that, I know.) Decoding quality is 
on par, but I saw cases when performance is 5-10% worse (and that's when 
both drivers work on their presumably optimal settings). So, "broken" 
closed source driver is in use for the _reason_. And which driver could 
be considered "broken" after that: closed source one or open source one?

So, why you are addressing that closed source driver is broken? If it 
will be put in the environment with the upstream kernel, then it will 
eventually be broken and that's what we are trying to fix here. But do 
you realize that in the production environment where the driver is 
intended to work there is a patched kernel mode driver in place with the 
MOCS settings to satisfy the need of the driver? Or you naively think we 
use non-modified KMD from the upstream or previously released versions 
from kernel.org. Bad guess! In the production environment driver is not 
broken.

MY ADVICE to everyone on the thread: topic is really hot, no clear path 
to deal with the problem is seen. Please, try to avoid addressing work 
done by others in the words: "unwilling", "broken", etc. This bothers 
people... Be easy...

There were suggestions in the thread to apply existing settings to the 
closed source driver and see how cool things will be. Well, we applied 
this settings: not cache anything policy and performance is worse 
comparing to the closed source solution. We have 3 other policies to 
try. Which one you want to try? Or you want to try combination? For 
which objects you suggest to try these combinations? If I recall 
correctly closed source driver has dozens, maybe close to hundred 
objects of different kind with different caching policies. You want to 
try all combinations? That's out of reality per my opinion... At least 
that can't happen within few days.

So, closed source driver _has_ settings it considers optimal. And yes, 
there is such a question how really optimal they are, but existing 
settings work, work well for few years already (in a closed source 
solution delivered to the customers) and work better comparing to open 
source solution. This solution is far to be considered broken. Open 
source solution is delivered to absolutely different set of customers, 
customers do not intersect, and I guess we can't consider open source 
solution broken as well. It satisfy certain customers segment. And there 
are possibilities to improve both solutions. Both groups can be blamed 
in unwillingness, but... wait a minute... after all here are both groups 
in the thread discussing this topic, so are we willing or unwilling to 
change?

I personally think that optimal solution would be:
1) Either an API to permit drivers to program settings they consider 
optimal and avoid all this discussion altogether.
2) or remove this MOCS table from the SW level completely and hold it on 
GPU side hidden from the SW stack (yep, not possible for current HW)
As for the solution#1, I afraid we have technical issues, right? Is that 
true that only Render contexts can hold settings table and that's not 
possible for other context types due to HW limitations? At what cost we 
would be able to support use cases with few drivers working at the same 
time and each trying to update MOCS settings for the global contexts?

Dmitry.