ROCm-OpenCL-Runtime VS avendish

Its not that they're supporting buggy code, they just downgraded the quality of their implementation significantly. They made the compiler a lot worse when they swapped to rocm

https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/iss... is the tracking issue for it filed a year ago, which appears to be wontfix largely because its a lot of work

OpenCL still unfortunately supports quite a few things that vulkan doesn't, which makes swapping away very difficult for some use cases

There's https://docs.amd.com/bundle/ROCm-Installation_FAQ/page/Frequently_Asked_Questions.html which leads to a page which doesn't list any gpus that I can see, there's https://rocm.docs.amd.com/en/latest/release/gpu_os_support.html which lists "RDNA2" , there's https://github.com/RadeonOpenCompute/ROCm/issues/1698 which is from last year and mentions changing an env for the RX 6600 XT (navi 23) . Not a lot is mentioned in the readme of https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime .

$ dnf info rocm-opencl Installed Packages Name : rocm-opencl Version : 5.4.3 Release : 2.fc38 Architecture : x86_64 Size : 1.7 M Source : rocm-opencl-5.4.3-2.fc38.src.rpm Repository : @System From repo : updates Summary : ROCm OpenCL Runtime URL : https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime License : MIT Description : ROCm OpenCL language runtime. : Supports offline and in-process/in-memory compilation.

Thank you for subscribing to AMD OpenCL Facts! To unsubscribe please type AARRHGHGH. I'm open for questions though, and the bug report for this is here. For more mildly disgruntled rambling:

Eg this bug about shared cl/gl textures with mipmaps being broken has now breached its first birthday, without even acknowledgement - basic cl/gl functionality here. This bug took a year for a fix to make its way into a public driver. And this fairly performance critical bug is just "wontfix", and also a significant downgrade from their old driver stack

Its definitely workable if you're willing to put in the effort (except for things that are straight up broken in some cases, like device side enqueue), but there are some issues that require.. fairly major workarounds

Their implementation is here: https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime

After a lot of moderately annoyed testing, I discovered that the AMD OpenCL implementation is.. rather dumb. If any two kernels share any arguments arguments, it inserts a command barrier between the two, hard-stalling the GPU. After filing a bug, it turns out this is wontfix as well, which is doubly bad. There's no set of flags in OpenCL that you can use to fix this either

What's particularly bizarre, is that with one bug report I filed, they claim to have fixed it internally in april, but.. no public driver has ever been released with the fix. For 7 months? Which is just a bizarre software development process

Happy to introduce you to https://ossia.io there are a lots of tasks open! You can check the projects for the general development axes: https://github.com/ossia/score/projects?query=is%3Aopen ; e.g. Audio, Musicality, Integrations, JACK & Linux integration (some are in Classic projects mode) all have audio-related tasks, some easy, some hard.

Creating new Avendish plug-ins (docs: https://celtera.github.io/avendish/) could also be fairly useful, here's a very basic example one: https://github.com/celtera/avendish/blob/main/examples/Advan...

If you are interested in making max, pd, etc... extension you can look into https://github.com/celtera/avendish : it's made exactly for this and tries to stay very close from standard C++ unlike most existing audio frameworks which often come with their own bespoke standard library reimplementation. The documentation also tries to explain the c++ features it used, you might find this useful!

to automatically generate safe dlopen stubs for runtime dynamic library loading from header files

and through the C++ one (this one is an extremely quick and dirty prototype):

https://github.com/ossia/score/blob/master/src/plugins/score...

to pre-instantiate get(aggregate), for_each(aggregate, f) and other similar functions in https://github.com/celtera/avendish because of how slow it is when done through TMP (doing it that way removed literally dozens of megabytes from my .o and had a positive performance impact even with -O3) ; so I weep a lot when I read that people in the committee object to pack...[indexing]

I really don't know about this, I'm writing audio & media effects in a fairly declarative style with https://github.com/celtera/avendish and I'm so much more productive that it's not even funny - I can rewrite entire effects from scratch in the time that it used to take me to find a bug somewhere

For anyone using c++, my declarative system has some amount of support for clap: https://github.com/celtera/avendish / https://celtera.github.io/avendish/

But unlike clap, targetting this also gives direct access to a few other environments, namely Max, Pd, ossia score, with the list hopefully growing.

Here is an example minimal plugin : https://github.com/celtera/avendish/blob/main/examples/Raw/M...

Note that unlike pretty much every other c/c++ plugin API, the plugin code does not need to include any header, everything is done through reflection of struct members at compile-time.

Here's a per-sample noise generator which uses a small library of pre-made ports: https://github.com/celtera/avendish/blob/main/examples/Helpe...

And a very naive buffer-based audio filter : https://github.com/celtera/avendish/blob/main/examples/Helpe...

UI is supported without relying on a specific UI library, only on a canvas painter concept which can then target Qt, NanoVG, and others to come: https://github.com/celtera/avendish/blob/main/examples/Helpe...

since it binds directly to audio APIs at compile time, it has pretty much zero code size in itself, the smallest plugin it generates for VST2 is around 7kb IIRC

I've ported my lib https://github.com/celtera/avendish to P1061's experimental clang implementation to replace boost.pfr (https://github.com/celtera/avendish/blob/main/include/avnd/common/aggregates.hpp#L67) and it works great, it's only missing pack indexing because right now one still needs to do something like

Working on a sunset of this with https://github.com/celtera/avendish - C++ reflection makes this very easy

so interesting, as a mostly C++ dev, UE's C++ style feels absolutely awful aha. Of course they have to be here because c++ used to not have reflection but I think that nowadays one could use similar principles as the ones I've tried to develop for audio / media objects in https://github.com/celtera/avendish to implement game objects / UObject in a much cleaner way and with better compile times