[Parallel_libs-dev] StreamExecutor design questions

James Price J.Price at bristol.ac.uk
Fri Sep 2 12:32:16 PDT 2016


I’ve thrown together a quick and dirty OpenCL backend for SE to play around with writing some application code that uses it, and as a result have one or two design questions. I know it’s early days so I apologise if I’m jumping the gun.

What’s the motivation for having the PlatformKernelHandle and PlatformStreamHandle classes, rather than just using opaque pointers? These classes result in a some extra subclassing when implementing an SE backend, just to wrap a platform specific pointer (e.g. cl_kernel or cl_command_queue), but maybe I’m missing the point here. It also seems to be slightly inconsistent with the device memory stuff, which uses raw opaque pointers at the PlatformDevice level.

It also seems that there is no way for a user to fully release the resources used by a SE device, since the end-user doesn’t own the Device pointer. Maybe I’m worrying about nothing here, but I wonder whether there may be some devices that become ‘unhappy' if you don’t release their contexts/default queues etc before the application exits.

Other minor points that I came across:

- If you *do* want the PlatformKernelHandle class, PlatformInterfaces.cpp was missing its destructor implementation.

- Should Device have a getName() that forwards onto PlatformDevice? Otherwise there seems to be no way for the end-user to get at the name.

- Missing LICENSE.txt at the top-level parallel-libs directory?

For reference, I’ve thrown this OpenCL backend up here (it’s not great, but it works):



More information about the Parallel_libs-dev mailing list