Finally, they released it. The long awaited SDK that should patch all Bugs. Guess what: not a single Bug fixed!
Here are the unresolved issues that are related to oclHashcat:
Most Important:
Quote:The ATI Radeonâ„¢ HD 5970 GPU is currently supported in single-GPU mode only. It is recommended users only access the first device on an ATI Radeonâ„¢ HD 5970 GPU for GPU compute.
Well this is a Problem for oclHashcat, but we have that hack, that hidden environment variable "GPU_USE_SYNC_OBJECTS". Using it we are able to utilize the 2nd GPU fully. It has been tested several times. It works fine. However its inofficial.
Semi Important:
- bitselect() still not mapped to BFI_INT. Thats sad, would save me a lot of work. So that means i still have to hack the BFI_INT instructions into the binaries.
- clGetDeviceInfo CL_DEVICE_MAX_CLOCK_FREQUENCY returns 0mhz, sometimes i've seen 1mhz. Its not listed in the in the release notes, but its still there.
Quote:The OpenCL runtime currently exposes less than the total amount of memory physically available on the card
Last but not least, SDK v2.4 had something usefull:
- Added support for BeaverCreek, Caicos, Turks and WinterPark GPUs.
Some additionally notes from me. In the developer release notes they say:
Quote:AMD APP intends to deprecate the following as of SDK 2.5:
– AMD CAL
– Support for the Windows XP platform
– BIF 1.0 (the binary format prior to SDK 2.2)
All of the following points are interessting from our view:
- Kick out CAL? I guess some guys in the GPGPU scene really do not like to read this! Just to name some of them: IGHASHGPU, KK, Fenix or calpp version of Pyrit base on it.
- Kick out Windows XP support. Thats not so bad however i know some Hashcat users still use XP. Guys, upgrade to Win7 or Linux
- Kick out BIF 1.0. Well thats a problem for oclHashcat. They all use the binary format. But I hope they stick at least to ELF. At least that means new releases of all oclHashcats after AMD releases SDK 2.5
Also it seems they finally renamed that ATI to AMD in the SDK. That means, on Linux, you have to
replace the files from the ICD registration on /etc/OpenCL/vendors. Remove the old ones and unpack the icd-registration.tgz in the SDK 2.4.
Thats all from my first impressions. However it will not prevent me from releasing oclHashcat-lite. I guess on weekend
--
atom
(04-07-2011, 01:04 PM)atom Wrote: [ -> ]atom
TL;DR
Drivers still suck, hashcat might be the only thing on the market for a bit
(04-07-2011, 01:04 PM)atom Wrote: [ -> ]Finally, they released it. The long awaited SDK that should patch all Bugs. Guess what: not a single Bug fixed!
Here are the unresolved issues that are related to oclHashcat:
Most Important:
Quote:The ATI Radeonâ„¢ HD 5970 GPU is currently supported in single-GPU mode only. It is recommended users only access the first device on an ATI Radeonâ„¢ HD 5970 GPU for GPU compute.
Well this is a Problem for oclHashcat, but we have that hack, that hidden environment variable "GPU_USE_SYNC_OBJECTS". Using it we are able to utilize the 2nd GPU fully. It has been tested several times. It works fine. However its inofficial.
Semi Important:
- bitselect() still not mapped to BFI_INT. Thats sad, would save me a lot of work. So that means i still have to hack the BFI_INT instructions into the binaries.
- clGetDeviceInfo CL_DEVICE_MAX_CLOCK_FREQUENCY returns 0mhz, sometimes i've seen 1mhz. Its not listed in the in the release notes, but its still there.
Quote:The OpenCL runtime currently exposes less than the total amount of memory physically available on the card
Last but not least, SDK v2.4 had something usefull:
- Added support for BeaverCreek, Caicos, Turks and WinterPark GPUs.
Some additionally notes from me. In the developer release notes they say:
Quote:AMD APP intends to deprecate the following as of SDK 2.5:
– AMD CAL
– Support for the Windows XP platform
– BIF 1.0 (the binary format prior to SDK 2.2)
All of the following points are interessting from our view:
- Kick out CAL? I guess some guys in the GPGPU scene really do not like to read this! Just to name some of them: IGHASHGPU, KK, Fenix or calpp version of Pyrit base on it.
- Kick out Windows XP support. Thats not so bad however i know some Hashcat users still use XP. Guys, upgrade to Win7 or Linux
- Kick out BIF 1.0. Well thats a problem for oclHashcat. They all use the binary format. But I hope they stick at least to ELF. At least that means new releases of all oclHashcats after AMD releases SDK 2.5
Also it seems they finally renamed that ATI to AMD in the SDK. That means, on Linux, you have to replace the files from the ICD registration on /etc/OpenCL/vendors. Remove the old ones and unpack the icd-registration.tgz in the SDK 2.4.
Thats all from my first impressions. However it will not prevent me from releasing oclHashcat-lite. I guess on weekend
--
atom
Good news we waiting for oclhashcat-lite personaly can't use becouse can't mix cards(i got 1xhd5870 and 1xhd5970 in crossfire) with it but will be very usefull for lots users.
Thanks Atom
why not? 5870 and 5970 share the same gpu type (cypress). just synchronize their core clock speed and it will work.
(04-08-2011, 09:08 AM)atom Wrote: [ -> ]why not? 5870 and 5970 share the same gpu type (cypress). just synchronize their core clock speed and it will work.
This is a good news.
Anyway already decided to move to a 5870 quad fire to solve the overheating problems.
BR
Alex
This SDK release sucks.
1) Removed the clc tool which was very useful and now I have to write my own ocl compiler to check build errors.
2) Unlike what they claim, kernel launch latency is roughly the same as in 2.3 (measured with SKA). That sucks
3) Zero-copy transfers are windows-only. That sucks
4) Suddenly I have problems replacing some BFI_INTs due to the OpenCL compiler playing too smart
5) Kernel compilation time not reduced at all
6) Still have to use BFI_INT hacking and still have to use undocumented environment variables
7) Created unnecessary confusion renaming libraries and all that ICD stuff lost me half an hour to figure out
8) Ummm overall no performance gains at all
9) Relying on environment to allocate buffers larger than the 128 MB limit still has erratic behavior
10) long vectors are the same sh*t as before, so that SHA512 kernels would still be pain in he ass.
Nah....
ATI is killing itself. If they continue this way everyone will move to nvidia
(04-08-2011, 09:08 AM)atom Wrote: [ -> ]why not? 5870 and 5970 share the same gpu type (cypress). just synchronize their core clock speed and it will work.
Great news read topic about oclhashcat-lite and there you write that can only use the same card but great that this is updated then will use for sure after relised
Haha, it seems nvidia is still bribing the ati(yes, the one amd "inherited") software dev team.
No, seriously, they made a habit of releasing new versions with new&old bugs.
I'm really really amazed how much patience is required to code OpenCL for AMD cards. Well, at least they beat NV in int perf. by several times.
The ATI Radeonâ„¢ HD 5970 GPU is currently supported in single-GPU mode only. It is recommended users only access the first device on an ATI Radeonâ„¢ HD 5970 GPU for GPU compute.
*****************************************************************************
Does anybody know if the new 6990 shares the same fate as the 5970 for GPU compute?
Does the following also apply here atom?
Well this is a Problem for oclHashcat, but we have that hack, that hidden environment variable "GPU_USE_SYNC_OBJECTS". Using it we are able to utilize the 2nd GPU fully. It has been tested several times. It works fine. However its unofficial.