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.
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.
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.
Has this performance regression been fixed for you in recent Mesa releases?
-- 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.