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

[Chris Wilson]

On Fri, May 05, 2017 at 01:31:37PM +0200, Arkadiusz Hiler wrote:
> 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.

Michal (W or W) has some patches to allow contexts to set their own mocs,
which is definitely my preferred solution.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre