Archives Discussions

[Iska91]

Hey everyone,

I'm a physics student @ the University of Delft and because of that I do quite a lot of calculations on my PC. The problem is that my CPU (C2D E8400@3.6ghz) isn't fast enough to make the calculations in an acceptable amount of time. So I was thinking, why use my CPU which can do about 30 GFlops while my 2 4850's (@700,1020) can do about 2.2 TFlops! 
I already have some C++ experience (and a lot PHP, but that doesn't really matter) so I decided to check out the wonderful world of ATI Stream.

Well, It's about 2 hours later right now and I'm damn frustrated! I can't get the Brook+ (multi_gpu in this case) examples to run! I already checked all the linker and C++ settings and I does compile. The error I'm getting is:
LINK : fatal error LNK1181: cannot open input file 'E:\ATI\ATI.obj'
I'm currently running Windows 7 Ent. x64 and Catalyst 9.10.

Does anyone know how I can fix this problem. I'm eager to start experimenting with my GPU's as my new calculator.

Regards,
Iska

[the729]

Welcome to the world of GPGPU.

Why not use OpenCL? I think the old Brook+ is deprecated.

By the way, there is no ATI.cpp or ATI.br in the Brook sample codes. So there should not be any object file named ATI.obj. Simply remove it from the linker settings and see what happens?

[Iska91]

I installed Stream v2.0 and set the Env. Var's. The OpenCL samples compile and run but it fails at the function SetupKernel:

CALint SetupKernel(const CALchar* ILKernel, CALmodule* module, CALcontext* ctx, CALboolean disassemble)
{
//////////////////////////////////////////////////////////////////////////
//
// compile, link and load the kernel program
//
CALimage image = NULL;
CALboolean success = CAL_FALSE;

// Get device specific information
CALdeviceattribs attribs;

attribs.struct_size = sizeof(CALdeviceattribs);
if (calDeviceGetAttribs(&attribs, Info.DeviceNum) != CAL_RESULT_OK)
{
fprintf(stderr, "There was an error getting device attribs.\n");
fprintf(stderr, "Error string is %s\n", calGetErrorString());
return 0;
}

// Compile IL kernel into object
CALobject obj;
if (calclCompile(&obj, CAL_LANGUAGE_IL, ILKernel, attribs.target) != CAL_RESULT_OK)
{
fprintf(stderr, "There was an error compiling the program.\n");
fprintf(stderr, "Error string is %s\n", calclGetErrorString());
return 0;
}

// Link object into an image
if (calclLink(&image, &obj, 1) != CAL_RESULT_OK)
{
fprintf(stderr, "There was an error linking the program.\n");
fprintf(stderr, "Error string is %s\n", calclGetErrorString());
return 0;
}

if (calclFreeObject(obj) != CAL_RESULT_OK)
{
fprintf(stderr, "There was an error freeing the compiler object.\n");
fprintf(stderr, "Error string: %s\n", calclGetErrorString());
return 0;
}
if (disassemble == CAL_TRUE)
{
calclDisassembleImage(image, __logger);
}

// Load module into the context
if (calModuleLoad(module, *ctx, image) != CAL_RESULT_OK)
{
fprintf(stderr, "There was an error loading the program module.\n");
fprintf(stderr, "Error string is %s\n", calGetErrorString());
return 0;
}

if (calclFreeImage(image) != CAL_RESULT_OK)
{
fprintf(stderr, "There was an error freeing the program image.\n");
fprintf(stderr, "Error string is %s\n", calGetErrorString());
return 0;
}

return 1;
}

Error:
There was an error getting device attribs.
Error string is Parameter passed in is invalid

Has this something to do with 64-bit or crossfire?

[frankas]

Originally posted by: the729 Welcome to the world of GPGPU.

Why not use OpenCL? I think the old Brook+ is deprecated.

By the way, there is no ATI.cpp or ATI.br in the Brook sample codes. So there should not be any object file named ATI.obj. Simply remove it from the linker settings and see what happens?

Who says brook is deprecated ? - It will be perhaps, but try running with multiple GPUs on Linux, and your stuck with Brook+ and 9.10 drivers for the time being. I'd love to switch to OpenCL, even though you have to write many more lines of codes to invoke a simple kernel. But the truth is that OpenCL isn't quite ready for prime time yet. But if you can get OpenCL working, then go ahead, but since most brook code is trivial to port to OpenCL you won't be stuck with Brook+ if you start there.