ROCm-OpenCL-Runtime VS Jinx

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.

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

Could you report these issues here https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime? Regarding the device side enqueue issue, could you attach a simple test case to the issue that reproduces the crash? The current pastebin link doesn't give enough info.

Check out jinx https://jamesboer.github.io/Jinx/

Don't get me wrong, I'm a big fan of automated tests where it makes sense. I wrote a scripting language that I use for my personal game projects, and I never would have been able to do it if it weren't for the battery of tests for every feature, error, and corner case I could think of. But games are rarely like other software, with hard rules about what is "correct" or "incorrect". And it would be a nightmare to try to keep up with designers, constantly tweaking and tuning, so what's "correct" is literally a day to day, constantly moving target.

A second trial for you might be Jinx. Depending on your definition of procedural, Jinx is 100% only procedural. https://jamesboer.github.io/Jinx/

Jinx (embeddable scripting language) works as following:

If you're working in UTF-8 internally, you could just write your own UTF-16 to UTF-8 conversion functions to convert strings at API boundaries. I did this in my scripting language because I didn't want to bring in dependencies.

Jinx is a scripting language specifically written for game development, and is written in modern C++. The syntax is clean and readable, looking a bit like pseudo-code or natural language phrases, thanks to functions with highly flexible syntax. Scripts are designed to operate asynchronously by default, ideal for attaching to game objects as long-lasting behaviors. I originally wrote it for my own engine and game, and then released it as open source.

I should point out that if anyone is interested in learning how to perform multi-platform (Windows/macOS/Linux) Continuous Integration on Github using automated Actions, this is a fairly simple example of how to do so. It's not difficult, but it's a bit tricky to find simple, clear examples of this online for some reason - or at least it seemed so when I was looking. Sort of odd, since it seems like this is one of the basic examples you'd want to see more of, but...

Jinx is mostly in maintenance mode (now at v1.3.5), since the addition of more support for functional and async programming earlier last year. It's cool to see evidence that a few people are actually using the language as intended as embedded scripting for their videogame engines, similar to what I did, as indicated by the fact that I get occasional questions and/or feature requests.

Sure, but this is due to the nature of the work we do. How would you set up an automated test to make sure the audio system plays sounds correctly, for example? How do you set up an automated test to tell if the game isn't as fun with the new controller scheme? I've seen a few companies try heavily automated testing, and it inevitably wastes huge amounts of resources for little gain. A small QA team that plays the game every day is still the best way to keep the quality bar high. I'm a huge fan of automated testing where it makes sense (for instance, in my scripting language Jinx, I have a large battery of automated unit tests), but it just doesn't work well for most games, with some rare exceptions.

I actually solved some of this with my own scripting language called Jinx, in which every script executes as a co-routine, so you can just write any sort of time-based logic as needed. I later added explicit async / coroutine support for functions inside scripts as well at another user's request.