Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 184. (Read 877859 times)

bullus, why did you shit all over your drivers?  You went from 14.7 down?  Going full retard?

  read it wrong.. thanks it works now

So enable ; )
I did confirm by logs and power meter.

Interesting, maybe that happens on 32bit systems/32bit miners?
I personally have not checked mining on *nix at all, cause its not possible to downvolt via software out of the box.
I did compare win and *nix AMD driver dissasembly, tho. And its different ; ) I mean, obviously kernel is different, but also some random ADL logic is different, looks like win AMD driver is more 'optimized'.

Anyway, like with Windows max GPU limit rumours, I think win is not the issue or at least I can't imagine how it could be.
I can actually ; )) hw memory mappings etc.. but if this was the case prly all GPUs would stop working.. not just some random GPUs.

Not working for my asus, even test gpu-tweak. unofficial oc is disabled.
At msi ab I can change the voltage but in the log and powerdraw u don't see any changes.
gpu-tweak does work with the voltage but lower clock settings don't work.

Installed 14.6rc1 and still not working..going back to 14.4

I had just edited my post to explain better, but you ninja'd a fast reply. I tried tons of TC values in my testing. Can't remeber the max I ever tried, but I never hit a memory error that wasn't due to a lack of GPU memory.

TC?

r9 290 unvervolts fine with 14.7 RC1 July9 via MSI AfterBurner 3.0.0 for me.
But without enabling 'unofficial oc with power play support' AF was not able to change clocks and sgminer launched after AF was not able to change clocks also.

I have run 6x R9 290s on an ASRock Pro BTC board with 2GB of RAM, and never in my testing did I hit a memory error that wasn't because of insufficient GPU memory.

(I later moved entirely to 5 card rigs, but that's quite unrelated)

I'm not judging any OS ; )
Btw, Win runs fine from USB flash stick with no swap space.

Do you have experience with 6xGPUs, 40960 TC, scrypt on *nix?

Oh god... please don't judge linux mining based on the awefully built 32bit BAMT OS running off a flash drive with no swap space...

Try a real linux install with some swap space and you'll be able to load any size opencl kernel, even with very little free RAM - this is my experience anyway.

Last night I wanted to undervolt my 290x but it doesn't work..going back to 14.6rc1 and try again.

It's completely understandable, that some ill-educated ppl will blame Win in the first place ; )

In this case it's either ocl or driver or cgminer or OS. Imo it's not OS, cause ppl get the same issue on BAMT https://litecointalk.org/index.php?topic=13137.msg98983#msg98983
And issue exists with any driver I've seen so far.

actually for for running miners i found pimp works fairly well
and its not too difficult to use

Lol... I deserved that.  But really... if you can, try mining on linux - it's yummy. =p

Fuck, I KNEW somebody would hit us up with the Linux circlejerk.
"Why don't you just bootstrap your backports blah blah blah"

Glad I'm a linux miner and don't have to worry about system RAM like apparently Windows users do.

Yep, something like that. But its the same process for any algo(or any OCL program).
The limitation is - OpenCL is not able to load multiple kernels with total size(or with VRAM consumption) more than available system RAM.
Proportion deffo is not 1:1, tho, if it even exists.
OpenCL does not care what kernel does. But since scrypt can use a lot of VRAM issue is more likely to appear.

"4" = CL_MEM_OBJECT_ALLOCATION_FAILURE, so that's deffo mem issue. However I was not able to pinpoint the issue, since at no point in time system memory usage spikes, my win rigs are using ~900mb of ram with miner running(~750MB win, ~200MB miner). OCL also reports available buffer size the same for rigs with 4GB/8GB RAM. GPU available VRAM obviously is the same. That's why I thought about hardware memory mappings. Tho maybe there is a bug or improper logic in cgminer ; )

And to complicate things, only some ammount of GPUs fail to init not all of them(proportionally to system RAM ammount). If I remember correctly 2 GPUs report -4 with 4GB of system RAM, scrypt and 24000tc and 1 GPU - with 6GB of system RAM.

Also there is something shady going on with maximum available buffer size in AMD OCL driver, f.e. 14.4+ apparently does not take GPU_MAX_ALLOC into account(however there is reference to it in the source code), that's why it sux for scrypt/scrypt-n/any other vram intensive algo.


Btw, I've checked with mining x11 with single r9 290 vram usage is 576MB, prly some ammount is being used by win.
So.. likely x11 kernel won't load on win system with 512mb of ram ; )

Yeah but I think in scrypt it started with the ram in the system then dumped it onto the grafix after it ... at least that is how I understood it back then.

So in theory you still should be able to start mining with the newer algos with 512mb ram... if you can find it that is lol.

; )

It's not about the algos it's about memory usage.
All algos use some ammount of GPU memory.
With large TC on scrypt its jsut more 'visible'.
x11 uses ~500mb of GPU RAM as far as I remember.