*Catalyst 12.1 Preview* Decreased performance, anyone else confirm?

[Fiyasko]

AKA your new kernal mixed with these drivers is totally fucking pointless for miners

... so just don't use it.

Dia

+1

[-ck]

Well I think the 100% CPU usage is not a fault in AMDs drivers but it comes from how I process the OpenCL buffer, which holds nonces.
To speed up kernel execution I removed control-flow (if-statements) from the kernel, but now check the whole buffer for valid nonces, even if there are none ... this leads (my guess) to an endless processing loop in Phoenix, which is the drawback of the kernel changes.

Just as a data point, cgminer does not do this. It does not check the whole buffer.

[Transisto]

I get 280 instead of 334mhs with 12.1 (5850 at 825mhz 300ram poclbm -v -w256)

That is not some small drop ... this is 20%,  I was expecting ~5% and that it was worth it for the CPU bug.

[bronan]

try with different settings cause when i use -v w256 i have a lot less performance
setting it to -v2 -w 128 should fit better on a 5850

[Diapolo]

Well I think the 100% CPU usage is not a fault in AMDs drivers but it comes from how I process the OpenCL buffer, which holds nonces.
To speed up kernel execution I removed control-flow (if-statements) from the kernel, but now check the whole buffer for valid nonces, even if there are none ... this leads (my guess) to an endless processing loop in Phoenix, which is the drawback of the kernel changes.

Just as a data point, cgminer does not do this. It does not check the whole buffer.

Hi Con,

That is correct, but CGMINER uses Phatk2, which seems currently to not work that well with SDK / runtime 2.6.
So it's again a trial and error to get the best tradeoff.

Dia

Edit: I found out that a Worksize of 64 with Phoenix works great now, this was much slower before 2.6.

[BOARBEAR]

For those who got less hash with 12.1 with cgminer

Try worksize 64 with vectors 4

[-ck]

For those who got less hash with 12.1 with cgminer

Try worksize 64 with vectors 4

That's interesting because each GPU will report what its "preferred vector size" is, and often it comes out to 4, yet despite that, virtually all GPUs had much better performance (with the older SDK) and 2 vectors. Perhaps they live up to their promise now?

[gat3way]

Nope, preferred vector size does not always mean "best performance". Wider vectors mean more GPRs used and the more GPRs you use, the less wavefronts you can schedule on a CU, thus occupancy goes down. Also, on VLIW5 hardware, uint4 vectors are not optimal, it can happen that there are no 5 non-dependent instructions to fill the whole VLIW bundle. That depends on your code.

For example, with hash cracking you might end up with uint8 being much better than uint4 for kernels like the MD5 or NTLM one as ALUPacking goes up and the number of used GPRs is 10-20 at most. On the other hand, more complex algorithms like SHA512 are much better with uint2 or even a scalar implementation as the number of used GPRs greatly hampers the occupancy. With memory-intensive kernels like DES ones (thanks god bitcoin is not one), occupancy becomes even more important as more concurrency means memory access  latencies are more easily "hidden".

Back to uint2, problem with it is that it's even worse at utilizing all the slots in the VLIW bundle and your ALUPacking just always sucks. However, generally speaking with most bitcoin kernels it's a tradeoff worth having as bad occupancy in that particular case is worse than bad ALUPacking.

uint3 should provide a better balance between those, but it was broken in pre-2.6 APP SDK releases. Now they fixed it and I am curious about results...


PS as of why suddenly uint4 started performing better, it could be either that they iimproved scheduling or that they have improved the backend compiler to pack instructions better with uint4 / worse with uint2. It could be actually both.

[BOARBEAR]

Oh btw there are two different versions of 12.1 preview

The one I tried is this:
http://developer.amd.com/Downloads/OpenCL1.2-Static-Cplus-preview-drivers-Windows.exe

It has a newer openCL than the other 12.1 preview

[Diapolo]

Nope, preferred vector size does not always mean "best performance". Wider vectors mean more GPRs used and the more GPRs you use, the less wavefronts you can schedule on a CU, thus occupancy goes down. Also, on VLIW5 hardware, uint4 vectors are not optimal, it can happen that there are no 5 non-dependent instructions to fill the whole VLIW bundle. That depends on your code.

For example, with hash cracking you might end up with uint8 being much better than uint4 for kernels like the MD5 or NTLM one as ALUPacking goes up and the number of used GPRs is 10-20 at most. On the other hand, more complex algorithms like SHA512 are much better with uint2 or even a scalar implementation as the number of used GPRs greatly hampers the occupancy. With memory-intensive kernels like DES ones (thanks god bitcoin is not one), occupancy becomes even more important as more concurrency means memory access  latencies are more easily "hidden".

Back to uint2, problem with it is that it's even worse at utilizing all the slots in the VLIW bundle and your ALUPacking just always sucks. However, generally speaking with most bitcoin kernels it's a tradeoff worth having as bad occupancy in that particular case is worse than bad ALUPacking.

uint3 should provide a better balance between those, but it was broken in pre-2.6 APP SDK releases. Now they fixed it and I am curious about results...


PS as of why suddenly uint4 started performing better, it could be either that they iimproved scheduling or that they have improved the backend compiler to pack instructions better with uint4 / worse with uint2. It could be actually both.

I implemented uint3 quite a few months ago, but it was bugged (like you said) ... since 2.6 I'm able to compile my kernel via KernelAnalyzer and get no errors (the uint3 kernel is much longer by the way). But I guess I did something wrong in the init.py from Phoenix, which I can't solve by myself ... Phoenix crashes if kernel is started. Are you skilled enough to take a look at it?

Dia

[gat3way]

Not quite, python is not among my strong sides. I may rewrite my miner though, just for the experiment. Anyway I have more important projects right now.

[HolodeckJizzmopper]

Confirming a 20% drop in hashing performance across a variety of cards using 11.12.

Fuck.

Time to roll back to older drivers.

I hate ATI so damned much sometimes.

Edit: Using phoenix/phatk

[Diapolo]

Confirming a 20% drop in hashing performance across a variety of cards using 11.12.

Fuck.

Time to roll back to older drivers.

I hate ATI so damned much sometimes.

Edit: Using phoenix/phatk

Could you try this one (https://bitcointalk.org/index.php?topic=25860) with Phoenix 1.7.1 and report your results?

Dia

[Fiyasko]

Confirming a 20% drop in hashing performance across a variety of cards using 11.12.

Fuck.

Time to roll back to older drivers.

I hate ATI so damned much sometimes.

Edit: Using phoenix/phatk

10% drop across all my cards. But no more cpu bug, Cant tell wich is worse.

[Fiyasko]

Confirming a 20% drop in hashing performance across a variety of cards using 11.12.

Fuck.

Time to roll back to older drivers.

I hate ATI so damned much sometimes.

Edit: Using phoenix/phatk

10% drop across all my cards. But no more cpu bug, Cant tell wich is worse.

So can anyone bring there hash rate back to normal with the cat 12.1? I love it's gaming performance, But im losing 10% of my speed so that i can save 17% of my cpu usage... I'd rather not burn out one of my cores, Atop of that it's a waste of power.

[conspirosphere.tk]

I confirm a 30+ Mhs drop on both a 5870 and a 5830 with both CataCLYSM 11.12 and 12.1 compared with 11.6.
What is MUCH WORSE is that you cannot revert back effectively: uninstalling and driver sweeping before rebooting and reinstalling 11.6 will NOT return your previous performance.
Luckily, I had a fresh system backup made just yesterday that I could restore no prob.
Now I am back to mining happily with my 5870@970/300 hashing at 440Mhs+ and a 5830@940/300 hashing at 300Mhs+ with Phoenix 1.7 on Xp.

[Fiyasko]

We really REALLY need to optomise these new drivers...
Some of us still play videogames and mine coins y'know... It's not just all Deticated miners running

[bal3wolf]

mining works good for me no cpu usage and still good perf but i been crashing in games on so im going back to try 11.12.

[Fiyasko]

mining works good for me no cpu usage and still good perf but i been crashing in games on so im going back to try 11.12.

...Wtf...
12.1 i've never crashed yet...
Im LOVING these drivers. but the lack of 10% mining speed really hurts

[bal3wolf]

It would crash in dead island 1-4hrs at random 11.12 does not and it still has 0 % cpu usage but the lower mining speed to.