Hi,
On 04.05.2017 11:53, Tvrtko Ursulin wrote:
On 04/05/2017 09:35, Arkadiusz Hiler wrote:
On Thu, Apr 27, 2017 at 05:23:16PM +0100, Chris Wilson wrote:
But what is being counter suggested is that their is no reason for these
mocs entries. If the sdk is just using mocs registers without first
programming them outside of the kernel abi, then it will be hitting
uncached memory - and then the only benefit is from simply enabling
cached access. The kernel ABI is minimalist for a reason, and we want to
know why we should be adding tables that we need to maintain forever
(bonus points for making that a consistent interface for hardware for
years to come).
-Chris
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?
Alternatively, at the time this was on my plate, Eero had suggested a
sequence of experiments by basically gradually replicating the default
UC/WB entries to currently empty slots, starting on GT2 parts and then
going forward adding the more fine tuned parts.
This would have showed the benefit of fine tuned entries vs basic cached
ones. Unfortunately I never got round doing this, but it sounded like a
really good approach to me.
I could paste these suggestion here if Eero wouldn't mind?
Of course I don't mind. :-)
But I am also
not sure if it is still relevant after the effort of exactly documenting
the extended set of entries started.
It's relevant in the sense that we don't currently don't know whether
there's any actual benefit from the new entries (i.e. was it just an
issue of VPG not using the correct existing entries).
If there is, that would be motivation to investigate impact of them also
on other workloads.
- Eero
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
