cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

JiaweiOu
Journeyman III

Using both CAL and Brook+ in the same program

Have someone tried to use  Brook+ and CAL in the same program?

I found that calInit() is not referece counted. and calOpenDevice() can not reopen a same device twice. If I call calInit() before using Brook+ will cause the Brook+'s CAL runtime failed to initialized.

Moreover, if device with ID 0 is opened somewhere, the Brook+ will not work too. This is a big problem. Although CAL provide context management for multi-thread access to the same device. Two CAL-based GPGPU modules still cannot use the same device, if they don't know the existence of each other, and communicate for the device handle..

Finally, I don't know where to calShutdown() CAL...

0 Likes
1 Reply
emuller
Journeyman III

I would be happy if there was an idiom for running cal kernels in a primarily  brook workflow.  But digging in the brook source, it appears to me that not even streams are willing to expose an uderlying CALmem or CALresource ...

Looking at the .cpp, .h and _gpu.h generated by brcc one should be able to hack a kernel class which runs il code provided as strings ... but why are there these cal_desc_tech1_pass0 cal_desc_tech0_pass0 ... and why does even a simple sum kernel produce such dirty il code?

 

 

 

0 Likes