From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance Date: Tue, 05 Aug 2014 21:15:02 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2087523383==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 2B89B6E324 for ; Tue, 5 Aug 2014 14:15:02 -0700 (PDT) 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 --===============2087523383== Content-Type: multipart/alternative; boundary="1407273302.fa440.27107"; charset="us-ascii" --1407273302.fa440.27107 Date: Tue, 5 Aug 2014 21:15:02 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=82201 --- Comment #15 from Kai --- (In reply to comment #11) > Created attachment 104101 [details] [review] > enable dpm=1 debugging even when dpm is not forced > > This patch enables the additional dpm debugging output even when it is not > explictly set on the command line. Does it help? The only thing I can > figure is that the debugging output adds a small delay that may have a > positive impact. You're not going to like this. But setting radeon.dpm=1 must have some other side effect. I booted each configuration represent by attachment 104103 and attachment 104104 two times. The first (104103) is the stack from comment #0 plus the patch from attachment 104101 applied to the kernel, then booted without radeon.dpm=1 (see the dmesg output for the kernel command line). When I start Portal 2 I stay at the numbers reported in comment #0 (ie. at low FPS). If I boot the stack from comment #0 with the patch from attachment 104101 applied to the kernel and DO set radeon.dpm=1 on the kernel command line (see second dmesg output; 104104), then I get 60 FPS in Portal 2. -- You are receiving this mail because: You are the assignee for the bug. --1407273302.fa440.27107 Date: Tue, 5 Aug 2014 21:15:02 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 15 on bug 82201 from 
(In reply to comment #11)
> Created attachment 104101 [details] [review] [review]
> enable dpm=1 debugging even when dpm is not forced
> 
> This patch enables the additional dpm debugging output even when it is not
> explictly set on the command line.  Does it help?  The only thing I can
> figure is that the debugging output adds a small delay that may have a
> positive impact.

You're not going to like this. But setting radeon.dpm=1 must have some other
side effect. I booted each configuration represent by attachment 104103 [details] and
attachment 104104 [details] two times. The first (104103) is the stack from comment #0
plus the patch from attachment 104101 [details] [review] applied to the kernel, then booted
without radeon.dpm=1 (see the dmesg output for the kernel command line). When I
start Portal 2 I stay at the numbers reported in comment #0 (ie. at low FPS).

If I boot the stack from comment #0 with the patch from attachment 104101 [details] [review]
applied to the kernel and DO set radeon.dpm=1 on the kernel command line (see
second dmesg output; 104104), then I get 60 FPS in Portal 2.

You are receiving this mail because:
  • You are the assignee for the bug.
--1407273302.fa440.27107-- --===============2087523383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============2087523383==--