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

[Arkadiusz Hiler]

On Fri, May 05, 2017 at 12:49:49PM +0100, Chris Wilson wrote:
> 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

Michal Winiarski (CCed).

IIRC the series was only for render - other rings does not have
context-stored MOCS.

-- 
Cheers,
Arek