Author here. Rx is actually built on WGPU[0] which will eventually have OpenGL support too. However, I don't really see much of a future for OpenGL - so building a graphics application today - I would pick something like Vulkan over OpenGL, given the choice.
And to clarify further, the next wgpu-rs version will not have features for backends. Vulkan/Metal/DX12/DX11 will be automatically exposed where appropriate, so there will not be a requirement to have Vulkan.
It just seems like an overkill and unnecessary requirement for a pixel editor. The first one I used ran just fine with software rendering on a 25Mhz CPU.
It’s not about power, it’s about portability. As far as I’m aware there is no simple, low level, software based, portable, 2D graphics stack.
The software you ran on a 25MHz machine was in all likelihood written in assembly, directly interfacing with the hardware of your machine, without even touching your windowing system (if you even had one, maybe you were running DOS). Modern operating systems frown on that sort of thing with extreme prejudice.
SDL isn’t really simple or low level. You can use it to get an OpenGL context but its built-in 2D stack is very high level (and not very useful for a pixel editor).
Today, it seems that Vulkan is really the most portable engine available. OpenGL support has kind of stagnated.
I would have thought SDL is probably a better target for this type of application. However, I'm happy to see developers use what they like and push the envelope how they like.
Just upgraded to Linux kernel 5.3 and beta mesa & vulkan so I can drop in my rx5700xt, which I still need to do.
The problem is that vulkan was specifically designed to throw away an amount of portability in favour of allowing lower level access to hardware features. If said hardware features don't exist on a platform, you're stuck. Note the "The Vulkan Portable Subset" having to throw away a number of features to have it work on a number of underlying platforms https://www.khronos.org/vulkan/portability-initiative .
The advantage that opengl has is a number of software implementations that can be used as a last ditch on unsupported systems. Efforts for software vulkan implementations are taking a long time to appear.
To chime in: it's not, but a software renderer wouldn't have the desired performance when rendering at the typical resolutions we see today (ie. up to 4K) - or would require a lot of work to get there.
It would seem a bit counterproductive to me to use a software renderer when a graphics API will give you a ton of the desired functionality out of the box, and will have better performance characteristics.
That would only be counterproductive if you actually need that functionality. Very few software would actually need what Vulkan offers. I can only think of AAA games.
What are you talking about? Shader languages are DSLs for working with images. Implementing a software renderer would require re-implementing many, many things you get for free when working with GLSL or HLSL.
Vulkan is just an API for talking to graphics hardware. There are a wide variety of applications which can benefit from using it.
My objection is about Vulkan specifically, not about using the GPU. It makes this software less portable than if they had used OpenGL, and for no benefit that I can see.
I mean, your original comment specifically cited a software renderer, and your original objection was that vulkan was overkill, not that it wasn't well supported, so it seems like you're moving the goalposts all over the place but I'll bite.
As someone who does graphics programming, I would not choose OpenGL for new projects. For one thing it's the future: while I only expect Vulkan to become more well supported as time goes on, the opposite is happening with OpenGL (see the state of support on Apple platforms). Also the Vulkan API itself actually makes it easier to target more platforms. Because the OpenGL api takes on more responsibility over how the graphics pipeline is executed, there is actually a lot more variation in behavior across driver implementations than you have with Vulkan. This was one of the biggest headaches of OpenGL development which Vulkan has largely solved.
So if I had to choose between losing some users who are using old hardware verses the headaches of supporting an OpenGL application across platforms, along with the fact that OpenGL is actually getting less support over time, the choice would be easy for me.
It's a moot point anyway since the developer here is already using a high-level compatibility library.
rx uses wgpu-rs, which primarily supports Vulkan, Metal, and DX12 (though DX11 and GL backends are also partially supported). This is aready relatively portable compared to using GL directly, especially on macOS where it has been deprecated.
> Very few software would actually need what Vulkan offers. I can only think of AAA games.
In about 2005-2007, count of pixels in displays started to grow much faster than CPU power. FullHD monitors entered mainstream market. CPUs stagnated because laptops stopped being expensive toys and started to become desktop replacement.
Nowadays, with 4k or higher rez monitors even in some laptops, pretty much all software actually needs what Vulkan (or D3D, or GL) offers, just to update screen at 60 Hz.
I was specifically talking about Vulkan. You can use the GPU through higher level APIs like OpenGL or D3D11 just fine and those are supported on more hardware than Vulkan.
Only collectively so, when you have both GL and D3D11 backends.
OpenGL is not portable.
Technically it works on Windows, but that’s only true if you’re happy with 11 years old version of the standard, OpenGL 3.0: https://github.com/Const-me/GL3Windows#building-and-running GPUs have changed dramatically over these 11 years, i.e. that version is way too old.
Technically, OpenGL doesn’t work on majority of ARM devices. They use OpenGL ES, not quite the same thing.
Vulkan works on most of these, with the only exception of Windows devices who have Intel GPUs older than Skylake, i.e. older than 2015.
There are a ton of GPUs out there that don't support Vulkan but shouldn't have any trouble running an image editor. By using Vulkan when it doesn't provide much of a benefit for your use-case, you're just artificially limiting your audience.
This project is using wgpu-rs, which already exposes a API that's a bit easier to work with than Vulkan.
wgpu-rs has backends for Vulkan, Metal, DX12, DX11, and GL (partial). The primary backends are the lower-level graphics APIs that are in active development: Vulkan, Metal, and DX12.
It's like using PostgreSQL to save its config.
But I don't want to criticize that choice. It looks like the author wrote something that worked for them, and more software should be like that (as counter-intuitive as it sounds).
It's interesting to me that people think of Vulkan as a "heavy dependency", when it's actually the thinnest layer available between an application and the graphics card.
"Partially" is misleading, MoltenVK almost completely supports Vulkan.
At this point the only features not supported are quite minor things, like lack of custom allocator support, and not being able to query pipeline statistics. Geometry shaders are also excluded because they're not implemented in Metal, but they are considered optional in the Vulkan spec.
I think it's more the connotation that 'partial' has. In my head that means that there is still significant portions of features missing. Also given the context, partial implies that it is not useful for its intended purpose. I'd say it's not really synonymous for all intents and purposes.
Exactly. For all intents and purposes, you can now target Apple platforms with Vulkan using MoltenVK with a shared codebase. For most people, the fact that custom allocators are ignored would not constitute incomplete coverage of the Vulkan API.
For what it's worth, rx is already targeting multiple native graphics APIs (Vulkan/Metal/etc.) with a shared codebase through wgpu [0], so MoltenVK isn't necessary here anyway.
It might also be interesting to mention that wgpu is implemented with gfx-hal, which provides a common abstraction for native graphics APIs. But besides wgpu, gfx-hal is used in the implementation of gfx-portability [1], which is a MoltenVK alternative that runs on Metal, DX12, and DX11.
