I'm still mildly suspicious that some of my perf problems (esp.

@oblomov @lisyarus The trick is to read ALL the words I wrote, not just some of them.

@oblomov @TomF @lisyarus

> Linux
> DX11

Tbh, a Win32 binary using D3D11 is most like more future proof on Linux than a native desktop-Linux executable

@floooh @TomF @lisyarus

sadly 8-(

@TomF Uhh, then I could just use OpenGL and that's it, why write two backends if one works on both platforms?

I'd go this way from the start of OpenGL wasn't this crappy global-state API with seven thousand layers of legacy on top

@oblomov @TomF @lisyarus IMHO the small-ish subset of Win32+D3D+DXGI needed for game development is actually a quite nice (and stable!) "cross-platform API".

@pierogiburo @lisyarus I second this. Modern vulkan is pleasant. Hard part is actually knowing the "correct" API in vulkan since the working group refuses to actually remove anything for backwards compatibility. Atleast the documentation has startet to label some functions that are considered "deprecated".

@TomF @lisyarus

can I pretend it's your fault for using a chiastic structure in the post? *whistles innocently*

@floooh @TomF @lisyarus

Does Wine have a macOS port? I know mesa does, so this might make it possible to leverage the various dx->vulkan layers for the graphics part.

Oh wait with the new ARM stuff that wouldn't work at all without some kind of lower level emulation. Was this what Valve was working on for their new VR thing?

@lisyarus This is a fair point. I write DX11 as the "golden path" because that's what I know best, and then translate to the equivalent OpenGL and ignore all the wacky variants/extensions of OGL that don't directly correspond to the DX11 equivalents. But you could just skip writing the DX11 code entirely I guess? I don't have a broad enough experience of OGL to know if that's wise.

@lisyarus @TomF You can simplify an awful lot of OpenGL these days, but the largest problem is that tool support for decent profiling has pretty much disappeared. A secondary issue is that I have experienced some performance issues due to shader compilation for long shaders, which is why Avoyd's path tracer runs on Vulkan.

A lot of Vulkan's verbosity issues can be worked around with some support code, and it is getting simpler to write (though I stick to an older subset for compatibility atm).

@avokado @pierogiburo @lisyarus I'm testing my assumptions and memory here, as I did try to hook #Vulkan to a framework at work.

Afaik, despite the lot-of-typing, Vulkan also provides error cues for troubleshooting like nothing I've seen so far. Or is there?

There's no other C++ native rendering framework that woud cater with a unified shader format without all the other connected bloat (like bgfx) now that Circle's effort was ditched. Right?

You can use modern ogl as the input for Vulkan though you'll depend on transpiling it to spirv and then to the platform specific format. I don't think this is an issue as I had an autoloading cmake job to handle this on file changes.

Macos is quite the divide here as the deprecated the ogl long ago and Metal, though it's quite good, is just different from DX.