OpenCL API #567
Replies: 2 comments 5 replies
-
|
To bridge the gap between low-level OpenCL APIs and JVM-focused mod developers, I recommend looking at JavaToGPU (A WIP project, but all the basic functionality has already been implemented): Writing raw OpenCL C kernels inside Java strings and manually managing native buffers has a high entry barrier. This library solves that by translating standard Java bytecode into GPU kernels at runtime. Key Features:
Providing a high-level tool like this alongside Cleanroom's core OpenCL implementation would make GPU-accelerated modding actually accessible for the community. |
Beta Was this translation helpful? Give feedback.
-
|
You could have told me back when I didn't have the minimal viable product 90% ready. |
Beta Was this translation helpful? Give feedback.
-
Well, the JavaToGpu project itself only just hit a stable alpha xD |
Beta Was this translation helpful? Give feedback.
-
|
Having learned about the OpenCL feature in the Cleanroom core, I would like to raise a number of serious architectural concerns and questions that any mod developer will inevitably face. 1. Unreliability of Text Kernel compilation. 2. Architecture and vendor fragmentation. 3. Device selection issues (iGPU vs. dGPU). 4. Register pressure and resource exhaustion. 5. Whose responsibility is hardware-specific optimization? Forcing modders to manually check the resources of every possible GPU, study the nuanced memory behavior of iGPUs vs. dGPUs, and write hacky workarounds creates a colossal barrier to entry. Without a high-level abstraction that takes on the burden of generating correct, hardware-aware code and managing memory safely, GPU acceleration in mods will remain a niche domain for a few enthusiasts, rather than an accessible standard for the community. |
Beta Was this translation helpful? Give feedback.
-
|
Just so you know, I am not angry at the criticism or anything, I think the criticism and concerns are valid as it can help with directing the API towards beng usable by mod developers without increasing the workload massively.
This is meant to be the high-level abstraction.
Partially addressed as the setup for the Compute API will prioritise known GPU architectures (currently only cuda, this will be expanded), this can be used to prioritise or force SPIR-V support. The whole thing will also be opt-in or opt-out depending on the hardware of the player. Not everyone has drivers for this so unless mods are specifically made to provide optimizations based on hardware acceleration or perform heavy calculations (physics based mods), the modder should provide alternative code for the mod. It is a workload increase but considering that this API is going to be an abomination no matter how much work is put into making it humanely usable, it might be better to have something to deter people from being too trigger-happy about using it. |
Beta Was this translation helpful? Give feedback.
-
I appreciate the open and constructive response. It is great to hear that the feedback is being taken seriously to shape the API. However, I have to respectfully push back on a couple of points, particularly regarding the definition of a 'high-level abstraction' and the design philosophy behind it. 1. Wrapper vs. True Abstraction 2. The 'Deterrent' Philosophy
The Goal: Make the 'Safe' Path the 'Easy' Path For example, if a modder could write standard, type-safe Java code, and a tool would automatically handle the translation to SPIR-V, manage zero-copy memory for iGPUs, and gracefully fall back to CPU execution when needed, the workload drops dramatically. The modder focuses on game logic, not driver quirks. I am raising these points because I genuinely want to see GPU acceleration succeed and become a stable standard in the community. I fear that the current approach might lead to a fragmented, unstable ecosystem rather than a robust one. I understand this might look like an attempt to promote my own library, JavaToGpu. However, my goal is to visually demonstrate what the developer experience actually looks like with a true high-level abstraction, and I firmly believe this is the ideal approach. @GPU
public static void basicMath(
@GPUGlobal float[] input,
@GPUGlobal float[] output
) {
int id = GPU.get_global_id(0);
FloatPtr ptr = new FloatPtr(input[id]);
// Modder uses familiar Java-like syntax and existing library functions
SomeGpuLibrary.clamp(ptr);
output[id] = SomeGpuLibrary.lerp(ptr.value, GPU.sin(input[id]), 0.25f);
}
void someMethod(...) {
float[] input = new float[256];
float[] out = new float[256];
// ... some code initializing input ...
// The API handles device selection, memory transfer, and kernel execution
try (GpuRuntimeScope runtimeScope = GpuRuntime.useOpenClSharedCache()) {
basicMath(input, out);
} catch (GpuRuntimeBackendUnavailableException ex) {
// Graceful, easy-to-implement fallback
cpuFallback(input, out);
}
// ... continue with out array ...
}In this scenario, the developer writes GPU logic in standard, type-safe Java without having to deal with raw kernel strings, manual native buffer management, or vendor-specific quirks. I fully understand that low-level code provides maximum flexibility, but it simultaneously imposes a massive maintenance burden. A true high-level abstraction should allow modders to focus entirely on the game algorithm, while the underlying tool handles the hardware translation, memory optimization (like zero-copy for iGPUs), and graceful CPU fallbacks. |
Beta Was this translation helpful? Give feedback.
-
|
hello skynet! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
Add an OpenCL wrapper (preferrably the LWJGL one) to Cleanroom
Goals
Non Goals
Motivation
There are many kinds of calculations in video games that can be sped up by parallelizing them on the GPU. OpenGL already has that feature in the form of compute shaders, however sadly, it only allows for features implemented at the time OpenGL 4.6 was released. OpenCL would allow developers to write Vulkan Compute level GPU computations without actually implementing Vulkan in the game. There are some mods that might implment their own physics, calculating them with OCL would reduce the load it would take on the CPU. This mainly applies to custom build vehicle mods like Valkyrien Skies and Davinci's Vessels which are notoriously heavy on the tick rate. Adding an API like this would allow for easy integration of paralellized computation without relying on interfacing native code written physics engine as it is done by VS2.
I'm pretty sure OpenGL is also client only, so the compute shaders can't run on the server.
Description
Add a Java OpenCL library to Cleanroom, implement a high level API that wraps around it. Make them avaliable on both client and server.
Dependencies
References
Guidelines
Beta Was this translation helpful? Give feedback.
All reactions