I'm still mildly suspicious that some of my perf problems (esp.
-
@lisyarus If it's just Linux and Windows then DX11 and a matching modern flavour of OGL still work perfectly well, and I prefer the balance of how much work I have to do versus what the driver does for me.
-
-
-
> Linux
> DX11Tbh, a Win32 binary using D3D11 is most like more future proof on Linux than a native desktop-Linux executable
-
-
@lisyarus If it's just Linux and Windows then DX11 and a matching modern flavour of OGL still work perfectly well, and I prefer the balance of how much work I have to do versus what the driver does for me.
@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
-
@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".
-
-
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?
-
@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
@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.
-
@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
@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).
-
@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".
@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.
-
R ActivityRelay shared this topic
