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

[Ewins, Jon]

On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> On Thursday, May 4, 2017 7:47:21 AM PDT David Weinehall wrote:
>> On Thu, May 04, 2017 at 10:35:33AM +0200, Arkadiusz Hiler wrote:
>>> Thanks for rephrasing - that's exactly what I am concerned with.
>>>
>>> Did you just use the MediaSDK as it is - meaning that MOCS entries
>>> beyond the set of the 3 we have defined had been naively utilized?
>>>
>>> If that's the case it is probably the cause of the performance
>>> difference - everything beyond "the 3" means UNCACHED.
>>>
>>> Can you try changing MediaSDK to only use entries that are already in?
>>> How the performance differs in that case?
>> We're benchmarking using upstream MediaSDK without changes, since that's
>> the only thing that's relevant. Customising benchmarks to get better
>> results isn't really an acceptable solution :)
>>
>> Obviously fixing MediaSDK upstream is a different story, in case one of
>> the three pre-defined entries we have turns out to be the best possible
>> MOCS-settings for that workload.
> You're right about customizing benchmarks, but...
>
> 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.
>
> We don't warp the core operating system to work around userspace
> software simply because they don't want to change it.
Agreed, that isn't the intention.
> This isn't about open vs. closed or internal vs. public projects,
> either.  I work on a public userspace driver for Intel graphics.
> If I sent a kernel patch, the kernel developers would ask me the
> exact same questions, to justify my new additions:
>
>     1.  Is your userspace actually using all these new additions?
>         If not, which ones are you using?
>
>         They would ask me to drop anything I wasn't actually using
>         yet, because speculatively adding things to the kernel that
>         we have to maintain backwards compatibility for has caused
>         both kernel and userspace developers a lot of trouble.
>
>     2.  Are you sure that you need them all?  Is there a simpler
>         solution - are some existing things good enough?  What's
>         the additional benefit of each new addition?
>
> I would have to answer these questions to the satisfaction of the
> kernel developers before they would even consider taking my patch.
>
> You keep pointing to your large performance improvement, but all it's
> shown is that actually using the GPU cache is faster than having a
> broken userspace driver explicitly set everything to uncached.  Many
> people have pointed this out.
> Arek and Tvrtko have good suggestions.  I don't think you're going
> to get anywhere with this until you demonstrate that the new MOCS
> entries provide some non-zero value over using the existing WB entries
> Here are a couple more data points:
>
> 1. We likely can't implement the documented "MOCS Version 1"
>     table as is.
>
>     The kernel exposes existing entries with specific semantics.
>     Changing their meaning would introduce a backwards-incompatible
>     change that would likely regress the performance of existing
>     userspace.  This is almost certainly unacceptable - our customers,
>     distro partners, users, and even people like Linus Torvalds will
>     suffer and complain loudly.
>     
The way the existing entries are exposed should not be changing.
>     We could add the new entries at an offset - i.e. leave the existing
>     3 entries, and append the rest after that.  But that would require
>     changing userspace that assumes the Windows tables, such as MediaSDK
>     (they would have to add 3 to their MOCS indexes).  At which point,
>     we're changing them, so...the "runs unaltered" argument falls over.
The intention is certainly that the existing 3 entries already in use by 
open source user mode stack are not changed.
This is additive to what is there.  The BSpec should be reflecting that 
- if not that is an error.  The Intel UMDs will change to support this.
> 2. The docs finally contain "recommended MOCS settings" - i.e. where
>     to cache various types of objects, and at what age.  However, I
>     believe those recommendations can be implemented with 1-2 new table
>     entries and a PTE change to be eLLC-only by default.  Most of the
>     table is completely unnecessary to implement the recommendations.
>
>     I personally would like to try implementing their recommended
>     settings in my driver.  I have not had time yet, but plan to try.
>
> I'm very glad to see the Windows MOCS recommendations documented.
> I'd been asking for that information for literally years.  If we'd
> gotten it earlier, a lot of mess could have been avoided.  For future
> platforms, we may want to coordinate and use the same table.  But
> Gen9 has been shipping for ages, and we don't have that luxury.
I would hope that is not the case and the change can be made for gen9, 
as it should have no impact on existing user space as is, while the 
addition of the new entries can provide benefit.

> --Ken
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20170504/0eb1a1e3/attachment.html>