Comment # 5
on bug 110781
from Richard Thier
Still fast with mesa 17.2.8 and X.Org X Server 1.19.5 The problem is somewhere between 17.x and 19.x mesa versions (and corresponding xorg). Also I have made an strace when it is good in one older system to see number of CREATE and CLOSE ioctl calls (also the number of CS ioctl calls) are a magnitude smaller than in case of 19.x! For example 10-20 seconds of glxgears running leads to 9-10 calls to DRM_IOCTL_RADEON_GEM_CREATE on mesa 17.2.8 while it leads to 708 (!!!) number of same calls in the same time period on mesa 19.x! This is surely a quite big of a difference! The similar pattern in 17.x is never creating a new gem object: ... ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) = 0 <0.000055> ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) = 0 <0.000022> ioctl(6, DRM_IOCTL_RADEON_CS, 0xb307d03c) = 0 <0.000089> ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) = 0 <0.000053> ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) = 0 <0.000023> ioctl(6, DRM_IOCTL_RADEON_CS, 0xb30910d0) = 0 <0.000095> ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) = 0 <0.000054> ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) = 0 <0.000023> ioctl(6, DRM_IOCTL_RADEON_CS, 0xb307d03c) = 0 <0.000090> ... Sometimes when the *_BUSY ioctl call returns -1, it issues a CREATE, but otherwise not. I think GEM is some kind of memory handler for the GPU (just like "ttm" in the perf output) and I think something have messed up with memory handling schemes for Mobility Radeon 200M (r300) at some mesa update between 17.x and 19.x. Will try to bisect a closer version as 17.2.8 is from 2017.12.22 in time...
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
