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
PS: Why do you need Catalyst 8.12 compatibility?
Does CAL also retun 0 devices? Can you run FindNumDevices test?
Originally posted by: gaurav.garg Does CAL also retun 0 devices? Can you run FindNumDevices test?
Ask you me or Raistmer? If you have installed a driver version with mismatched CAL libraries (atical*.dll vs. amdcal*.dll) it doesn't run at all if that is your question. One would have to check which libraries are there and dynamically load the appropriate ones (and use the matching struct definitions). I found it easier just to compile it twice (once for each set of libraries).
Originally posted by: gaurav.garg
Does CAL also retun 0 devices? Can you run FindNumDevices test?
Originally posted by: gaurav.garg
Does CAL also retun 0 devices? Can you run FindNumDevices test?
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.
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.
Originally posted by: Raistmer Originally posted by: GipselCAL 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...
Obviously there is more than one thing broken in later driver releases. I don't need the address translation (kernels are written directly in IL, so there is also no chance it is used by accident) but it still fails with all WinXP drivers starting with Catalyst 9.3. Strange coincidence, isn't it?
Originally posted by: Raistmer 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...
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