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