found the bug reports.
Here is the original bug report from the kernel:
And here is an fdo bug report where we tried to investigate the root
cause, but didn't had time for that yet:
Am 06.04.2018 um 10:03 schrieb Christian König:
yeah, that is a known problem. Using huge pages improves the
performance because of better TLB usage, but for the cost of higher
What we found is that firefox is doing something rather strange by
allocating large textures and then just trowing them away again
We mitigated the problem by avoiding the slow coherent DMA code path
on almost all platforms on newer kernels, but essentially somebody
needs to figure out why firefox and/or the user space stack is doing
this constant allocation/freeing of memory.
There is also a bug tracker on bugs.kernel.org about this, but I can't
find it any more of hand.
Am 06.04.2018 um 02:30 schrieb Jean-Marc Valin:
I noticed a serious graphics performance regression between 4.14 and
4.15. It is most noticeable with Firefox (tried FF57 through FF60) and
causes scrolling to be really choppy/sluggish. I've confirmed that the
problem is also there on 4.16, while 4.13 works fine.
After a bisection, I've narrowed the regression down to this commit:
Author: Christian König <christian.koe...@amd.com>
Date: Thu Jul 6 09:59:43 2017 +0200
drm/ttm: add transparent huge page support for DMA allocations v2
Some details about my system:
Distro: Fedora 27 (up-to-date)
Video: MSI Radeon RX 560 AERO
CPU: Dual-socket Xeon E5-2640 v4 (20 cores total)
RAM: 128 GB ECC
As a comparison, when running Firefox with 4.15 on a Lenovo W540 laptop
(with Intel graphics only) the responsiveness is much better then what
I'm getting on the Xeon machine above with the Radeon card, so this
really seems to be an AMD-only issue.
Any way to fix the issue?
dri-devel mailing list