Veganism Social

Giuseppe BilottaEven now, Thrust as a dependency is one of the main reason why we have a <a href="https://fediscience.org/tags/CUDA" class="mention hashtag" rel="nofollow noopener" target="_blank">#CUDA</a> backend, a <a href="https://fediscience.org/tags/HIP" class="mention hashtag" rel="nofollow noopener" target="_blank">#HIP</a> / <a href="https://fediscience.org/tags/ROCm" class="mention hashtag" rel="nofollow noopener" target="_blank">#ROCm</a> backend and a pure <a href="https://fediscience.org/tags/CPU" class="mention hashtag" rel="nofollow noopener" target="_blank">#CPU</a> backend in <a href="https://fediscience.org/tags/GPUSPH" class="mention hashtag" rel="nofollow noopener" target="_blank">#GPUSPH</a>, but not a <a href="https://fediscience.org/tags/SYCL" class="mention hashtag" rel="nofollow noopener" target="_blank">#SYCL</a> or <a href="https://fediscience.org/tags/OneAPI" class="mention hashtag" rel="nofollow noopener" target="_blank">#OneAPI</a> backend (which would allow us to extend hardware support to <a href="https://fediscience.org/tags/Intel" class="mention hashtag" rel="nofollow noopener" target="_blank">#Intel</a> GPUs). <<a href="https://doi.org/10.1002/cpe.8313" rel="nofollow noopener" translate="no" target="_blank">https://doi.org/10.1002/cpe.8313</a>>This is also one of the reason why we implemented our own <a href="https://fediscience.org/tags/BLAS" class="mention hashtag" rel="nofollow noopener" target="_blank">#BLAS</a> routines when we introduced the semi-implicit integrator. A side-effect of this choice is that it allowed us to develop the improved <a href="https://fediscience.org/tags/BiCGSTAB" class="mention hashtag" rel="nofollow noopener" target="_blank">#BiCGSTAB</a> that I've had the opportunity to mention before <<a href="https://doi.org/10.1016/j.jcp.2022.111413" rel="nofollow noopener" translate="no" target="_blank">https://doi.org/10.1016/j.jcp.2022.111413</a>>. 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 isa. too much effort b. probably not worth it.Again, following <a href="https://peoplemaking.games/@eniko" class="u-url mention" rel="nofollow noopener" target="_blank">@eniko</a>'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/

Giuseppe BilottaI'm getting the material ready for my upcoming <a href="https://fediscience.org/tags/GPGPU" class="mention hashtag" rel="nofollow noopener" target="_blank">#GPGPU</a> course that starts on March. Even though I most probably won't get to it,I also checked my trivial <a href="https://fediscience.org/tags/SYCL" class="mention hashtag" rel="nofollow noopener" target="_blank">#SYCL</a> programs. Apparently the 2025.0 version of the <a href="https://fediscience.org/tags/Intel" class="mention hashtag" rel="nofollow noopener" target="_blank">#Intel</a> <a href="https://fediscience.org/tags/OneAPI" class="mention hashtag" rel="nofollow noopener" target="_blank">#OneAPI</a> <a href="https://fediscience.org/tags/DPCPP" class="mention hashtag" rel="nofollow noopener" target="_blank">#DPCPP</a> runtime doesn't like any <a href="https://fediscience.org/tags/OpenCL" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenCL</a> platform except Intel's own (I have two other platforms that support <a href="https://fediscience.org/tags/SPIRV" class="mention hashtag" rel="nofollow noopener" target="_blank">#SPIRV</a>, so why aren't they showing up? From the documentation I can find online this should be sufficient, but apparently it's not …)

Benjamin Carr, Ph.D. 👨🏻‍💻🧬Just how deep is <a href="https://hachyderm.io/tags/Nvidia" class="mention hashtag" rel="nofollow noopener" target="_blank">#Nvidia</a>'s <a href="https://hachyderm.io/tags/CUDA" class="mention hashtag" rel="nofollow noopener" target="_blank">#CUDA</a> moat really? Not as impenetrable as you might think, but still more than Intel or AMD would like It's not enough just to build a competitive part: you also have to have <a href="https://hachyderm.io/tags/software" class="mention hashtag" rel="nofollow noopener" target="_blank">#software</a> that can harness all those <a href="https://hachyderm.io/tags/FLOPS" class="mention hashtag" rel="nofollow noopener" target="_blank">#FLOPS</a> — something Nvidia has spent the better part of two decades building with its CUDA runtime, while competing frameworks for low-level <a href="https://hachyderm.io/tags/GPU" class="mention hashtag" rel="nofollow noopener" target="_blank">#GPU</a> <a href="https://hachyderm.io/tags/programming" class="mention hashtag" rel="nofollow noopener" target="_blank">#programming</a> are far less mature like AMD's <a href="https://hachyderm.io/tags/ROCm" class="mention hashtag" rel="nofollow noopener" target="_blank">#ROCm</a> or Intel's <a href="https://hachyderm.io/tags/OneAPI" class="mention hashtag" rel="nofollow noopener" target="_blank">#OneAPI</a>. <a href="https://www.theregister.com/2024/12/17/nvidia_cuda_moat/" rel="nofollow noopener" translate="no" target="_blank">https://www.theregister.com/2024/12/17/nvidia_cuda_moat/</a> <a href="https://hachyderm.io/tags/developers" class="mention hashtag" rel="nofollow noopener" target="_blank">#developers</a>

Recent searches

Search options

Administered by:

Server stats:

#oneapi