From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 107277] Raven: pci_pm_suspend takes over 1 second Date: Wed, 18 Jul 2018 15:37:10 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0398914148==" 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 1EA9D6E78D for ; Wed, 18 Jul 2018 15:37:10 +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 --===============0398914148== Content-Type: multipart/alternative; boundary="15319282300.Bdeb9B39.30298" Content-Transfer-Encoding: 7bit --15319282300.Bdeb9B39.30298 Date: Wed, 18 Jul 2018 15:37:10 +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=3D107277 --- Comment #4 from Alex Deucher --- (In reply to Paul Menzel from comment #3) > (In reply to Christian K=C3=B6nig from comment #2) > > There isn't much you can do here: > > > amdgpu_bo_evict_vram [amdgpu] (306.331 ms @ 74.694620) > >=20 > > This is evacuating the content of VRAM to RAM/disk to make sure we don't > > lose screen content while suspended. >=20 > I do not understand that. The integrated graphics device uses the system = RAM > as VRAM doesn=E2=80=99t it? So why does it have to be evicted at all? Als= o, I > believe it=E2=80=99s 1 GB of VRAM. That means the speed would be 3 GB/s, = where it > should be much higher with DDR4 shouldn=E2=80=99t it? It's not a problem with S3 (suspend to ram), but it is for S4 (suspend to d= isk) because power will be lost and the vram carve out area is not managed by the OS. Currently S3 and S4 share the same code paths, so they would need to be reworked to handle S3 and S4 differently. As for the time it takes, depend= ing on how much system memory is in use, some stuff may have to be swapped out = to disk to make room for all of the buffers in vram, so a lot of shuffling may need to take place. --=20 You are receiving this mail because: You are the assignee for the bug.= --15319282300.Bdeb9B39.30298 Date: Wed, 18 Jul 2018 15:37:10 +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 # 4 on bug 10727= 7 from Alex Deucher 
(In reply to Paul Menzel from comment #3)
> (In reply to Christian K=C3=B6nig from comment #2)
> > There isn't much you can do here:
> > > amdgpu_bo_evict_vram [amdgpu] (306.331 ms @ 74.694620)
> >=20
> > This is evacuating the content of VRAM to RAM/disk to make sure w=
e don't
> > lose screen content while suspended.
>=20
> I do not understand that. The integrated graphics device uses the syst=
em RAM
> as VRAM doesn=E2=80=99t it? So why does it have to be evicted at all? =
Also, I
> believe it=E2=80=99s 1 GB of VRAM. That means the speed would be 3 GB/=
s, where it
> should be much higher with DDR4 shouldn=E2=80=99t it?

It's not a problem with S3 (suspend to ram), but it is for S4 (suspend to d=
isk)
because power will be lost and the vram carve out area is not managed by the
OS.  Currently S3 and S4 share the same code paths, so they would need to be
reworked to handle S3 and S4 differently.  As for the time it takes, depend=
ing
on how much system memory is in use, some stuff may have to be swapped out =
to
disk to make room for all of the buffers in vram, so a lot of shuffling may
need to take place.

You are receiving this mail because:
  • You are the assignee for the bug.
= --15319282300.Bdeb9B39.30298-- --===============0398914148== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0398914148==--