NVIDIA: fix wrong number of threads #2003
Conversation
In the cuda backend for monero we start always twice as much threads as needed. Those threads are than removed after the AES matrix is copied to the shared memory. Never the less it is the result of an copy past bug. - start correct number of threads for `monero`
|
CC-ing: @xmrig |
|
@xmrig brings Fermi to 75% perf of CN1 ("v7") instead of 50% |
|
Not less then 3% hasrate back for Maxwell (GTX 970). Good job, thanks! |
|
No, the hashrate fell, while "threads" : 8, "blocks" : 128, for GTX 980 at 2.5.1 513 H / s 2.5.2 500H / s Monero v8 |
|
This is not possible if your setup has not changed. Before 2x the needed
threads are spawned. Now this is corrected.
|
|
Such poor results on 2.5.2 because I use compiled CUDA 8.0, before on CUDA 9.0 the results were quite bad, the hashrate was 1.5-2 times lower. Looks like this bug already exists, you just now fixed in 2.5.2, now tested with CUDA 9.0, Hasrat increased to 522 H/s. Here's the same config on 2.5.1 CUDA 9.0: Benchmark nvidia Thread 0: 286.9 H/S |
|
CUDA 8.0 is non optimal for Maxwell, only really still supported for Fermi. CUDA 8.0 never worked very well via backward compatibility after CUDA 9.1 was in the drivers. So compiled for CUDA 8.0 works best on last available CUDA 8.0-containing driver so ~386.28 Compile for whatever the driver contains always works best (check driver release note under supported technologies, it shows CUDA version bundled) Backward compatibility is a crutch at best. |
|
This is the latest available in the Nvidia archive |
|
Also pending accept, new docs section here |
|
xmr stack does not correctly detect the CUDA version of the Nvidia driver. With 388.13 miner writes at startup (9.1/9.0), 388.71 (9.2/9.0). A should have been (9.0/9.0) and (9.1/9.0) respectively. |
|
are you sure. the miner is printing te value provided by the driver. If
cuda has no bug I think its correct
sergneo <notifications@github.com> schrieb am So., 28. Okt. 2018, 18:40:
… xmr stack does not correctly detect the CUDA version of the Nvidia driver.
With 388.13 miner writes at startup (9.1/9.0), 388.71 (9.2/9.0). A should
have been (9.0/9.0) and (9.1/9.0) respectively.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2003 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYsxtpK_OL6pp335D-m3e5hIXn1ehAj9ks5upewagaJpZM4X3WJX>
.
|
|
The release notes PDFs for 388.13/388.71 do claim such, however it must be a documentation lag as what the code says if from the driver itself so... 388.13 has 9.1 and 388.71 has 9.2 despite the docs. There was the one other crossover noted in the new The release notes PDF for 388.71 does say 9.1 however it must be a documentation lag as what the code says is from the driver itself so... 388.13 has 9.1 despite the docs. |
|
Indeed, for example, driver 388.19 is installed with CUDA Toolkit 9.1. PDF is misleading. |
…erOfThreads NVIDIA: fix wrong number of threads
In the cuda backend for monero we start always twice as much threads as needed.
Those threads are than removed after the AES matrix is copied to the shared memory.
Never the less it is the result of an copy past bug.
monero