AMD Stream 2.3 SDK released

[User]

Good news to hakre, i think

# AMD Stream 2.3 SDK release

* Performance improvements for AMD’s OpenCL toolset
* Support UVD video hardware component through OpenCL driver (Windows 7 only)
* Support for the Stream Profiler on Linux (command line version)
* Support added for AMD Radeon HD 6800 Series and AMD Radeon HD 6900 Series
* Support for FFT and BLAS-3 libraries
* Stream Profiler enhancements (including timeline visualization)
* Resolves a number of bug fixes from the Stream SDK 2.2 release

[Rolf]

Bad news.
Nothing promised got fixed.
They screwed it up again.

[atom]

The SDK v2.3 is absolutely useless.

I can't express how disappointed I am.

ATI developers have confirmed, and known about all of the bugs for some time, with adequate time to fix them.

But not a single bug was fixed.

Here is a list of serious unresolved OpenCL Bugs that affect oclHashcat:

- hd5970 and all other dual-gpu cards: only 1st gpu is supported
- Device query returns wrong global memory size
- Device query returns wrong clock rate
- Linux: multi-gpu is not supported at all
- Linux: each GPU produces 100% CPU load

AFAIK, none of these bugs exists in CAL.

Here is a list of serious missing features that affect oclHashcat:

- No support for VLIW5 (reduces performance to CAL theoretical by ~ 20%)
- No support for BFI_INT (reduces performance to CAL theoretical in md5 by ~ 15%)
- Users manually need to disable crossfirex
- Windows: requires a monitor connected to each GPU
- Linux: Requires a valid Xsession of the user who is running the OpenCL app
- Linux: Users still need to install the whole SDK just to get libOpenCL.so

But there one more thing. With each new of the SDK they changed the binary format of the kernels somehow. This mostly requires to recompile them. This forces me to publish a new version of oclHashcat after that. So i have to release new oclHashcat each time they release a new SDK?

This is so de-motivating. It seems both ATI and NV are not interested in making OpenCL successfully and rather push their own native solutions CUDA and CAL/IL. I am still undecided, but I have seriously considered terminating development of oclHashcat.

[Sorcier_FXK]

It's à fantastic gift from ATI. I understand your anger. You can pause the developement of oclh/oclh+ but don't stop it. You know my opinions on your works, Hashcat tools are 'Royce Rolls' of passcracking.

Do not lose your motivation, we're with you !

[IvanG]

I am still undecided, but I have seriously considered terminating development of oclHashcat.

I know these feelings, writing code for ATI GPUs is a totally annoying process. And it isn't related to OpenCL only, CAL/IL have a lots of problems too mainly because of immature design and programmers used to create it. Moreover, ATI decided that OpenCL is ready (ha-ha!) and so no point to document/expose feature at IL level. They added several features to CAL and these features used by ATI's internal OpenCL functions but they cba to document anything, so these functions are unavailable without time consuming disassembly/hacks. Simply ridiculous, I need to hack CAL compiler to make it compile code the way I want.

As for VLIW5 -- you don't need special support for it, just declare 5x different states as uint4 a, b, c, d and uint a2, b2, c2, d2, intermix everything together and it'll work. However I see no real speed-ups for multihash kernels as they more limited with texture fetches rates.

And BFI_INT isn't exposed at CAL/IL level at all, so you're need to manually hack binary code to replace needed instructions with BFI_INT.

All in all, switching to CAL/IL won't make things easier, only positive thing will be working 2nd core of 5970 (as ATI somehow broke it at OpenCL level).

[User]

atom,

If there's anything we could do, like post your suggestions at AMD's board, please tell us.

A software and a support like yours costs a lot at the moment.

Your story remembers me BarsWF project, killed by the end of brook.

[Xanadrel]

Same as Sorcier_FXK, if we can help in a way just say it.
And it's great that we can talk to you easily, comparing to some other developers.
hashcat makes me want to learn more for being able to code (I hope) nice tools too.

Keep coding your awesome tools

[atom]

much thanks to you guys for the the support

[atom]

Good News!!!!!!

Today some guy posted on AMD dev forum about an undocumented environment variable "GPU_USE_SYNC_OBJECTS": http://forums.amd.com/forum/messageview....did=143851

Setting this environment variable to 1 solves the three most annoying problems at once:

1. hd5970 2nd gpu works (have not tested 2x hd5970 yet, have not tested on windows)
2. multi gpu on linux works
3. CPU usage is at 0%. This means i was able to run hashcat (CPU) which creates 100% load on all cores while i run oclHashcat in parallel without any speed loss

One thing before we all go crazy now. It requires a BIG change in oclHashcat core. I am going for vacation in the next days so i can not implement it. But i try to get it ready ASAP when i am back in january.

[Jardeath]

Excellent, I've just been using both hashcat and oclhashcat and the speed drop from using the cpu was getting annoying. ^_^

EDIT: Lately I've been noticing oclhc using 38% cpu while using word lists / doing a fair amount of hashes which slows down my whole OS which didn't happen before. Now it even happens when I'm only doing one hash, so hopefully the new version can fix this for me.