From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 110781] Radeon: heavy r300 performance drop regression between
11.x and 19.x
Date: Wed, 29 May 2019 15:49:02 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0349011079=="
Return-path:
Received: from culpepper.freedesktop.org (culpepper.freedesktop.org
[IPv6:2610:10:20:722:a800:ff:fe98:4b55])
by gabe.freedesktop.org (Postfix) with ESMTP id C353C6E0F2
for ; Wed, 29 May 2019 15:49:01 +0000 (UTC)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel"
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
--===============0349011079==
Content-Type: multipart/alternative; boundary="15591449410.EffFE324.3939"
Content-Transfer-Encoding: 7bit
--15591449410.EffFE324.3939
Date: Wed, 29 May 2019 15:49:01 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated
https://bugs.freedesktop.org/show_bug.cgi?id=3D110781
--- Comment #5 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 correspon=
ding
xorg).
Also I have made an strace when it is good in one older system to see numbe=
r 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 (!!!) numb=
er
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) =3D 0 <0.000055>
ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) =3D 0 <0.000022>
ioctl(6, DRM_IOCTL_RADEON_CS, 0xb307d03c) =3D 0 <0.000089>
ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) =3D 0 <0.000053>
ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) =3D 0 <0.000023>
ioctl(6, DRM_IOCTL_RADEON_CS, 0xb30910d0) =3D 0 <0.000095>
ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) =3D 0 <0.000054>
ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) =3D 0 <0.000023>
ioctl(6, DRM_IOCTL_RADEON_CS, 0xb307d03c) =3D 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 sche=
mes
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...
--=20
You are receiving this mail because:
You are the assignee for the bug.=
--15591449410.EffFE324.3939
Date: Wed, 29 May 2019 15:49:01 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated
Commen=
t # 5
on bug 11078=
1
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 correspon=
ding
xorg).
Also I have made an strace when it is good in one older system to see numbe=
r 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 (!!!) numb=
er
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) =3D 0 <0.000055&g=
t;
ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) =3D 0 <0.000022>
ioctl(6, DRM_IOCTL_RADEON_CS, 0xb307d03c) =3D 0 <0.000089>
ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) =3D 0 <0.000053&g=
t;
ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) =3D 0 <0.000023>
ioctl(6, DRM_IOCTL_RADEON_CS, 0xb30910d0) =3D 0 <0.000095>
ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) =3D 0 <0.000054&g=
t;
ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) =3D 0 <0.000023>
ioctl(6, DRM_IOCTL_RADEON_CS, 0xb307d03c) =3D 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 sche=
mes
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.
=
--15591449410.EffFE324.3939--
--===============0349011079==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs
--===============0349011079==--