From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 72785] bfgminer --scrypt on 7xxx+
Date: Mon, 24 Nov 2014 17:43:03 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0489801572=="
Return-path:
Received: from culpepper.freedesktop.org (unknown [131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id 5CED06EA6B
for ; Mon, 24 Nov 2014 09:43:03 -0800 (PST)
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
--===============0489801572==
Content-Type: multipart/alternative; boundary="1416850983.3C35B3.16567"; charset="UTF-8"
--1416850983.3C35B3.16567
Date: Mon, 24 Nov 2014 17:43:03 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=72785
--- Comment #36 from Linux User ---
Got similar issues when trying scrypt. I have relatively recent bfgminer (~1
month old git build) and more or less recent graphics stack: 3.17 kernel, mesa
10.4 pre-release from Oibaf PPA and LLVM 3.5.1
I have bunch of HD5000 based cards, mostly HD5750/5770 and somesuch and R9 270.
Tests have shown bfgminer performs correctly when computing SHA256 and goes
about 80% of catalyst at 57xx and even better than that on R9 270.
However things are much worse when it comes to scrypt. I got impression open
driver can get issues if something aggressively using GPU VRAM.
Some observations about open drivers stack so far:
- If you set scrypt intensity too high, there is high risk GPU would lock up in
fatal way and crash (can happen on both 57xx and R9).
- It is also exceptionally unsafe to try sha256 with vectors=4 on HD 57xx. It
would be much slower than other vector settings anyway, but still indication of
some techmical problem lurking around.
- If I'm setting up intensity at reasonable levels, it does builds kernels and
computes BUT --benchmark ***NEVER*** accepts computed blocks, 100% reject rate.
If I reduce intensity - error rate goes down. But still no accepted blocks. If
I try CPU at same time, it computes several blocks at time frame where GPU
gives no results at all. This indicates computations are just going wrong.
p.s. IMO bfgminer is a really worthy program to add it into automated
tests/regression checks, etc.
P.P.S. and what about better fan/intensity control? Problem is that if ambient
is warm, about 25-26C, 57xx cards can make really annoying noise. Heat can be
reduced via intensity a bit but it works poorly and not really fine grained.
There is also overheat + hysteresis setting which can be (ab)used to cool down
GPU a bit but it makes fan to speed up and down in oscillating manner which is
also really annoying to hear.
Any proper tooling to hint DPM about max acceptable cooler rate or max allowed
GPU freq comparable to what Catalyst haves to offer in ADL? Preferred attitude
would be to reduce GPU core clocks if ambient is high and increase it if
ambient temp is low and TDP/fan setup permits. Its possible to achieve with
Catalyst, but Catalyst really stinks and really I want to get rid of it.
--
You are receiving this mail because:
You are the assignee for the bug.
--1416850983.3C35B3.16567
Date: Mon, 24 Nov 2014 17:43:03 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Comment # 36
on bug 72785
from Linux User
Got similar issues when trying scrypt. I have relatively recent bfgminer (~1
month old git build) and more or less recent graphics stack: 3.17 kernel, mesa
10.4 pre-release from Oibaf PPA and LLVM 3.5.1
I have bunch of HD5000 based cards, mostly HD5750/5770 and somesuch and R9 270.
Tests have shown bfgminer performs correctly when computing SHA256 and goes
about 80% of catalyst at 57xx and even better than that on R9 270.
However things are much worse when it comes to scrypt. I got impression open
driver can get issues if something aggressively using GPU VRAM.
Some observations about open drivers stack so far:
- If you set scrypt intensity too high, there is high risk GPU would lock up in
fatal way and crash (can happen on both 57xx and R9).
- It is also exceptionally unsafe to try sha256 with vectors=4 on HD 57xx. It
would be much slower than other vector settings anyway, but still indication of
some techmical problem lurking around.
- If I'm setting up intensity at reasonable levels, it does builds kernels and
computes BUT --benchmark ***NEVER*** accepts computed blocks, 100% reject rate.
If I reduce intensity - error rate goes down. But still no accepted blocks. If
I try CPU at same time, it computes several blocks at time frame where GPU
gives no results at all. This indicates computations are just going wrong.
p.s. IMO bfgminer is a really worthy program to add it into automated
tests/regression checks, etc.
P.P.S. and what about better fan/intensity control? Problem is that if ambient
is warm, about 25-26C, 57xx cards can make really annoying noise. Heat can be
reduced via intensity a bit but it works poorly and not really fine grained.
There is also overheat + hysteresis setting which can be (ab)used to cool down
GPU a bit but it makes fan to speed up and down in oscillating manner which is
also really annoying to hear.
Any proper tooling to hint DPM about max acceptable cooler rate or max allowed
GPU freq comparable to what Catalyst haves to offer in ADL? Preferred attitude
would be to reduce GPU core clocks if ambient is high and increase it if
ambient temp is low and TDP/fan setup permits. Its possible to achieve with
Catalyst, but Catalyst really stinks and really I want to get rid of it.
You are receiving this mail because:
- You are the assignee for the bug.
--1416850983.3C35B3.16567--
--===============0489801572==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0
cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK
--===============0489801572==--