Does using PoCL require OpenCL code refactoring in any way or can it be simply be selected to run unchanged OpenCL software that hasn't taken it into consideration?
Also isn't a direct path from OpenCL to Vulkan potentially better in the long run than the extra crazy roundtrip done via Zink and the less-close-to-metal features offered by Gallium? If that's the case I wouldn't scrape PoCL so quickly even if it currently lags behing...
-
PoCL predates rusticl by a fair chunk, but rusticl has a couple large advantages, the most important being that it's built on the already mature and highly battle tested gallium stack, meaning a lot of work for rusticl was already done to get it working, (gallium is lovely for a reason).Originally posted by R41N3R View Post
EDIT: so you could say that while PoCL predates rusticl, gallium predates PoCL so a lot more work has been put into that.Leave a comment:
-
Another solution of OpenCL on Vulkan :-) It will be interesting to compare PoCL to Rusticl on Zink at some point.Leave a comment:
-
While I'm all for multiple implementations and pathways as much as the next guy, I fully expect rusticl will kill this thing.Leave a comment:
-
FYI for CUDA it states: Currently this backend has only been tested against CUDA 8.0.Leave a comment:
-
PoCL 3.1-RC1 Released With Improved SPIR-V Support For CPU & CUDA Drivers, Vulkan WIP
Phoronix: PoCL 3.1-RC1 Released With Improved SPIR-V Support For CPU & CUDA Drivers, Vulkan WIP
PoCL 3.1 is nearing release as the "Portable Computing Language" that is most known for serving as a CPU-based OpenCL implementation but via its LLVM usage also allows supporting OpenCL execution atop NVIDIA CUDA and other targets...
Leave a comment: