GPU plot generator v2.0.0 Changelog: Kernel split to increase graphic cards compatibility (introduction of the <hashesNumber> parameter to batch hashes computations). OpenCL platforms and devices listing added. Platform and device selection added as generation parameters. Enhanced CPU and GPU support (removed the auto-selection and fallback). Clearer information display. Displaying the % and nonces/minutes while generating plots. README added with some basic build and run instructions. Makefile cleaned up. Windows x86 binaries: https://mega.co.nz/#!2BNDXY4L!jgwHDZXDJyFp2Jg5mN8sxtpplgXEInSMf1cQGbPc5lM Sources: https://mega.co.nz/#!LZs1RapR!6VGB1SssX5lFp8GX0bZmN2OH-MftLVzEAn1P1nKrdwA Please read the README provided with both the binaries and the sources. Your feedbacks are welcome, it greatly helps me. If you like this software, support me  Roadmap for the next versions (feel free to post your features/ideas) : Kernel enhancement to speed up plot generation (shabal core can be improved). Find a way to reduce the memory overhead caused by my workaround solution to bypass the per-thread local memory limit. Make a list of graphic cards along with their optimal parameters (needs your participation). >>>>>>> There is a dedicated topic on the new forum for the GPU plot generator http://burstforum.com/index.php?threads/gpu-plot-generator.45/ <<<<<<< Awesome! Just tested it out on Linux (Ubuntu 14), I had to modify a couple more things than what was in the readme: OPENCL_INCLUDE = ../_opencl/include
OPENCL_LIB = ../_opencl/lib/win/x86
CC = /c/_data/cryo/_apps/mingw/bin/g++
CC_FLAGS = -ansi -pedantic -W -Wall -std=c++0x -O3 -I$(OPENCL_INCLUDE)
LD = /c/_data/cryo/_apps/mingw/bin/g++
I changed these to my locations (also CC and LD needed to be changed): OPENCL_INCLUDE = ../opt/AMDAPPSDK-2.9-1/include
OPENCL_LIB = ../opt/AMDAPPSDK-2.9-1/lib/x86_64
CC = g++
CC_FLAGS = -ansi -pedantic -W -Wall -std=c++0x -O3 -I$(OPENCL_INCLUDE)
LD = g++
I attempted to do a "make dist" but it was complaining that the "bin" folder didn't exist. I created the bin folder manually, and then I was then able to issue a "make dist" and got the following: Compiling [Command.cpp]
Compiling [CommandGenerate.cpp]
Compiling [CommandHelp.cpp]
Compiling [CommandList.cpp]
CommandList.cpp:54:5: warning: unused parameter ‘p_args’ [-Wunused-parameter]
int CommandList::listPlatforms(const std::vector<std::string>& p_args) {
^
Compiling [gpuPlotGenerator.cpp]
Compiling [OpenclError.cpp]
Linking [bin/gpuPlotGenerator.exe]
Generating distribution Not sure if that is a critical issue or not, but I ran the app anyways.... and it appears to be GENERATING PLOTS on my AMD Radeon 7800! ./gpuPlotGenerator.exe generate 0 0 /media/twig/Burst_Coin_21/GPU_Plotter_v2.0.0/bin/plots 11111222223333344444 14670000 7335000 1000 64 1024 Also, not sure on the "hashes" (1024) number really compares to though On my AMD Radeon 7800!  WOOT! 121,000 nonces/minute! Did that ~3.5TB take 2 hours to finish? |
|
|
|
Okay, time for me to bitch aobut this.
I downloaded the GPU Plotter on page 443. I have WinZip on my computer (Windows 7 64 bit Pro).
When right clicking the files, I can't even get the option to open with WinZip.
So what the hell? Is this plotter made only for Linux? How do I open the files to install them?
it's a .7z file, not a .zip file. You need 7-zip to be able to extract it: http://www.7-zip.org/download.html.7z is a fairly common compression format which most are familiar with. Either way, 7-zip is a MUCH more robust compression application and I would suggest using 7-zip instead of WinZip in the future. Honestly, 7zip is the best compression/decompression freeware out there and even way better than Winzip or any paid version. |
|
|
|
Can everyone take a moment to tweet to Bittrex for our great coin?
I tweet'd them once the wallet update came out and still no response.... |
|
|
|
I am also getting 'error in step1 kernel launch' with the gpu plotter....
13.12 AMD drivers on 6950, here is my batch...
gpuplotgenerator generate 0 1 G:\SOLOminer\plots (account) 6660999400000 2800000 1000 128 1024
I get the gpu plotter to work on a HD6970, but it slow (500 nonce/min) or it freezes. Stagger at 1024, threads at 64 and hash at 1024 or 512. Not understanding exactly how the hash command works exactly in relation to plotting, stagger/hashes? Hey man This is my setting for a single 7970 GPU - seems to be the fastest/most stable. Higher hashes results in display driver crashing when playing a youtube video. This seems to be a good middleground and is actually a tad faster than higher hash settings. gpuplotgenerator.exe generate 0 1 plots ACC# (START_AT) (#_OF_NONCES) 2000 64 2040 What nonce/min are you achieving? |
|
|
|
My R9 280x can't work with 4096 stagger size... only with 1024 (((( wtf?
Strange it should work around the range of 2048 to 3072 normally at least. |
|
|
|
I am also getting 'error in step1 kernel launch' with the gpu plotter....
13.12 AMD drivers on 6950, here is my batch...
gpuplotgenerator generate 0 1 G:\SOLOminer\plots (account) 6660999400000 2800000 1000 128 1024
I get the gpu plotter to work on a HD6970, but it slow (500 nonce/min) or it freezes. Stagger at 1024, threads at 64 and hash at 1024 or 512. Not understanding exactly how the hash command works exactly in relation to plotting, stagger/hashes? |
|
|
|
Guys, i have a small overlap for 2 plots. Is it ok or I should re-plot?
Shouldn't be anything major and you should be fine. |
|
|
|
GPU plot generator v2.0.0 Changelog: Kernel split to increase graphic cards compatibility (introduction of the <hashesNumber> parameter to batch hashes computations). OpenCL platforms and devices listing added. Platform and device selection added as generation parameters. Enhanced CPU and GPU support (removed the auto-selection and fallback). Clearer information display. Displaying the % and nonces/minutes while generating plots. README added with some basic build and run instructions. Makefile cleaned up. Windows x86 binaries: https://mega.co.nz/#!2BNDXY4L!jgwHDZXDJyFp2Jg5mN8sxtpplgXEInSMf1cQGbPc5lM Sources: https://mega.co.nz/#!LZs1RapR!6VGB1SssX5lFp8GX0bZmN2OH-MftLVzEAn1P1nKrdwA Please read the README provided with both the binaries and the sources. Your feedbacks are welcome, it greatly helps me. If you like this software, support me Roadmap for the next versions (feel free to post your features/ideas) : Kernel enhancement to speed up plot generation (shabal core can be improved). Find a way to reduce the memory overhead caused by my workaround solution to bypass the per-thread local memory limit. Make a list of graphic cards along with their optimal parameters (needs your participation). >>>>>>> There is a dedicated topic on the new forum for the GPU plot generator http://burstforum.com/index.php?threads/gpu-plot-generator.45/ <<<<<<< we got to compile in windows :-( Only if you want to rebuild the source. Otherwise, the binaries work out of the box. |
|
|
|
How much system ram do you have? What Windows are you running? Are you using AMD 13.9 driver and APP SDK 2.9.1?
You should at least be able to get the same stagger size of your vram, 3GB/3072MB. I couldn't go higher than 4096 for stagger size and 128 threads. I'm running Windows 8.1.
I have 8GB (approx 1.4GB in use while plotting). Windows 8.1. Driver 13.251.9001.1001 and APP SDK 2.9.233.167. Try a clean uninstall with DDU driver cleaner, then try to install 13.9 with 2.9.1 APP SDK. That's how I got it to work for me. |
|
|
|
The GPU plot generator v2.0.0 will allow you to do that. I will release it in few hours at most. Be patient  Will this also fix the weird double memory problem? I was able to plot up to 2024 stagger with my 3GB 280x but anymore than that and I get the CL error. Strange thing is that looking at MSI Afterburner I'm only using 1.1GB on the card and less than 20% of my system RAM. The time it takes to look through the plots for valid shares is related to stagger size, right? I'm noticing that my systems aren't always able to go through all my plots before the end of some blocks. Most of my plots are at stagger 1000 because I was having problems going any higher with the Java miner. The "weird" double memory problem is due to the limited amount of local memory for each workgroup thread on the GPU side (it would require more than 260KB per thread, what is really big in the graphic cards world). The only way I found for now is to allocate another huge buffer (of (PLOT_SIZE + 16) * staggerSize bytes) that each workgroup thread can use to store the processing data. Thus, the amount of memory needed by the GPU plot generator is more than twice the normal amount. One solution to avoid this memory overhead is to find a mean to do the last algorithm step in an on-place fashion. I will try to work on that and on the kernel enhancement (to speed things up even more :p) for the 2.1.0 version. I get the error "[-61] Unable to create the OpenCL GPU generation buffer" with any stagger sizes above about 2000. Is that because of this memory problem or something else? How much system ram do you have? What Windows are you running? Are you using AMD 13.9 driver and APP SDK 2.9.1? You should at least be able to get the same stagger size of your vram, 3GB/3072MB. I couldn't go higher than 4096 for stagger size and 128 threads. I'm running Windows 8.1. surley if using the gpu to plot at stagger of 4096 but able to use java plotter to do 8191 its better to java plot all be it 3x as long because mining would run better due to larger stagger, right? To me, it never really made a difference. Once the plots were done, seeks and read seem to be the same. |
|
|
|
Can anybody help?
What does it mean???
//16Gb RAM. 2*4TB HDD.// [Running two miners]
"Uncaught error from thread [Uncaught error from thread [default-akka.actor.defau
lt-dispatcher-2] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabl
ed for ActorSystem[default]
default-akka.actor.default-dispatcher-4] shutting down JVM since 'akka.jvm-exit-
on-fatal-error' is enabled for ActorSystem[default]
java.lang.OutOfMemoryError: Java heap space"
Answered in the new forum ( 75 burst for signing up.)
Try to increase the heap size from -Xmx750 to -Xmx1024. |
|
|
|
The GPU plot generator v2.0.0 will allow you to do that. I will release it in few hours at most. Be patient Will this also fix the weird double memory problem? I was able to plot up to 2024 stagger with my 3GB 280x but anymore than that and I get the CL error. Strange thing is that looking at MSI Afterburner I'm only using 1.1GB on the card and less than 20% of my system RAM. The time it takes to look through the plots for valid shares is related to stagger size, right? I'm noticing that my systems aren't always able to go through all my plots before the end of some blocks. Most of my plots are at stagger 1000 because I was having problems going any higher with the Java miner. The "weird" double memory problem is due to the limited amount of local memory for each workgroup thread on the GPU side (it would require more than 260KB per thread, what is really big in the graphic cards world). The only way I found for now is to allocate another huge buffer (of (PLOT_SIZE + 16) * staggerSize bytes) that each workgroup thread can use to store the processing data. Thus, the amount of memory needed by the GPU plot generator is more than twice the normal amount. One solution to avoid this memory overhead is to find a mean to do the last algorithm step in an on-place fashion. I will try to work on that and on the kernel enhancement (to speed things up even more :p) for the 2.1.0 version. I get the error "[-61] Unable to create the OpenCL GPU generation buffer" with any stagger sizes above about 2000. Is that because of this memory problem or something else? How much system ram do you have? What Windows are you running? Are you using AMD 13.9 driver and APP SDK 2.9.1? You should at least be able to get the same stagger size of your vram, 3GB/3072MB. I couldn't go higher than 4096 for stagger size and 128 threads. I'm running Windows 8.1. |
|
|
|
Been running fine for me at a stagger size of 4096 and 128 thread. While system ram usage is at 6GB out of 8GB. I had issue with my miner closing, so I upped the heap size from 750 to 1024 and it's mining fine now.
Heap size? The miner would crash after a period of time. The -Xmx in the miner is default 750, I put 1024 and it hasn't gave me any issues since. |
|
|
|
The GPU plot generator v2.0.0 will allow you to do that. I will release it in few hours at most. Be patient Will this also fix the weird double memory problem? I was able to plot up to 2024 stagger with my 3GB 280x but anymore than that and I get the CL error. Strange thing is that looking at MSI Afterburner I'm only using 1.1GB on the card and less than 20% of my system RAM. The time it takes to look through the plots for valid shares is related to stagger size, right? I'm noticing that my systems aren't always able to go through all my plots before the end of some blocks. Most of my plots are at stagger 1000 because I was having problems going any higher with the Java miner. Been running fine for me at a stagger size of 4096 and 128 thread. While system ram usage is at 6GB out of 8GB. I had issue with my miner closing, so I upped the heap size from 750 to 1024 and it's mining fine now. |
|
|
|
What command to use 2 280x for a bat file to use them all ?
anyone ? read the thread  Miner for multiple graphics dont exist yet. And, few pages back there was a configuration for R9 R280x.. The GPU plot generator v2.0.0 will allow you to do that. I will release it in few hours at most. Be patient Will it be compatible with more cards than just the AMD GCN cards? For me, it works for a HD7730 1GB(2048nonces/min) and HD7970(12288nonce/min). I tried a HD6950 2GB and HD6970, both freeze the system. Would be nice if the was compatible with both AMD and Nvidia. Thanks for all the great work, much appreciated by the community. |
|
|
|
I think that if Windows needs that memory it will start cleaning seeing that its not being used anymore you mean that if i add other TB, that mem won't increase farther? It might increase further. But Windows will report that its being used to keep files in memory in case you use the app again. So, opening the miner again should increase the ram usage a bit, but not as it would when you started it the first time. This is pure theory, so I might be wrong. Unfortunately it doesn't seem to work this way. Windows can cache so much that the miner can crash due to bad allocs. And then it still doesn't release the memory after the miner is down. It seems to be a problem that gets worse over time as windows sees you keep reading the same file/s I was able to keep it under control by disabling prefetching and superfetching as detailed here: https://bitcointalk.org/index.php?topic=731923.msg8635800#msg8635800 , but that didn't seem to work for Amph Is it a pagefile issue in his case possibly? Windows 8/8.1 does not seem to have the issue as Amph has in Windows 7. |
|
|
|
Just got my 8 pieces of 5TB (Seagate) and started plotting now. With GPU Plotter, I'm should be able to complete 40TB PLOT in a week. Should get 28000 BURST per day next week onward so with current rate I'm should get 0.112 BTC per day just purely by POC. ROI should be 30 days from next week.  . Happy POC. You have failed to take into account the major price crash coming this weekend when serious problems are revealed in the POC algorithm. What are you talking about? When you state something like this you better have proof to back up your claims. There are no problems with the PoC algo. VHD exploits There are no VHD exploits. To have a 2 Tb VHD you need to have that on a drive with 2 Tb actual free space. Stop spreading fud. You can't plot 2 Tb on a 500 Gb drive. You people be bringing out random FUD. VHD is primarily just a virtual file format with a limitation of 2TB. As fanepatent said, how would you put that on a smaller footprint of storage? How can you spoof the process to trick the miner? It's like asking an Elephant to come out of your rear. |
|
|
|
|
I just tested a HD7730 1GB, I sold most of my GCN gpu mining cards and only have a 7970 left, the gpu plotter works on it. Stagger size of 512 with 64 threads doing 2048 nonce/min. So, for sure GCN cards work on this gpu plotter with AMD 13.9 driver/2.9.1 APP SDK and maybe the 750/750ti. I guess I better get another HD7950/7970 or 280x/290/290x. lol
Update: Make sure to turn of all the graphical Windows stuff, that tends to crash the driver with GCN cards with low vram. Guess anything less than 2GB, ie. 1GB cards.
|
|
|
|
|
HD6950 2GB and HD6970 don't work with the gpu plotter, even on 13.9 with APP SDK 2.9.1. It freezes and probably because of the architecture isn't GCN/compute based like the 7xxx's and R series AMD's. I tried to even use 512 stagger size and 8 threads as the lowest settings. So, no go at the moment with VLIW cards at the moment. This might work on the 750/750ti, just an assumption.
|
|
|
|
hey guys, I tried the GPU plotter but GPU driver crashes every time it starts plotting  second thing, I've noticed kinda big amount of data being transfered while plotting/mining burst. It can download even about 500MB per day, while mining other coins it was about 10MB/day. It might put me out from burst train to the moon, because I have limited data transfer:( Does it download data only while plotting or while mining? Try with different version of catalyst software. There are still different version of gpu to be tested but my mate successfully plotting with 290x twin frozer x10 times faster than his i7 processor. If you gpu is same model, pm for specs I tried on 2x 7950 and the driver was crashing. Then I tried on another pc with single 7950 and it doesn't even start to plot, it crashes after 'Building OpenCL program'. what catalyst version does your mate have? I'm pretty sure I have the newest drivers. Supposedly they are on 13.9. I just did a clean uninstall and installing 13.9 on a HD7970. Are you on Win7 or Win8.1 SpeedDemon? And its not like I bought the 5960X for plotting ;p I wish I owned a 5960X...lfmao.... I'm running Win8.1 64-bit.... |
|
|
|
|
Show Posts
