which are the required dlls?
amdocl.dll for sure
what else?
amd_opencl32.dllamdocl.dll for sure
what else?
amd_opencl64.dll
amdocl.dll
amdocl12cl64.dll
amdocl64.dll
Topic: ethminer-0.9.41-genoil-1.1 - page 67. (Read 397360 times)
amd_opencl64.dll
amdocl.dll
amdocl12cl64.dll
amdocl64.dll
afaik its algo-related
Still noone was able to implement the algo in faster way than referent design. At least not publicly available
Still noone was able to implement the algo in faster way than referent design. At least not publicly available
Porting the dagger creation code to rhe gpu is low pri. But I think I make the existing code 200 times faster by using memory mapped files.
200 times, which translate in what kind of boost in the hashrate? nvidia was always not optimized well, that's why amd could match it with the same power consumption...You save some seconds when you generate and load the dagger. Perhaps it can be generated realtime. But still in the cpu, and your rig need 6-8gb of ram.
so no real boost on the hashrate? i guess it's because of the access to the memory, if i'm not mistaken, i've read they have a problem related to this compared to amd
Porting the dagger creation code to rhe gpu is low pri. But I think I make the existing code 200 times faster by using memory mapped files.
200 times, which translate in what kind of boost in the hashrate? nvidia was always not optimized well, that's why amd could match it with the same power consumption...You save some seconds when you generate and load the dagger. Perhaps it can be generated realtime. But still in the cpu, and your rig need 6-8gb of ram.
Porting the dagger creation code to rhe gpu is low pri. But I think I make the existing code 200 times faster by using memory mapped files.
200 times, which translate in what kind of boost in the hashrate? nvidia was always not optimized well, that's why amd could match it with the same power consumption...
Porting the dagger creation code to the gpu is low pri. But I think I make the existing code 200 times faster by using memory mapped files.
Will ethminer be made to not use DAG files as the latest update in separate dual miner has no DAG file creation and uses it on GPU using Claymore's Dual Miner. Was wondering if you guys on ethminer will follow suite and become DAG free on system?
it will be released without the need to create dag, by SP, check his thread, he still need to test some things
Will ethminer be made to not use DAG files as the latest update in separate dual miner has no DAG file creation and uses it on GPU using Claymore's Dual Miner. Was wondering if you guys on ethminer will follow suite and become DAG free on system?
which are the required dlls?
amdocl.dll for sure
what else?
amdocl.dll for sure
what else?
which is the best AMD drivers version to use with 1.0.7 miner?
i have a pair of undervolted gigabyte 280xs that dont like newer drivers. i´m still using 14.4 as i can control gpu and memclock with it.
i cant underclock gpu with 15.7 and cards get sick at default speeds.
Hashrate is kinda low with 14.4 drivers... 18mh/s at best.
Copy the 15.12 dll files to miner folder. İt'll work. Anybdy knows the latest drivers(for 390) can possible downclock the core-mem clocks.15.12 and 15.71.1 don't let the downclok.pls share.it's driver bug . don't wanna try the all srivers. i have a pair of undervolted gigabyte 280xs that dont like newer drivers. i´m still using 14.4 as i can control gpu and memclock with it.
i cant underclock gpu with 15.7 and cards get sick at default speeds.
Hashrate is kinda low with 14.4 drivers... 18mh/s at best.
which is the best AMD drivers version to use with 1.0.7 miner?
i have a pair of undervolted gigabyte 280xs that dont like newer drivers. i´m still using 14.4 as i can control gpu and memclock with it.
i cant underclock gpu with 15.7 and cards get sick at default speeds.
Hashrate is kinda low with 14.4 drivers... 18mh/s at best.
i have a pair of undervolted gigabyte 280xs that dont like newer drivers. i´m still using 14.4 as i can control gpu and memclock with it.
i cant underclock gpu with 15.7 and cards get sick at default speeds.
Hashrate is kinda low with 14.4 drivers... 18mh/s at best.
Can someone point me to latest Win10 driver for 750Ti better speed?
Genoil, do you think that generating DAG in-memory or chunks can help NV cards?
Genoil, do you think that generating DAG in-memory or chunks can help NV cards?
cmake -DBUNDLE=cudaminer -DCOMPUTE=30 -DCUDA_HOST_COMPILER=/usr/bin/gcc-4.9 ..
worked on my testbench on 15.10 the server is still down need to try it there to.
i did a try on 16.04 but got som errors. used the same cmake a on 15.10
[ 11%] Built target ethash
[ 51%] Built target devcore
[ 57%] Built target ethstratum
[ 59%] Building NVCC (Device) object libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o
[ 66%] Built target ethash-cl
nvcc fatal : redefinition of argument 'std'
CMake Error at ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o.cmake:207 (message):
Error generating
/home/mattias/cpp-ethereum/build2/libethash-cuda/CMakeFiles/ethash-cuda.dir//./ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o
libethash-cuda/CMakeFiles/ethash-cuda.dir/build.make:63: recipe for target 'libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o' failed
make[2]: *** [libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o] Error 1
CMakeFiles/Makefile2:350: recipe for target 'libethash-cuda/CMakeFiles/ethash-cuda.dir/all' failed
make[1]: *** [libethash-cuda/CMakeFiles/ethash-cuda.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 66%] Built target BuildInfo.h
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2
worked on my testbench on 15.10 the server is still down need to try it there to.
i did a try on 16.04 but got som errors. used the same cmake a on 15.10
[ 11%] Built target ethash
[ 51%] Built target devcore
[ 57%] Built target ethstratum
[ 59%] Building NVCC (Device) object libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o
[ 66%] Built target ethash-cl
nvcc fatal : redefinition of argument 'std'
CMake Error at ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o.cmake:207 (message):
Error generating
/home/mattias/cpp-ethereum/build2/libethash-cuda/CMakeFiles/ethash-cuda.dir//./ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o
libethash-cuda/CMakeFiles/ethash-cuda.dir/build.make:63: recipe for target 'libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o' failed
make[2]: *** [libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o] Error 1
CMakeFiles/Makefile2:350: recipe for target 'libethash-cuda/CMakeFiles/ethash-cuda.dir/all' failed
make[1]: *** [libethash-cuda/CMakeFiles/ethash-cuda.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 66%] Built target BuildInfo.h
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2
I got the NVCC fatal STD error too when building with cmake 3.5.1 but I finally got it compiled on my Ubuntu 16.04 laptop using the following steps:
- removed cmake 3.5.1
- downloaded cmake 3.2.2, built it from source and installed it
- added the following line as the first line of CMakeLists.txt:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_FORCE_INLINES")
And that was that. I didn't use any special flags and arguments to build it, just the "sudo cmake -DBUNDLE=cudaminer"
I still haven't tried this on my mining rig though, it was just a test compile on my laptop.
Yes this was my question when I switched to Dwarfpool a few weeks ago and read their FAQ the first time.
Meanwhile I can also confirm that Dwarfpools proxy and Genoil's 1.0.7 are a very effective team. No problems and constant high hashrate.
With 51 MH/s I get 88 - 111 shares/h. With Claymore's I never reached more than 92.
Meanwhile I can also confirm that Dwarfpools proxy and Genoil's 1.0.7 are a very effective team. No problems and constant high hashrate.
With 51 MH/s I get 88 - 111 shares/h. With Claymore's I never reached more than 92.
at Dwarfpools FAQ I can read,
"Low hashrate
If your calculated speed below 60% threshold over a long period of time, you send low amount of shares.
It's because of bug in some versions of ethminers. Just restart miner. Also don't use buggy Genoil v1.0.4"
are these bugs in "buggy Genoil 1.0.4" fixed at actual 1.0.7?
"Low hashrate
If your calculated speed below 60% threshold over a long period of time, you send low amount of shares.
It's because of bug in some versions of ethminers. Just restart miner. Also don't use buggy Genoil v1.0.4"
are these bugs in "buggy Genoil 1.0.4" fixed at actual 1.0.7?
My miner does not even support the weird dwarfpool "stratum". I think that's what he's referring to.
SAME HERE--
I use the python-based proxy above with no problems. It is easy to set up. --scryyptr
at Dwarfpools FAQ I can read,
"Low hashrate
If your calculated speed below 60% threshold over a long period of time, you send low amount of shares.
It's because of bug in some versions of ethminers. Just restart miner. Also don't use buggy Genoil v1.0.4"
are these bugs in "buggy Genoil 1.0.4" fixed at actual 1.0.7?
"Low hashrate
If your calculated speed below 60% threshold over a long period of time, you send low amount of shares.
It's because of bug in some versions of ethminers. Just restart miner. Also don't use buggy Genoil v1.0.4"
are these bugs in "buggy Genoil 1.0.4" fixed at actual 1.0.7?
My miner does not even support the weird dwarfpool "stratum". I think that's what he's referring to.
But... The usual way will be generate DAG, verify (somehow), generate CRC, then write to disk
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
I'm not assuming he's doing it the wrong way. I was just trying to figure out an easy way to do something similar with the lowest amount of effort involved
. But on second thought you are right. CRC is very useful. The problem with my suggestion is that it would only validate DAG integrity upon finding a solution. It would not see that a solution was not found because of a corrupted DAG
On my weak CPU it takes about 8 sec, it's awesome!
I don't understand how, but it works, may be because he creates it directly on RAM and don't store to disk.
It's generated directly on the GPU. Very well done. I had a half-hearted attempt at it a while back (with a different goal in mind) but it was a failed experiment
Can you implement this feature for nvidia this is very useful.
I'm thinking about it, but I don't have much time.
But... The usual way will be generate DAG, verify (somehow), generate CRC, then write to disk
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
I'm not assuming he's doing it the wrong way. I was just trying to figure out an easy way to do something similar with the lowest amount of effort involved
. But on second thought you are right. CRC is very useful. The problem with my suggestion is that it would only validate DAG integrity upon finding a solution. It would not see that a solution was not found because of a corrupted DAG
On my weak CPU it takes about 8 sec, it's awesome!
I don't understand how, but it works, may be because he creates it directly on RAM and don't store to disk.
It's generated directly on the GPU. Very well done. I had a half-hearted attempt at it a while back (with a different goal in mind) but it was a failed experiment
Can you implement this feature for nvidia this is very useful.
But... The usual way will be generate DAG, verify (somehow), generate CRC, then write to disk
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
I'm not assuming he's doing it the wrong way. I was just trying to figure out an easy way to do something similar with the lowest amount of effort involved
. But on second thought you are right. CRC is very useful. The problem with my suggestion is that it would only validate DAG integrity upon finding a solution. It would not see that a solution was not found because of a corrupted DAG
On my weak CPU it takes about 8 sec, it's awesome!
I don't understand how, but it works, may be because he creates it directly on RAM and don't store to disk.
It's generated directly on the GPU. Very well done. I had a half-hearted attempt at it a while back (with a different goal in mind) but it was a failed experiment
But... The usual way will be generate DAG, verify (somehow), generate CRC, then write to disk
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
I'm not assuming he's doing it the wrong way. I was just trying to figure out an easy way to do something similar with the lowest amount of effort involved
. But on second thought you are right. CRC is very useful. The problem with my suggestion is that it would only validate DAG integrity upon finding a solution. It would not see that a solution was not found because of a corrupted DAG
On my weak CPU it takes about 8 sec, it's awesome!
I don't understand how, but it works, may be because he creates it directly on RAM and don't store to disk.
Jump to: