Bug 101769

Summary:	2X performance regression on Mesa 17.1 vs 17.0
Product:	Mesa	Reporter:	David Pinedo <david>
Component:	Drivers/Gallium/radeonsi	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED MOVED	QA Contact:	Default DRI bug account <dri-devel>
Severity:	major
Priority:	medium	CC:	johnz, karen
Version:	17.1
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	hack to apitrace for duplicating problem

Description David Pinedo 2017-07-12 20:35:59 UTC

Created attachment 132646 [details] [review]
hack to apitrace for duplicating problem

We have an internal OpenGL benchmarking tool that measures the performance of
certain frames in apitrace files. We have been using this tool to measure
the performance of various releases of Mesa.

We recently found a large regression in Mesa performance of Half Life Episode 2, as measured by our benchmarking tool. We measured the following frame rates when running the benchmark with Mesa built from the listed source tags:

    tag mesa-17.0.0   358.6 fps
    tag mesa-17.1.3   151.1 fps

This is a reduction in performance of more than 2X.

Since the tool we use to measure performance is an internal tool and we cannot distribute it, I hacked apitrace to behave similar to our tool so that apitrace can be used to measure the performance of the problem frame.  The frame rates I measured with this hacked apitrace benchmark are:

    tag mesa-17.0.0   417.7 fps
    commit 071d80b    393.9 fps
    commit f81ede4    324.6 fps
    tag mesa-17.1.3   196.0 fps

The hacked apitrace shows about the same performance drop between mesa-17.0.0 and mesa-17.1.3 as our original benchmark. I also include the results for commits 071d80b and f81ede4 because commit f81ede4 seemed to show the single largest performance drop of all commits between mesa-17.0.0 and mesa-17.1.3.

The configuration of the system I have been using to measure Mesa performance is:

   CPU: Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz
   RAM: 16Gb
   GPU: AMD RX480

Attached is the patch I applied to apitrace to create my hacked apitrace that attempts to duplicate the original benchmark.

After building apitrace with the above patch, I used the following command to measure performance:

    vblank_mode=0 glretrace -b hl2_linux.trace

I can make the hl2_linux.trace trace file available on request. We cannot widely distribute it because it contains Valve IP (i.e. game images). Please send a request directly to david@lunarg.com.

Note that we have observed similar performance drops for other games, but I have concentrated on isolating and reporting on one frame in one game for now.

Comment 1 Matias N. Goldberg 2017-09-01 21:00:07 UTC

I was going to submit a new bug report, but I suspect this is the same issue.

I recently purchased an i7 7700 + Radeon RX 560 2GB to replace my older i5 4650 + Radeon HD 7770.
But I noticed performance on Dolphin Emulator *went down*. Way down when using OpenGL; whereas Vulkan has no performance issues and running on Windows gives similar performance to Linux with Vulkan.

But what's more baffling is the performance with our Ogre 2.1 samples:
1. If I run our Postprocessing sample I can easily obtain 500 fps.
2. But if certain processes are running on the background, such as RenderDoc with a capture (even if RenderDoc is minimized), the framerate will go down as low as 55-69fps; with CPU usage around 3% and radeontop indicating a GPU usage of 15%. This behavior is a little inconsistent, as closing RenderDoc will increase performance back to 500 fps, but opening RenderDoc again will keep it at 500 fps. RenderDoc is not the only process to induce this mysterious behavior, but it is the one I've managed to identify correctly.

At first I suspected a clocking problem, but after setting CPU governor to performance and echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level the problem persisted.

The framerate drops aren't also consistent, another of our samples for example reduces their performance from 200fps to 40fps.
Dolphin should be performing between 100-200 fps (by comparing with Vulkan and Windows versions) but it manages between 21-49fps

I will try to see if older versions of Mesa as this ticket suggests will solve the problem; although I'm not sure if Mesa 17.0.0 supports Polaris.

Comment 2 Matias N. Goldberg 2017-09-01 22:21:06 UTC

Bah, nevermind. Either my bug is not related or it gets fixed the same way.

Updating kernel from 4.11.6 to 4.12.10 seems to have solved all the weird performance issues.

Comment 3 Timothy Arceri 2019-05-07 00:45:58 UTC

Has this performance regression been fixed for you in recent Mesa releases?

Comment 4 GitLab Migration User 2019-09-25 17:59:39 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1273.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.