Re: [PATCH] drm/i915: Update MOCS settings for gen 9

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux