1 Reply Latest reply on Jun 12, 2009 8:14 PM by emuller

    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...

        • Using both CAL and Brook+ in the same program

          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?