What an honor to start the #IWOCL conference with my keynote talk! Nowhere else you get to talk to so many #OpenCL and #SYCL experts in one room! I shared some updates on my #FluidX3D #CFD solver, how I optimized it at the smallest level of a single grid cell, to scale it up on the largest #Intel #Xeon6 #HPC systems that provide more memory capacity than any #GPU server. 
Even now, Thrust as a dependency is one of the main reason why we have a #CUDA backend, a #HIP / #ROCm backend and a pure #CPU backend in #GPUSPH, but not a #SYCL or #OneAPI backend (which would allow us to extend hardware support to #Intel GPUs). <https://doi.org/10.1002/cpe.8313>
This is also one of the reason why we implemented our own #BLAS routines when we introduced the semi-implicit integrator. A side-effect of this choice is that it allowed us to develop the improved #BiCGSTAB that I've had the opportunity to mention before <https://doi.org/10.1016/j.jcp.2022.111413>. Sometimes I do wonder if it would be appropriate to “excorporate” it into its own library for general use, since it's something that would benefit others. OTOH, this one was developed specifically for GPUSPH and it's tightly integrated with the rest of it (including its support for multi-GPU), and refactoring to turn it into a library like cuBLAS is
a. too much effort
b. probably not worth it.
Again, following @eniko's original thread, it's really not that hard to roll your own, and probably less time consuming than trying to wrangle your way through an API that may or may not fit your needs.
6/
Performance portability via C++ PSTL, SYCL, OpenMP, and HIP: the Gaia AVU-GSR case study
#HIP #SYCL #OpenMP #CUDA #PerformancePortability #HPC #Astrophysics #Package
One of the nice things of the refactoring that I had to do to introduce CPU support is that it also allowed me to trivially had support for #AMD #HIP / #ROCm.
That, and the fact that AMD engineers have written a drop-in replacement for the Thrust library that we depend on in a couple of places. (This is also one of the things that is holding back a full #SYCL port for #GPUSPH, BTW.)
It's out, if anyone is curious
https://doi.org/10.1002/cpe.8313
This is a “how to” guide. #GPUSPH, as the name suggests, was designed from the ground up to run on #GPU (w/ #CUDA, for historical reasons). We wrote a CPU version a long time ago for a publication that required a comparison, but it was never maintained. In 2021, I finally took the plunge, and taking inspiration from #SYCL, adapted the device code in functor form, so that it could be “trivially” compiled for CPU as well.
Howdy all - registrations are still open for the first oneAPI DevSummit hosted by the UXL Foundation! Learn about GPGPU programming, oneAPI and how companies are coalescing around #oneapi / #sycl
https://linuxfoundation.regfox.com/oneapiuxldevsummit2024
Registration will closeat 5pm today. The DevSummit will start at 8pm PT or 8:30am IST. See you there!
Two very busy and exhausting days at the @thekhronosgroup face-to-face planning out some awesome #SYCL developments for the coming year. Keep an eye on the news feed at https://khronos.org/sycl for more details soon...
Hit the Van Sickle (#SYCL?) trail today, always a good time.
Do I have anyone in my wider network with skills in programming CUDA, SYCL, and OpenCL?
We want to determine feasibility of migrating CUDA-only code to SYCL (via SYCLomatic?): OpenCV feature detection/extraction modules (SIFT, HAGOG, ORB, AKAZE).
The intent is to upstream all feasible work.
This, hopefully, should stand to benefit everyone instead of being limited to NVIDIA.
Currently in info gathering/people connecting phase, not yet funded & ready to go.
James Reinders et al. have released the second edition of their SYCL book "Data Parallel C++", available for free in PDF and EPUB: https://link.springer.com/book/10.1007/978-1-4842-9691-2
"SYCL is a royalty-free open standard developed by the Khronos Group that allows developers to program heterogeneous architectures [such as CPUs, GPUs, and FPGAs] in standard C++."
Hey folks! We have two speaker slots available to talk about heterogeneous computing at our community led forum @ Berkeley - would someone be willing to speak in person at Berkeley? Please boost!#oneapi #sycl
https://www.meetup.com/oneapi-community-us/events/296111342/
Saturday Oct 7th
What an amazing talk by @airlied on the state of vendors, compute and community feedback. Please take the 45 minutes to watch - worth every minute! https://youtu.be/HzzLY5TdnZo
For those who have waited eagerly for the recording of our #oneapi meetup with @karolherbst - here it is! https://youtu.be/KUze0JbPSy8
#sycl #opencl #rustlang - if you are interested in joining our oneAPI meetup - feel free to subscribe here - https://www.meetup.com/oneapi-community-us/
Next time we will be meeting with Stephano Cetola who will be talking about RISC-V, onAPI, and other things.
Did a #SyCL CTS run via DPCPP on #Rusticl on my sycl branch: https://gitlab.freedesktop.org/karolherbst/mesa/-/commits/rusticl/sycl/
`57% tests passed, 36 tests failed out of 84`
not bad, not great, though some fails are not directly rusticls fault:
- bugs inside DPCPP
- invalid SPIR-V generated by DPCPP, had to disable SPIR-V validation
- some tests assume optional CL extensions (like Intel_usm)
- some tests require Program Scope Global Variables, which are pain to implement.
9 of the fails are trivial Mesa, so I'll handle those.
(Thread)
Wanted to give a quick thanks to @sri for having me on as part of the #OneAPI Accelerated compute panel yesterday
Had a good time discussing what does and doesn't work across oneAPI, #SYCL and how to deal with SYCL as a standard.
I also want to reiterate that SYCL or oneAPI as standards are not "magic bullets" for performance across all hardware
The major point of them, like most libraries and software stacks, is to get you to ~90% of performance without having to rewrite the stack
Corporate #FLOSS at its worst: #NVIDIA controls the #Thrust library and its #CUDA, #OpenMP and #TBB backend. #AMD provides rocThrust, that is just Thrust with the CUDA part stripped an a new backend for #ROCm / #HIP. Nobody* is working on a backend for #SYCL
#Intel provides its own #oneAPI alternative as #oneDPL, which is NOT a drop-in replacement.
This is why we can't have nice things.
*there's a dead project here
https://github.com/wdmapp/syclthrust
