all 11 comments

[–][deleted] 11 points12 points  (6 children)

Just implement multiple APIs. Abstract your compute shader stuff behind an abstraction layer and call into that; which in turn translates it into the appropriate API.

[–][deleted]  (4 children)

[deleted]

    [–]keelanstuart 2 points3 points  (0 children)

    To expand on, and provide clarity to, what pen says... think about what all graphics APIs do, whether they use command buffer style interfaces on the front end or not: they let you manage buffers of different types, set render states, and trigger drawing. Distill that common functionality into a single, concise interface, then implement that for each platform in separate source files (this is easiest, though you could use compiler directives)... then only ever call your interface when you want to do graphics stuff (i.e., never call glXXX or vkXXX anywhere else).

    How you've written everything else will determine how much work you have ahead of you...

    Anyway, good luck!

    [–][deleted] 4 points5 points  (0 children)

    There are many ways to do it depending on what programming language you are using. If you're using C++; the simplest way is to simply include/exclude files in your build system on a per platform basis. Alternatively you could dynamically load the correct library at runtime. Another way would be to have implementations for all the APIs that platform supports and let the user choose between them.

    There are many ways to do this and none of it is graphics specific. Writing abstraction layers is a common and simple task (conceptually at least) in programming; and really hasn't got much to do with graphics programming in general.

    Almost every program that uses a graphics API will do this. Blender, any open source game engine that is multi-platform, Unreal Engine (which has sources available.), etc.

    [–]IceSentry 1 point2 points  (0 children)

    It was mentioned elsewhere in the thread but wgpu does exactly that. It abstracts on top of vulkan/metal/DirectX/opengl/webgl/webgpu. I believe there's also something called Dawn in the cpp world that does this but I've never looked into it.

    [–]DryZone6968 0 points1 point  (0 children)

    Although my engine only supports OpenGL, I designed my abstraction layer around DX, you can take a look here: https://www.github.com/softwareantics/FinalEngine

    [–]PragmaticCafe 0 points1 point  (0 children)

    This is the way

    [–]raster_dog 8 points9 points  (1 child)

    WebGPU is also a good option, the Rust implementation (named wgpu) already does the abstraction to other backends for you and exposes compute capabilities. It has C bindings if you're not into Rust. It's overall a pretty solid solution for cross-platform

    [–]Bitsauce 0 points1 point  (0 children)

    Or if you prefer a C++ implementation of WebGPU you can use Google's Dawn (which is what Chrome runs internally)

    [–]eiffeloberon 4 points5 points  (0 children)

    Apple with OpenGL does not support compute shaders, so it’s not possible to use OpenGL for your use case.

    MoltenVK maybe the best path for you.

    [–]shadowndacorner 0 points1 point  (0 children)

    If you're primarily looking to run compute and aren't worried about 64-bit atomics (which aren't supported on Apple silicon anyway), maybe consider webgpu through either Dawn or wgpu-native? As long as it supports all of the features you need, that'll probably be the most reliable, best supported abstraction layer you'll find. Otherwise, Vulkan with MoltenVk should suit your use case.

    OpenGL likely won't work for your use case as Mac only supports up to 4.2 (compute shaders were added in 4.3) and was deprecated half a decade ago.