Search content
Sort by
Showing 20 of 21 results by deathlire
Hi, use pre-GCN cards 5870 gpu0 65% use gpu1 100% use Because it happens?
https://pasteboard.co/HhTRNaj.png
https://pasteboard.co/HhTRNaj.png
Settings the same for both? and not using a crossfire situation?
Settings same *2 not use crossfire
Are you using first gpu to do anything graphically intensive like watching video's or webpages, or games?
Also have you tried just using only that card to mine and see if it still stays around that hash rate by itself?
It could be several factors.. perhaps even the memory or just plain old "silicon lottery" losing on the first card..
Maybe Dok can help with this one though.
I am a greedy ba*tard. Why I cant use this command in .bat file anymore?
It was taken out in the past few versions.. Is 1 minute every couple hours really that bad?
Hi, use pre-GCN cards 5870 gpu0 65% use gpu1 100% use Because it happens?
https://pasteboard.co/HhTRNaj.png
https://pasteboard.co/HhTRNaj.png
Settings the same for both? and not using a crossfire situation?
1.) Nope, and don't think he's going to, but never know later on.
Far as claymore 9.7 goes.. probably some shady coding he doesn't want anyone to know, or just wants to keep it away from everyone for fee's possibly, never know.
2.) I did notice on 14.4 drivers that my vram was more around 1GB and switching over to 15.7.1 it has 2047MB for some reason detected on all the other miners, but claymore did find 2047 on both drivers..
so determining how it gets the m1 and m2 should be an easy fix, I know for a fact I only have 512MB dedicated, which is also shown in m2.. I'll have a look at which way xmrig/stak is polling the memory. iirc this has been an issue with those for quite awhile.. I've never been able to get any miner to work without dying except for claymore on 15.7.1, and believe me I am trying to find a workaround that doesn't involve switching and mangling drivers around to make something work.
How much memory does 14.4 show you compared to 15.7.1?
1) The thing is, Claymore recently removed the devfee from his miner (v11.3). Apparently he's leaving the scene, which means no more support.Far as claymore 9.7 goes.. probably some shady coding he doesn't want anyone to know, or just wants to keep it away from everyone for fee's possibly, never know.
2.) I did notice on 14.4 drivers that my vram was more around 1GB and switching over to 15.7.1 it has 2047MB for some reason detected on all the other miners, but claymore did find 2047 on both drivers..
so determining how it gets the m1 and m2 should be an easy fix, I know for a fact I only have 512MB dedicated, which is also shown in m2.. I'll have a look at which way xmrig/stak is polling the memory. iirc this has been an issue with those for quite awhile.. I've never been able to get any miner to work without dying except for claymore on 15.7.1, and believe me I am trying to find a workaround that doesn't involve switching and mangling drivers around to make something work.
How much memory does 14.4 show you compared to 15.7.1?
It sucks that he doesn't want to release the source code...
2) 14.4 detects the entire memory, while 15.7.1 says only 384MB of VRAM is available.
I really want to know how Claymore v9.7 detects the entire memory with 15.7.1 drivers... yet another secret hiding in the closed-source binary.
Yeah I did notice he took out the fee's at least for 3GB or under cards i think..
But how much memory do you have exactly in total when it's correct? Then I might be able to finally dig into it and see if i can get something going.
Since mines actually doing the opposite for some reason.. on 14.4 it's showing 1024 iirc, and 2047 for 15.7.1...not sure why it isn't 2048 though..
Hello,got some question.
On v7 algo,what i should to oc between core clock or memory clock?
thank you.
On v7 algo,what i should to oc between core clock or memory clock?
thank you.
core by 5-10Mhz until it's no longer stable..then if you want put a little more volts into it until stable..
once you reach where both kill it.. go back about 10Mhz and maybe even lower volts a bit..if you are going
for extreme anyways, also watch for heat..but huge heat isn't a good thing..means more power wasted..
when sometimes you can get the same with clocking lower.
Is this for oc GPU clock or Memory clock?
GPU Clock is raised until things just refuse to work properly, then you can up the core voltage to keep going up until it is no longer stable there either.. don't raise voltage by much, since it can be devastating to your card or motherboard even..
Raising up GPU core clock until stable as normal, and then raising the memory clock until it stays stable without touching voltages may be better in your case. Try to learn about GPU OC'ing either from tomshardware or youtube ..pretty much anywhere with google.. Hope this helps
*NOTE* Don't play with voltages until you know what you are doing seriously. Also I hold no responsibility for what I've said in this post.
Wow thank you very much. 
We can expect it in the next version?
Can you give me some advice for fine tuning my r7 370-s and rx 470s for all cryptonight versions, because on all types of algos, my desktop is little freezing, even on default settings, or even a much smaller intensity.
We can expect it in the next version?Can you give me some advice for fine tuning my r7 370-s and rx 470s for all cryptonight versions, because on all types of algos, my desktop is little freezing, even on default settings, or even a much smaller intensity.
Nothing really can help that without the kernels that are executed. This also happens on any other gpu miner as well right?
For everyone:
I'll explain a bit about OpenCL and how the "kernels" work a bit..
The kernel or "payload/work" is sent to the video card and is kind of like a singular pipe, okay that analogy sucked, but imagine
with all the "CU" Compute Units available.. the work from these kernels are sort of like threads on a miniature scale and they all
work according to the OpenCL standard (Hopefully) But it's like a faucet.. turn it on or off.. also you may need to turn down intensity
even more until you have a freeze free desktop which costs all the extra hashing power you would have had. Remember on SRBMiner you can
use decimals so don't forget that ex: "intensity 20.3" or what have you.
I've left an earlier comment on a "low intensity" mode that is about splitting
up one big time job to do work into much smaller timed jobs and if done right, it really shouldn't have any negative impact on hashing speed,
or at least any notable impacts on it so that could be maybe be a modulation of 100ms or 1/10th a second per command queue or even smoother
by doing it roughly ~16.67ms for 1/60th a second, but I'm getting a bit to technical trying to explain it.. Anywho, a good way to perhaps implement
this would be to take an argument for say --desktop_mode
I have a couple of questions:
1) Has doktor83 released the source code of SRBminer?
IMHO, it's crucial to have the source code of any possible improvements, so that we don't end up with a Claymore v9.7 situation (the author has even refused BTC/ETH donations to release the source code to the community).
2) How is it possible that Claymore v9.7 can use the entire memory with 15.7.1 Catalyst driver, but other miners cannot do the same? Is there any OpenCL hack that makes 14.4 drivers redundant?
I don't even know if it's possible to copy/paste the OpenCL dll file from 14.4 to 15.7.1 or something like that to detect the memory properly...
1.) Nope, and don't think he's going to, but never know later on.
Far as claymore 9.7 goes.. probably some shady coding he doesn't want anyone to know, or just wants to keep it away from everyone for fee's possibly, never know.
2.) I did notice on 14.4 drivers that my vram was more around 1GB and switching over to 15.7.1 it has 2047MB for some reason detected on all the other miners, but claymore did find 2047 on both drivers..
so determining how it gets the m1 and m2 should be an easy fix, I know for a fact I only have 512MB dedicated, which is also shown in m2.. I'll have a look at which way xmrig/stak is polling the memory. iirc this has been an issue with those for quite awhile.. I've never been able to get any miner to work without dying except for claymore on 15.7.1, and believe me I am trying to find a workaround that doesn't involve switching and mangling drivers around to make something work.
How much memory does 14.4 show you compared to 15.7.1?
Hey, do you know how set difficulty on 1.4.6 miner I'm mining IPBC I set port everything working fine but difficulty going up with geometrical progress like "10-20-40-80"and going up . I believe in miner 1.2.1 one of the first SRB miner you put (wallet address) . (Difficulty) how you do that on new SRB 1.4.6
That depends on your pool, and if they have a diff setting.. it's not a miner issue.
But should be like WALLET_ADDRESS+DIFF or as you said WALLET_ADDRESS.DIFF and some even use WALLET_ADDRESS.RIG_NAME+DIFF
Look at your local pool to find out.
Hello,got some question.
On v7 algo,what i should to oc between core clock or memory clock?
thank you.
On v7 algo,what i should to oc between core clock or memory clock?
thank you.
core by 5-10Mhz until it's no longer stable..then if you want put a little more volts into it until stable..
once you reach where both kill it.. go back about 10Mhz and maybe even lower volts a bit..if you are going
for extreme anyways, also watch for heat..but huge heat isn't a good thing..means more power wasted..
when sometimes you can get the same with clocking lower.
Code:
"gpu_conf" :
[
{ "id" : 0, "intensity" : 0, "worksize" : 8, "threads" : 1},
{ "id" : 1, "intensity" : 20, "worksize" : 16, "threads" : 2}, <<-- shouldn't have a comma. took this out
}
[
{ "id" : 0, "intensity" : 0, "worksize" : 8, "threads" : 1},
{ "id" : 1, "intensity" : 20, "worksize" : 16, "threads" : 2}, <<-- shouldn't have a comma. took this out
}
that worksize and threads shouldn't be that high.. but anyways 1st card is given an auto intensity setting and 2nd is getting 20.. by a 15 workload and 2 threads try 1 thread, or lower to 8 ws
32 is a bunch.
Actually what is card 0 and card 1 doing? #0 should be doing just optimal settings with the 0 switch.. perhaps you want to have 2 threads on it as well?
it's all about testing..
Trying this miner for the first time. It doesn't like my config. What am I doing wrong? It tells me I have a parse error
"cryptonight_type" : "normalv7",
"intensity" : 0,
"double_threads" : true,
"target_temperature" : 0,
"gpu_conf" :
[
{ "id" : 0, "intensity" : 0, "worksize" : 8, "threads" : 1},
{ "id" : 1, "intensity" : 20, "worksize" : 16, "threads" : 2}, <<-- shouldn't have a comma.
}
] <-- probably a brace here
"cryptonight_type" : "normalv7",
"intensity" : 0,
"double_threads" : true,
"target_temperature" : 0,
"gpu_conf" :
[
{ "id" : 0, "intensity" : 0, "worksize" : 8, "threads" : 1},
{ "id" : 1, "intensity" : 20, "worksize" : 16, "threads" : 2}, <<-- shouldn't have a comma.
}
] <-- probably a brace here
look in quote
If you didn't build the whole thing your own that is, check out a line that has i believe a "224u" line in it assigning a value to memHash..which is padding for a 256 byte chunk..so it should be something that takes it out at way before 255 and bam, well just comment it off and add + 1; How stable is it? i've only ran it an hour... but if it can do ~2-5 hashes for me.. imaging what it may do for multiple not using the basis of bits..
try a good test on a more speedy video card with that..doing before fix and after fix results and of course will it stay running for an hour or 300?
it's in auto config... source.
Code:
const size_t perThread = hashMemSize + 1u; // +224u; // Seems to be a speed improvement over padding and probably half unstable / more shares.
try a good test on a more speedy video card with that..doing before fix and after fix results and of course will it stay running for an hour or 300?
it's in auto config... source.
are you referring to xmrig ?
Yeah, sorry I didn't specify, it's pretty late here.. and if it's not added as + 1.. it would fit in a 32 byte address.. so nothing would be wasted.. should be an 8 times increase.. at least in memory speed.. if it fits without +1 ..and if there is some need to have 256 byte for a video's memory.. I'll understand, but would like to wonder why.
But if you made your own, and isn't forked or anything from them.. is that how you have it somewhat? maybe 32 or 64?
that is not aligning, that is meta data size added. You probably got better results because you use more free mem by adding 1 than 224
unsigned int size can be max 0xffffffff, so lets take for ex. normal cn mem, its 2mb (0x200000 or 2097152 in decimal), so by adding 224 you get 2097376 and that is far away from unsigned int max
oh and you are talking probably about bits (32 bit, 256bit etc), not bytes.
i tried +1, and nothing changes on rx580 8g, get the same hashrate
of course i may be wrong
It is bits in machine code, but not by memory chunks grabbed.. but any whose.. i did not know it took exactly 2MB for CN.. I've only noticed it in readme files for that's how much a thread takes to add on to memory.. I'm not really talking about how big it can go.. it should be how small can it go and how quickly can it get generated/solved across the whole board, I'm pretty honest here, I do not know that much about the actual algorithm or anything, but turning things into more workable chunks to whatever size can diminish time for things to complete depending on it's assignment..which isn't in just one place in the code.. but after changing that did you get any errors from results? and or notice any raise in memory availability? and yeah even far from normal int.. guess I'm just used to asm and C. and using lowest forms of memory possible for any code improvement.. i always use int8_t or uint_16t from the stdint.h header and C is very unforgiving with memory, but kind of rewarding as well.
If you didn't build the whole thing your own that is, check out a line that has i believe a "224u" line in it assigning a value to memHash..which is padding for a 256 byte chunk..so it should be something that takes it out at way before 255 and bam, well just comment it off and add + 1; How stable is it? i've only ran it an hour... but if it can do ~2-5 hashes for me.. imaging what it may do for multiple not using the basis of bits..
try a good test on a more speedy video card with that..doing before fix and after fix results and of course will it stay running for an hour or 300?
it's in auto config... source.
Code:
const size_t perThread = hashMemSize + 1u; // +224u; // Seems to be a speed improvement over padding and probably half unstable / more shares.
try a good test on a more speedy video card with that..doing before fix and after fix results and of course will it stay running for an hour or 300?
it's in auto config... source.
are you referring to xmrig ?
Yeah, sorry I didn't specify, it's pretty late here.. That is my own code adjustment and if it's not added as + 1.. it would fit in a 32 byte address..(Theoretically) so nothing would be wasted.. should be an 8 times increase.. at least in memory speed.. if it fits without +1 ..and if there is some need to have 256 byte for a video's memory.. I'll understand, but would like to wonder why. and if so.. instead padding memory like the ones before have done.. actually times the hash by 7 or 8 beforehand filling up 256 registers almost and then padding if necessary... many ways to come to something fun and workable i suppose.
But if you made your own, and isn't forked or anything from them.. is that how you have it somewhat? maybe 32 or 64?
If you didn't build the whole thing your own that is, check out a line that has i believe a "224u" line in it assigning a value to memHash..which is padding for a 256 byte chunk..so it should be something that takes it out at way before 255 and bam, well just comment it off and add + 1; How stable is it? i've only ran it an hour... but if it can do ~2-5 hashes for me.. imaging what it may do for multiple not using the basis of bits..
try a good test on a more speedy video card with that..doing before fix and after fix results and of course will it stay running for an hour or 300?
it's in auto config... source.
Code:
const size_t perThread = hashMemSize + 1u; // +224u; // Seems to be a speed improvement over padding and probably half unstable / more shares.
try a good test on a more speedy video card with that..doing before fix and after fix results and of course will it stay running for an hour or 300?
it's in auto config... source.
Wow thank you very much. We can expect it in the next version?
Can you give me some advice for fine tuning my r7 370-s and rx 470s for all cryptonight versions, because on all types of algos, my desktop is little freezing, even on default settings, or even a much smaller intensity.
We can expect it in the next version?Can you give me some advice for fine tuning my r7 370-s and rx 470s for all cryptonight versions, because on all types of algos, my desktop is little freezing, even on default settings, or even a much smaller intensity.
Nothing really can help that without the kernels that are executed. This also happens on any other gpu miner as well right?
For everyone:
I'll explain a bit about OpenCL and how the "kernels" work a bit..
The kernel or "payload/work" is sent to the video card and is kind of like a singular pipe, okay that analogy sucked, but imagine
with all the "CU" Compute Units available.. the work from these kernels are sort of like threads on a miniature scale and they all
work according to the OpenCL standard (Hopefully) But it's like a faucet.. turn it on or off.. also you may need to turn down intensity
even more until you have a freeze free desktop which costs all the extra hashing power you would have had. Remember on SRBMiner you can
use decimals so don't forget that ex: "intensity 20.3" or what have you.
I've left an earlier comment on a "low intensity" mode that is about splitting
up one big time job to do work into much smaller timed jobs and if done right, it really shouldn't have any negative impact on hashing speed,
or at least any notable impacts on it so that could be maybe be a modulation of 100ms or 1/10th a second per command queue or even smoother
by doing it roughly ~16.67ms for 1/60th a second, but I'm getting a bit to technical trying to explain it.. Anywho, a good way to perhaps implement
this would be to take an argument for say --desktop_mode
wow , long post
To tell you the truth, at the moment i have more important things to improve on the miner. Yes, surely lagging is a problem, but since mining is 98% happening on rigs, where you don't need a responsive ui, it really isn't a problem
If you come up with something , surely i can integrate it, so that 2% of users can get a responsive desktop, with minimal hash drop
Well that 2% may be more than you think, since that is probably all real people most likely just trying out mining or doing it as a hobby and when electric may not be an issue, or many others.
It can also improve on speed for killing outdated shares and work.. pretty much instantly start working on a new task. But yeah tons of people on dedicated mining rigs.. I'll get there eventually.. right now I just want to get the most out of what i can.. since i've known it's limits.. can translate well into newer optimized code too.
Also on that other parts of a miner.. Those are a hassle, but end result is always good, was thinking of a CLI that did a refresh and a moving graph of all gpu's kind of like an equalizer and show hashes accepted, round trip time.. averages, highest number of share_per_card .. but that's another fun story for some beautiful client miners that have never been done before, far as I've seen yet anyways.. most is just what's the hash? is it still running..how many shares.. it should be "what's my temp? and what's my wattage/heat ratio to kWatt" and preserving these new cards that do need to be resold someday..
I'm having issues using certain GPU's. no matter what I change, when I start the miner it starts all mu GPU's instead of the ones I choose. its like the gpu conf section is not overruling everything else like the readme file says it should?? I'm pretty new at this so I'm sure its something I'm prolly doing but I could use some help!! otherwise I love the new miner!! thanks
Do you have yours set up like this.. for example let's say I have 4 cards and i only want the last 2 of them to run for some reason..it would look a little like this..
Code:
//{ "id" : 0, "intensity" : 0, "worksize" : 8, "threads" : 2}, // First GPU.
//{ "id" : 1, "intensity" : 0, "worksize" : 8, "threads" : 2}, // Second.
{ "id" : 2, "intensity" : 0, "worksize" : 8, "threads" : 2}, // Third.
{ "id" : 3, "intensity" : 0, "worksize" : 8, "threads" : 2}, // Fourth.
//{ "id" : 1, "intensity" : 0, "worksize" : 8, "threads" : 2}, // Second.
{ "id" : 2, "intensity" : 0, "worksize" : 8, "threads" : 2}, // Third.
{ "id" : 3, "intensity" : 0, "worksize" : 8, "threads" : 2}, // Fourth.
the "id" is what you are looking for.. numbers start with 0 being first card.. Have you tried running it with -listdevices in your start.bat batch file?
OH also forgot, did you take out the leading /* gpu_stuff here, yada, yada. and then there is another closing comment as thus */ which will also stop it from being used.
⭐ Merited by cryptosize (1)
Wow thank you very much. We can expect it in the next version?
Can you give me some advice for fine tuning my r7 370-s and rx 470s for all cryptonight versions, because on all types of algos, my desktop is little freezing, even on default settings, or even a much smaller intensity.
We can expect it in the next version?Can you give me some advice for fine tuning my r7 370-s and rx 470s for all cryptonight versions, because on all types of algos, my desktop is little freezing, even on default settings, or even a much smaller intensity.
Nothing really can help that without the kernels that are executed. This also happens on any other gpu miner as well right?
For everyone:
I'll explain a bit about OpenCL and how the "kernels" work a bit..
The kernel or "payload/work" is sent to the video card and is kind of like a singular pipe, okay that analogy sucked, but imagine
with all the "CU" Compute Units available.. the work from these kernels are sort of like threads on a miniature scale and they all
work according to the OpenCL standard (Hopefully) But it's like a faucet.. turn it on or off.. also you may need to turn down intensity
even more until you have a freeze free desktop which costs all the extra hashing power you would have had. Remember on SRBMiner you can
use decimals so don't forget that ex: "intensity 20.3" or what have you.
I've left an earlier comment on a "low intensity" mode that is about splitting
up one big time job to do work into much smaller timed jobs and if done right, it really shouldn't have any negative impact on hashing speed,
or at least any notable impacts on it so that could be maybe be a modulation of 100ms or 1/10th a second per command queue or even smoother
by doing it roughly ~16.67ms for 1/60th a second, but I'm getting a bit to technical trying to explain it.. Anywho, a good way to perhaps implement
this would be to take an argument for say --desktop_mode
Hi there, I've had a problem with every miner around since the monero pow change, since the only miner I was able to use was Claymore 9.7beta without it crashing my display drivers.
I've tried xmr-stak, xmrig-amd, newer claymore's (No ASM bin found for my old card.) and about anything else that is supposed to work, I've compiled all the ones available and tried
with stock binaries on windows..
Display drivers crash no matter which version I try.. 14.4 15.7, 15.11-beta (for some reason this one is tricky to find.) Even tried the crimson edition beta which I've found out doesn't
actually include any assembler/disassembly tools for openCL.. Anywho..
Display card: AMD Ati Radeon 6530D (Evergeen or BeaverCreek as it picks it up everywhere.)
Cpu: AMD A6-3620 APU w/ the onboard 6530D
I've tried all 4 kernels out, all kill display, and of course can't get ADL to work, but I'd be highly surprised if that could even work at all anyways on this gpu.
All in all I really don't know what to do, or even try anymore.. I'd lend a hand if I could for getting what is needed to make these A-Series APUs to work. I haven't really seen anything in
the code for the other miners like xmrig/xmr-stak that would be a problem.. But I noted for some reason Claymore is posting exact driver versions for all of their releases, and wondering
how they are able to compile against them specifically, or if that just happens to be what they were using when compiling...
Any help is appreciated, and I'd love to get back to mining on my gpu, had a ton more shares and efficiency even at 42H/s and that's better than 0 since it's on 24/7 anyways.
Here are a couple screenshots for how it's acting and what it catches, and second is showing when display was killed and came back.
https://imgur.com/a/mBtohkv
Thanks, you really are saving miner's lives with this miner and I hope you keep at it.. So I tip my hat to you Doc.
I've tried xmr-stak, xmrig-amd, newer claymore's (No ASM bin found for my old card.) and about anything else that is supposed to work, I've compiled all the ones available and tried
with stock binaries on windows..
Display drivers crash no matter which version I try.. 14.4 15.7, 15.11-beta (for some reason this one is tricky to find.) Even tried the crimson edition beta which I've found out doesn't
actually include any assembler/disassembly tools for openCL.. Anywho..
Display card: AMD Ati Radeon 6530D (Evergeen or BeaverCreek as it picks it up everywhere.)
Cpu: AMD A6-3620 APU w/ the onboard 6530D
I've tried all 4 kernels out, all kill display, and of course can't get ADL to work, but I'd be highly surprised if that could even work at all anyways on this gpu.
All in all I really don't know what to do, or even try anymore.. I'd lend a hand if I could for getting what is needed to make these A-Series APUs to work. I haven't really seen anything in
the code for the other miners like xmrig/xmr-stak that would be a problem.. But I noted for some reason Claymore is posting exact driver versions for all of their releases, and wondering
how they are able to compile against them specifically, or if that just happens to be what they were using when compiling...
Any help is appreciated, and I'd love to get back to mining on my gpu, had a ton more shares and efficiency even at 42H/s and that's better than 0 since it's on 24/7 anyways.
Here are a couple screenshots for how it's acting and what it catches, and second is showing when display was killed and came back.
https://imgur.com/a/mBtohkv
Thanks, you really are saving miner's lives with this miner and I hope you keep at it.. So I tip my hat to you Doc.
hi, remove drivers with Display Driver Uninstaller, install 14.4 and try SRBMINER 1.4.6 --userkernel 4 for XMR use "normalv7"
and start with a very low intensity like 5, and only 1 thread
Ok well I used DDU and found the correct 14.4 drivers.. seems the last one wasn't actually installing for some reason.. anyways now all other miners work as well.
Only one issue really is the intensity setting, I can only go up to 2.0. 2.1 or higher kills display driver or gives the CL invalid buffer.. tried all 4 kernels and worksizes, kernel 2 seems to be the best
at 14H/s compared to 12-13H/s on 3 & 4 kernels. I was wondering if the gpu kernels having "256" in them as being the hash size? and if so, is there a way to lower or give a CLI option to change them or
maybe a 128 version? If that isn't the case, oh well.
(126 intensity seemed to be the optimal number for xmr-stak for some odd reason, also with a 35.9H/s which isn't to far off of the original claymore 9.7's 42H/s with low intensity mode on before v7.)
Does anyone know how to keep windows and everything from being totally unusable on all these miners?
(like clay's -li low intensity mode, which doesn't seem to be related at all to actual intensity.)
Best of luck to everyone.
easy, lower the intensity and problem solved
Claymore v9.7 allows me to have 320 hash threads -> 176 H/s and with low intensity option my PC is perfectly usable for other tasks.
All all other miners max out at 100 H/s and the PC is lagging hard! If I try to use intensity 320, the entire PC freezes.
And yes, I've tried 14.4 drivers.
Srbminer is helping you to use these old cards, so be patient.
Lowering intensity on an APU has no effect, It's more like it's either on or off.. When miner runs with even lowest intensity: it takes 7 seconds to pull up start bar. On higher intensity: 7 seconds to pull up start bar.
If I had a dedicated gpu card this probably isn't the case since they are not built into cpu. I've been playing around trying to make a kernel that runs 1/60th a second, kind of like an oscillation and it should be a fully usable desktop if the mode is enabled.. I'll keep folks posted, and if and when I get it done, I'll post the code enhancements somewhere for anyone interested.
it should go up to 7 - 7.5 with 1 thread on kernel 2
You are right of course, perhaps it's something on kernel 3 or 4, but was able to hit 7.5, and 7.6 killed it..
{ "id" : 0, "intensity" : 7.2, "worksize" : 8, "threads" : 1}, is giving 33.0H/s so, not bad at all for this APU.
I'll be looking up some OpenCL api and see if something like low intensity mode could be done by it, or if it needs
done mostly from scratch, or if it's some windows magic.. (i'm used to linux coding, so don't know much of that..)
EDIT:
Seems to be clEnqueueNDRangeKernel and getting it's timing down, thanks to a little nugget of info through google.
Hi there, I've had a problem with every miner around since the monero pow change, since the only miner I was able to use was Claymore 9.7beta without it crashing my display drivers.
I've tried xmr-stak, xmrig-amd, newer claymore's (No ASM bin found for my old card.) and about anything else that is supposed to work, I've compiled all the ones available and tried
with stock binaries on windows..
Display drivers crash no matter which version I try.. 14.4 15.7, 15.11-beta (for some reason this one is tricky to find.) Even tried the crimson edition beta which I've found out doesn't
actually include any assembler/disassembly tools for openCL.. Anywho..
Display card: AMD Ati Radeon 6530D (Evergeen or BeaverCreek as it picks it up everywhere.)
Cpu: AMD A6-3620 APU w/ the onboard 6530D
I've tried all 4 kernels out, all kill display, and of course can't get ADL to work, but I'd be highly surprised if that could even work at all anyways on this gpu.
All in all I really don't know what to do, or even try anymore.. I'd lend a hand if I could for getting what is needed to make these A-Series APUs to work. I haven't really seen anything in
the code for the other miners like xmrig/xmr-stak that would be a problem.. But I noted for some reason Claymore is posting exact driver versions for all of their releases, and wondering
how they are able to compile against them specifically, or if that just happens to be what they were using when compiling...
Any help is appreciated, and I'd love to get back to mining on my gpu, had a ton more shares and efficiency even at 42H/s and that's better than 0 since it's on 24/7 anyways.
Here are a couple screenshots for how it's acting and what it catches, and second is showing when display was killed and came back.
https://imgur.com/a/mBtohkv
Thanks, you really are saving miner's lives with this miner and I hope you keep at it.. So I tip my hat to you Doc.
I've tried xmr-stak, xmrig-amd, newer claymore's (No ASM bin found for my old card.) and about anything else that is supposed to work, I've compiled all the ones available and tried
with stock binaries on windows..
Display drivers crash no matter which version I try.. 14.4 15.7, 15.11-beta (for some reason this one is tricky to find.) Even tried the crimson edition beta which I've found out doesn't
actually include any assembler/disassembly tools for openCL.. Anywho..
Display card: AMD Ati Radeon 6530D (Evergeen or BeaverCreek as it picks it up everywhere.)
Cpu: AMD A6-3620 APU w/ the onboard 6530D
I've tried all 4 kernels out, all kill display, and of course can't get ADL to work, but I'd be highly surprised if that could even work at all anyways on this gpu.
All in all I really don't know what to do, or even try anymore.. I'd lend a hand if I could for getting what is needed to make these A-Series APUs to work. I haven't really seen anything in
the code for the other miners like xmrig/xmr-stak that would be a problem.. But I noted for some reason Claymore is posting exact driver versions for all of their releases, and wondering
how they are able to compile against them specifically, or if that just happens to be what they were using when compiling...
Any help is appreciated, and I'd love to get back to mining on my gpu, had a ton more shares and efficiency even at 42H/s and that's better than 0 since it's on 24/7 anyways.
Here are a couple screenshots for how it's acting and what it catches, and second is showing when display was killed and came back.
https://imgur.com/a/mBtohkv
Thanks, you really are saving miner's lives with this miner and I hope you keep at it.. So I tip my hat to you Doc.
hi, remove drivers with Display Driver Uninstaller, install 14.4 and try SRBMINER 1.4.6 --userkernel 4 for XMR use "normalv7"
and start with a very low intensity like 5, and only 1 thread
Ok well I used DDU and found the correct 14.4 drivers.. seems the last one wasn't actually installing for some reason.. anyways now all other miners work as well.
Only one issue really is the intensity setting, I can only go up to 2.0. 2.1 or higher kills display driver or gives the CL invalid buffer.. tried all 4 kernels and worksizes, kernel 2 seems to be the best
at 14H/s compared to 12-13H/s on 3 & 4 kernels. I was wondering if the gpu kernels having "256" in them as being the hash size? and if so, is there a way to lower or give a CLI option to change them or
maybe a 128 version? If that isn't the case, oh well.
(126 intensity seemed to be the optimal number for xmr-stak for some odd reason, also with a 35.9H/s which isn't to far off of the original claymore 9.7's 42H/s with low intensity mode on before v7.)
Does anyone know how to keep windows and everything from being totally unusable on all these miners?
(like clay's -li low intensity mode, which doesn't seem to be related at all to actual intensity.)
Best of luck to everyone.
I also have an Evergreen GPU (Radeon 5770) and even went back to 14.4 drivers from 15.7.1.
No miner works properly, except Claymore v9.7. I even noticed that my PC hangs with non-Claymore miners.
What kind of sorcery is this?!
No miner works properly, except Claymore v9.7. I even noticed that my PC hangs with non-Claymore miners.
What kind of sorcery is this?!
Not quite sure, but I did have that happen with a full on crash when it came to I'm thinking was xmr-stak on some of the odd drivers..
Most of the time though just a flash and display drivers pop back up and no hashes ever as soon as it gets a job and tries to work.
Also claymore is pretty much dead now.. would be nice if they released the code to it, would help out about all branches of miners
for video instability and such.
..
That pool might have a much longer threshold on banning time.. instead of the usual 10 or 30 minutes, it might be much higher.
Might want to check with the pool to make sure about that.. Some actually do 24 hours.