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: Tue, 04 Jun 2019 07:56:23 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1109850710==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 3956D897B4 for ; Tue, 4 Jun 2019 07:56:23 +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 --===============1109850710== Content-Type: multipart/alternative; boundary="15596349832.16367c1D8.20649" Content-Transfer-Encoding: 7bit --15596349832.16367c1D8.20649 Date: Tue, 4 Jun 2019 07:56:23 +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 #25 from Richard Thier --- In the assert problem this is the domain and flag meanings in case of only = my hack is in place: domain(6) =3D=3D RADEON_DOMAIN_GTT(2) | RADEON_DOMAIN_VRAM(4) flags(1) =3D=3D RADEON_FLAG_GTT_WC (1 << 0) So I get -1 even if I "outcomment" this check in radeon_get_heap_index(..): /* Resources with interprocess sharing don't use any winsys allocators.= =20 if (!(flags & RADEON_FLAG_NO_INTERPROCESS_SHARING)) return -1;*/ There is a switch statement in this function where they switch based on the domain parameter: switch (domain) { case RADEON_DOMAIN_VRAM: ... case RADEON_DOMAIN_GTT: ... default: break; } return -1; I suspect we return -1 here because we go into the "default" case. I think = that is right because domain is: 6 =3D=3D 2 | 4 =3D=3D GTT+VRAM at the same time. Maybe once it was meaningful to have both GTT (is that GART?) and VRAM at t= he same time being or-ed together but not anymore? I will try to add a hack to make the domain always just VRAM to see what happens... I know that is bad, but just for the analysis. --=20 You are receiving this mail because: You are the assignee for the bug.= --15596349832.16367c1D8.20649 Date: Tue, 4 Jun 2019 07:56:23 +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

Comme= nt # 25 on bug 11078= 1 from = Richard Thier
In the assert problem this is the domain and flag meanings in =
case of only my
hack is in place:

domain(6) =3D=3D RADEON_DOMAIN_GTT(2) | RADEON_DOMAIN_VRAM(4)
flags(1) =3D=3D RADEON_FLAG_GTT_WC (1 << 0)

So I get -1 even if I "outcomment" this check in radeon_get_heap_=
index(..):

    /* Resources with interprocess sharing don't use any winsys allocators.=
=20
    if (!(flags & RADEON_FLAG_NO_INTERPROCESS_SHARING))
        return -1;*/

There is a switch statement in this function where they switch based on the
domain parameter:

    switch (domain) {
    case RADEON_DOMAIN_VRAM:
      ...
    case RADEON_DOMAIN_GTT:
      ...
    default:
        break;
    }
    return -1;

I suspect we return -1 here because we go into the "default" case=
. I think that
is right because domain is: 6 =3D=3D 2 | 4 =3D=3D GTT+VRAM at the same time.

Maybe once it was meaningful to have both GTT (is that GART?) and VRAM at t=
he
same time being or-ed together but not anymore?

I will try to add a hack to make the domain always just VRAM to see what
happens... I know that is bad, but just for the analysis.


You are receiving this mail because:
  • You are the assignee for the bug.
= --15596349832.16367c1D8.20649-- --===============1109850710== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1109850710==--