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

[Arkadiusz Hiler]

On Thu, May 04, 2017 at 07:46:34PM -0700, 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.

You are right. It is very unfortunate that those two were confused.

To further clarify, here's an excerpt from MediaSDK's README.md:

"Intel Media SDK depends on a special version of LibVA which comes with
Intel Media Server Studio installation and is not in upstream, so this
version is not compatible with the LibVA/driver available at 01org."


Nonetheless, the main question still stands:

How big is the performance gap when using appropriate, existing entries
entries vs the entries proposed here?


Also a couple more questions arise:

* What about versioning schema? We definitely need a consumer for that.

* The libva you use is a **closed** UMD. It this enough of a reason to
  do the change (sans the versioning)? It starts to get blurry here.

Don't get me wrong, I've seen the spec and believe that a lot of hard
work was put into determining the entries and the usage scenarios, and
that they can benefit us.

I even have some patches ready[0] and I would love to get them upstream,
but they have to be tested in reproducible manner, with clear
methodology. They need to be discussed and deemed useful by providing
real value. We cannot simply relay on opaque claims that they are good
for us.


To do the above I am fiddling with Mesa - if we will see performance
boost, then this would provide both a solid reason to add the entries
and a consumer for the versioning API.


As of proprietary libva/MediaSDK combo I see at least three options to
do "the 3" vs "extended mocs" testing:

1. change the libva you use to utilize only the basic 3 entries only and
   do the testing - if you can change the source

2. change kernel and fill in entries with copies of the 3 basic ones and
   do the testing - will work even without the source code of libva

3. port the MOCS changes to 01org's libva and either use this version
   from MediaSDK for testing or use some other benchmarks -  this could
   be the consumer we need

I hope that this will move us forward.

[0]: https://github.com/ivyl/linux/commits/mocs

-- 
Cheers,
Arek