Bug 109505

Something on the kernel side in drm-tip git improved Heaven performance by similar amount it dropped with Mesa in December.  That didn't affect Valley though.

Hi, 
I've run tests on my machine:
Manjaro on Gnome 3.30.2 with 4.20.11 Kernel.
CPU - Intel Core i7-8550U
GPU - Intel® UHD Graphics 620 (Kaby Lake (GT2)) 

I've performed few tests for three versions of Mesa (18.3.3 ; 9ebc00f32e and 5c454661c6)
and I have next results:
- Heaven 
18.3.3 : FPS - 11.1; Score - 279; Min FPS - 5.5; Max FPS - 23.7.
9ebc00f32e : FPS - 11.1; Score - 278; Min FPS - 6.4; Max FPS - 242.
5c454661c6 : FPS - 10.3; Score - 260; Min FPS - 5.9; Max FPS - 23.3.

- Valley 
18.3.3 : FPS - 12.1; Score - 508; Min FPS - 7.6; Max FPS - 21.5.
9ebc00f32e : FPS - 12.1; Score - 509; Min FPS - 8; Max FPS - 22.3.
5c454661c6 : FPS - 11.2; Score - 467; Min FPS - 7.8; Max FPS - 18.

I want to clarify, how are you comparing results of testing?
maybe you have some tool for that?

(In reply to Paul from comment #2)
> I want to clarify, how are you comparing results of testing?
> maybe you have some tool for that?

We have an internal thing for drawing trends & showing data from test runs automated with Jenkins, which still happens to be running some 3D tests.

When I had still time for Mesa, I used this tool to bisect performance changes I saw in the trends:
  https://cgit.freedesktop.org/ezbench/tree/README
  https://www.x.org/wiki/Events/XDC2016/Program/peres_ezbench.pdf

(It automatically bisects all performance and rendering changes in given tests, between given commit range in given repo, which is very handy.  I don't know any other tool that does both, although whether rendering has changed is important info for evaluating performance changes.)


Few people in Mesa team have used this:
  https://gitlab.freedesktop.org/mesa/sixonix/commits/master

(It does much less than ezBench, but is simpler to use.)

I bisected this to:

author	Rafael Antognolli <rafael.antognolli@intel.com>	2018-10-29 10:19:54 -0700
commit	5c454661c66fa2624cf4bba1071175070724869a (patch)
i965/gen9: Add workarounds for object preemption.

Mesa engineers took a look at this, and decided that the performance penalty represents the cost of enabling preemption.

Since the performance penalty is slight, the team decided not to address it.

Benchmarks will not measure the improvements to system responsiveness that come from this feature.  Sometimes we need to make the choice that a benchmark score is not the most important indicator of our driver's performance, even if it is the most visible one.

(In reply to Mark Janes from comment #5)
> Mesa engineers took a look at this, and decided that the performance penalty
> represents the cost of enabling preemption.
>
> Since the performance penalty is slight, the team decided not to address it.

I assume it's the PIPE_CONTROL_RENDER_TARGET_FLUSH when toggling preemption.

Neither Heaven nor Valley use any of the draw types that require disabling preemption, but they do use instancing.

GfxBench Manhattan tests use in addition to instancing, also Triangle FAN draw type, but I didn't check how much they alternates those with the other draw types & non-instancing draws (that can be pre-empted on GEN9). It's anyway likely that they're slightly impacted also, but happily impact is below daily variance.


> Benchmarks will not measure the improvements to system responsiveness that
> come from this feature.  Sometimes we need to make the choice that a
> benchmark score is not the most important indicator of our driver's
> performance, even if it is the most visible one.

Yep, most important was bisecting this so that an informed decision can be done about it.

VERIFIED.