The Still Very Early State Of Vulkan For Blender - No Active Developers Working On It

[stormcrow]

Because they would be missing out on Xbox & PlayStation, that's why.

Also, most PC DirectX 12 API renderers tend to be straight ports from the Xbox Series version, therefore it doesn't make sense from a financial perspective to further invest into a Vulkan version, unfortunately.

Also because while there is a Vulkan stack for MacOS, it's not supported by Apple and probably never will be. It will be subject to breakage in any given platform update. Games for iOS uses the native Metal implementations supported by Apple. No, mobile game makers are not going to ignore iOS. There's too much potential money in that market.

This "code once run everywhere" is just marketing BS and needs to stop. There are platforms that do reasonably well with cross platform portability (RenPy/Python comes to mind), but I can't think of one that doesn't have quirks you have to work around if you want to move to an underlying platform alien to your original target when you have to interact with the underlying OS - and nearly every complex program has to at some point.

[tildearrow]

Yeah. Most games I tried on Linux run worse in the native Linux version and are running far better via Proton. Everspace for example. Or pretty much any Unity based game.

Pianofall (or any game built with latest Unity) can't even take unfocus via Wine - it stops accepting all mouse input events and sometimes even stops rendering.

[smitty3268]

Question: Why would game developers stick with DirectX when they could simply target Vulkan and hit all platforms at once, with native performance?

Because most game devs only care about Windows and consoles, and DX is the path of least resistance there.

You're making the classic mistake of assuming others (game devs in this case) value the same things you do. They don't care about hitting other platforms, and will figure Valve can deal with that for them if they ever do.

[stormcrow]

Because most game devs only care about Windows and consoles, and DX is the path of least resistance there.

You're making the classic mistake of assuming others (game devs in this case) value the same things you do. They don't care about hitting other platforms, and will figure Valve can deal with that for them if they ever do.

To give your counter more support: Arguably many don't even care about Windows. It's often an afterthought and many ports are pretty awful because they don't take the time to recreate a proper UX for the completely different control styles on a PC. Just because it will run, doesn't mean it runs well or that it's playable. There are definitely exceptions, and I have a few in my game library both in Windows and Linux. I'm grateful to the companies and dev teams that do wish to target Linux (thank you X4 devs if you're reading this!). But, I don't for one instant think just because Vulkan is out there and available there isn't a significant cost in targeting it opposed to the native targets of the real money makers on the non-mobile platforms: DirectX/PlayStation.

[vegabook]

Vulkan is a very big, very expensive distraction for projects. Yes it has it's benefits, but the cost of rewriting the entire graphics engine is enough to actually kill a lot of projects that would be better off investing the time in features/supporting issues users are already dealing with. Even for VR support Vulkan is often unnecessary and used more as an excuse not to implement VR support e.g: "We'll get around to VR once the Vulkan rewrite is done", 10 years later... no Vulkan rewrite and no VR support, users lose interest and the project momentum dies.

Wrong. Parallel compute occupies the larger part of the transistor budget. And the reason is that multitudinous modern workloads need it. This architecture is at least 40 years newer than the turing machine, and so easy abstractions are still a long way out. But the architecture is now ubiquitous in every modern computer, including your phone. Any systems programmer or application that uses compute needs to understand this, as anyone all those years ago would have needed a fundamental understanding of (their flavour of von neumann-style) assembler language. Trying to pretend a low-level architecture is somehow too difficult is a web-dev mentality, spoiled by abstractions. These transistors will not remain dead. Those who cannot light them up or refuse to do so efficiently, are doomed to be surpassed by those who can. If you're going to wait around for comfy abstractions, you're going to be last to the party.

[stormcrow]

Wrong. Parallel compute occupies the larger part of the transistor budget. And the reason is that multitudinous modern workloads need it. This architecture is at least 40 years newer than the turing machine, and so easy abstractions are still a long way out. But the architecture is now ubiquitous in every modern computer, including your phone. Any systems programmer or application that uses compute needs to understand this, as anyone all those years ago would have needed a fundamental understanding of (their flavour of von neumann-style) assembler language. Trying to pretend a low-level architecture is somehow too difficult is a web-dev mentality, spoiled by abstractions. These transistors will not remain dead. Those who cannot light them up or refuse to do so efficiently, are doomed to be surpassed by those who can. If you're going to wait around for comfy abstractions, you're going to be last to the party.

I'd argue that blindly reaching for Turing completeness for the past 50 years without regard for all of its implications is what got us into the security situation we find ourselves in the present. It's mathematically impossible to secure a Turing Machine and its equivalents from all possible "weird states" since by definition a Turing complete system can encompass all possible states and input (practically an infinite number while the number of weird states would be an undefined subset of that infinite set) regardless of the desirability of any given state. Blindly following the same path with heterogeneous computing will land us exactly in the same boat we are now, just making the tripwire of weirdness just that much larger. Just because we can do a thing, doesn't necessarily follow that should or must do that thing. Unfortunately, our geek natures have a tendency to embrace new and shiny before we figure out how to secure new and shiny against the inevitable deliberate attacks or (un?)intended consequences (like the widely deployed algorithmic gateways that have proven severely biased towards or against certain points of view).

Edit to add: It's also painfully clear that pushing off fixing problems identified today just to push a product out the door means those problems never get fixed. Instead they ossify. Just look at the massive amounts of effort that goes into fixing the C language's (and programmer) inadequacies (you need look no further than OpenBSD or HardenedBSD). The lifetime of the Unix paradigm which people still religiously cling to as if it were a gift from a god as the End All and Be All of software development (any given BSD or Linux discussion). Microsoft's Windows still has APIs that were bad when they were first introduced and have proven impossible to fix thanks to 25 years of cruft (Print Nightmare among others).

[ET3D]

Please keep in mind that you need to write 10 times more lines of code than OpenGL to display a triangle on the screen.

It's also worth keeping in mind that there are multiple libraries for making Vulkan easier to use.

Thing is, it doesn't matter how hard or easy Vulkan is if no one is working on it. My guess is that once work starts it will be possible to see results in a few months.

[kpedersen]

Well. You need to do it even without Vulkan. Apple deprecated OpenGL long time ago and it breaks every other version.

Do you know what Apple's Vulkan support is like? Certainly not any better. And adding an entire API support (Metal) just for one platform is a very old fashioned thing to do these days. Apple should get out of the 90s and interoperate with the rest of the industry.

Luckily OpenGL is going back to its "specification, not a library" roots and can easily wrap around other APIs. Vulkan, due to its very low level (and sprawling) nature, not so much.

[undefined]

What would having Vulkan instead of OpenGL give Blender? Would it mean new features? Or does it only mean viewport FPS increase? Do people really have issues because of viewport FPS?

I am just not sure what are the immediate benefits of Vulkan. Eventually, sure, they probably want it because OpenGL is outdated. But I wonder why would people want it faster.

[piotrj3]

What would having Vulkan instead of OpenGL give Blender? Would it mean new features? Or does it only mean viewport FPS increase? Do people really have issues because of viewport FPS?

I am just not sure what are the immediate benefits of Vulkan. Eventually, sure, they probably want it because OpenGL is outdated. But I wonder why would people want it faster.

??? It is huge. Blender on nvidia cards with optix does real time in viewport rendering allowing you to have quite accurate representation real time of how object will look on final render. Vulkan exposes raytracing extensions allowing you to have such goods being agnostic GPU company. Also in case of rendering it opens you option to use vulkan as compute for rendering as faster alternative to opencl (thanks to indirect dispatching, many queues). It basicly is a way to introduce blender to platforms without HIP/oneapi/cuda support. The only reason why Vulkan isn't that prioritized is because every company (nvidia, AMD, intel) provided programmers to work on backend for their own technology.