Originally posted by: Raistmer If keeping 8.12 is absolutely required, should I rebuild with older SDK version (what version then) or this issue doesn't connected with new SDK/old driver compatibility ?
SDK1.3 ist the version you need to be compatible with Catalyst 8.12 and Cat 9.1 (but the apps build with them don't work with newer drivers). Unfortunately you loose some features of the SDK1.4 (choice of GPU without setting some environment variable, just to name one which is important to you 
). Actually that is the reason I started to build my own versions of the brook.dll. Asynchronous kernel calls also benefit from SDK1.4.
The reason for the incompatibility is the "rebranding" of the amdcal*.dll files to atical*.dll. Nice place for a brand! No normal guy will ever notice and it broke/breaks existing programs!
My solution was to still use SDK1.3 with some small modifications (GPU choice and no busy waiting) and to create two versions of the applications. One linked against the amdcal*.libs (Cat 8.12 and 9.1) and the other one linked against the atical*.libs (you have to use the SDK1.3 cal.h for this to be working as some struct sizes have been increased, some functions will return junk otherwise) for newer drivers. It's not perfect but it was the simplest solution. And it works.
PS: Why do you need Catalyst 8.12 compatibility? Did you also run into the stability problems of the new WindowsXP drivers? From my feeling the handling of several output streams (multiple render targets for the graphics guys) amplifies the problem tremendously. Collatz uses only single output stream kernels and doesn't show the issues. Milkyway is generally using 4 output streams and doesn't run longer than a few seconds before crashing the newer drivers. Cat 9.2 was still working okay (I had MW running on a HD4870 continously for about a week at full load), but starting from Cat9.3 it simply doesn't return from a kernel call, while Vista and Win7 drivers generally work.
Originally posted by: Gipsel Originally posted by: Raistmer About problems with XP - app uses 1 output stream in longest kernel and up to 4 for smaller kernels. Currently it works OK on WinXP x86 SP3/CAL ATI Radeon HD 2600 (RV630) (512MB) driver: 1.3.186, Microsoft Windows XP Professional x64 Edition, Service Pack 2, (05.02.3790.00) / CAL ATI Radeon HD 3800 (RV670) (512MB) driver: 1.3.186, Microsoft Windows XP Professional x86 Edition, Service Pack 3, (05.01.2600.00) / CAL ATI Radeon HD 3800 (RV670) (512MB) driver: 1.3.186. Other hosts about I know running Vista/Win7.
CAL 1.3.186 equals Catalyst 9.2, the last stable one for Milkyway with WindowsXP 32bit as well as 64bit. You should try it with one of the later ones.
Later will have address translation broken...
Actually, AMD/ATI has no Stream SDK. It has only some work in progress in this area. Starting from 0.99 alpha there were no single SDK release accordingly ATI's own SDK download page. Only betas... No real product. It says very much about quality
And there is no device.h header in SDK 1.3
That is, no multi-GPU support for Brook+ app
and code modifications required to build with SDK 1.3
It seems such downgrade not an option...
That is, no multi-GPU support for Brook+ app
and code modifications required to build with SDK 1.3 It seems such downgrade not an option...
Originally posted by: Raistmer And there is no device.h header in SDK 1.3 That is, no multi-GPU support for Brook+ app
It is more or less in there (I guess you don't use more than one GPU in a single instance). It works a bit different than in SDK1.4, but basically you just have to pass the device number from the command line (set by the client) to the brook.dll and use that instead of the value set by the environment variable. One has to recompile the brook runtime, but as I see it you are forced to to this recompile for SDK1.4 too (because of the dynamic linking issue).
But I agree it is a bit of effort to change back from SDK 1.4 to 1.3 (and may be close to impossible if you need the LDS for instance).
The easiest fix would be that the next driver release fixes the address translation as well as the issues with multiple output streams (if that is the problem) on WinXP systems
Originally posted by: Gipsel
The easiest fix would be that the next driver release fixes the address translation as well as the issues with multiple output streams (if that is the problem) on WinXP systems
LoL, next driver release most probably will abandon Brook as whole...
And will not support OpenCL still (this will be just in line with "improvements" done so far... )
