Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing Vulkan everywhere

gfx-rs.github.io

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Bringing Vulkan everywhere

#61

Post by VSTN »

berkut wrote: post #37
electricslpnsld wrote: post #34

Earlier quoted context omitted.

> It's definitely a reason we're not jumping on the new low level APIs in the VFX industry currently. While the big studios on Linux (people like Pixar) probably don't care about the lower level APIs, the major vendors like Autodesk and SideFX are going to have to if they still want to target macOS.

Possibly, but I bet they'll hold out on OpenGL for ages, and I wouldn't be surprised if push comes to shove that macOS gets dropped for VFX in the future - as a developer who used to work at The Foundry years ago, it causes so much trouble to develop for compared to Linux, and in relation to the number of people who used it I'm not sure it's worth it any more... Quite a few individuals are still using it, but there's…

Some companies have already dropped future support of the mac version of their software based on Apple making it official that OpenGL is truly dead.

https://apple.slashdot.org/story/18/07/29/1939212/autodesk-d...

"According to a note posted on Autodesk's support website, while older Alias versions can run on High Sierra or earlier, "no versions of VRED will run on that operating system due to the OpenGL deprecation."

While openGL is not going to stop working on Mojave, it has served as a good excuse for autodesk to stop bothering with the work of developing mac versions and refusing to provide any support or patching of any future issue that might arise on current releases being run on mojave.

Apple is working very hard at killing the mac both because of what they've done to the hardware and what they're doing to their OS for any user that's not some grandma that does nothing outside browsing facebook on a $1500 macbook..

Re: Bringing Vulkan everywhere

#62

Post by kvark »

wlesieutre wrote: post #15
baobrien wrote: post #9

Earlier quoted context omitted.

I think -- and I could be wrong here -- that gfx-rs aims to eventually implement Vulkan on D3D12 in addition to Metal, while MoltenVK only aims to work on Metal.

I don't know about the MoltenVK branding specifically, but Khronos does plan a "Universally portable subset" of Vulkan with tools to target both Metal and D3D12 from one rendering codebase and common SPIR-V shaders. The project is call Vulkan Portability Initiative : https://www.khronos.org/blog/khronos-announces-the-vulkan-po...

Both gfx-rs and MoltenVK are in that technical subgroup within Khronos.

Re: Bringing Vulkan everywhere

#63

Post by kvark »

electricslpnsld wrote: post #6
nemaar wrote: post #4

Earlier quoted context omitted.

I believe you can use this without touching Rust. If I remember correctly they even ran Dota2 with this. That certainly does not have Rust inside.

Interesting, thanks for the clarification! Any idea as to the advantages of using these bindings vs. the Molten bindings, if one isn't using Rust?

gfx-rs Metal backend can be powerful and faster

Re: Bringing Vulkan everywhere

#65

Post by shmerl »

kvark wrote: post #64
shmerl wrote: post #17

So gfx-rs will expose Vulkan frontend? Is there a plan to support GNM backend in gfx-rs?

gfx-rs does expose Vulkan frontent: https://github.com/gfx-rs/portability I'd love to get started on GNM but licensing is tricky, given that gfx-rs is a community project.

You mean getting Sony's SDK is a problem? May be you can partner with some developers who already have access to it?

Re: Bringing Vulkan everywhere

#66

Post by oliwarner »

snaky wrote: post #39
oliwarner wrote: post #35

Earlier quoted context omitted.

The extensions are just that. They are essentially proposals or hardware specific items not meant for broad adoption. Those that are get drafted into the proper specs. And variable driver support is common across all big graphics APIs. If anything, the feature per driver coverage here is better than DX12.

And hardware vendors are and will be very eager to add hardware specific quirks, tons of it. So there is no point to "abstract graphics API for any OS/CPU instruction set" then, when most of the work - and we are talking about graphics acceleration, where performance is everything - is and increasingly will be handling all of that quirks.

Meanwhile, vendors work hand-in-hand with sponsored developers to patch their in-driver Direct3D implementation flaws up for specific games before release.

There's always going to be nonsense like this but —so far— there has been very little in Vulkan. Everybody is working towards a shared good, pushing the idea that a common framework that works the same is just less work for everyone.

Raytracing is going to test that because we already have fundamental differences in approach (Nv has a published extension, AMD are pushing a userspace compute library). It'll be interesting to see what emerges at the end.

Re: Bringing Vulkan everywhere

#67

Post by sounds »

berkut wrote: post #29
Lio wrote: post #2

Hopefully this will offer some way forward for FOSS software like Blender running on macOS when Apple kill OpenGL off.

Application software doesn't necessarily want to be using low-level stuff like Vulkan just yet: the reason being is that these low-level APIs with more direct access/control to the hardware don't (currently) provide load-balancing between multiple applications, which all OpenGL implementations (via the drivers) do currently do fairly well. i.e. so you can have two differential applications open which both fairly heav…

Just to offer a counterpoint (and I'm happy to discuss), Vulkan has much better load-balancing and resource-sharing potential than OpenGL.

Resource Sharing:

--------------------

Vulkan requires the application provide verbose information about the features being used. Vulkan also reports the number and types of heaps, their sizes, and detailed information on the max number of each type of resource the application can allocate.

OpenGL allows the application to just "go for it," allocate resources without bound [1], and the driver will attempt to "make it work." The only way the application knows it has reached a limit is when the driver finally fails with GL_OUT_OF_MEMORY.

When the driver and OS need to move resources around, such as if the GPU's memory is exhausted, Vulkan applications are much easier to manage. A Vulkan application's memory will be clearly structured so that the driver can identify little-used resources and relocate them so that the next application can get the resources it needs.

Load Balancing:

-------------------

Vulkan requires the application to be much more explicit about which queues and devices the application will be using, and even what priority the application places on different loads.

OpenGL again has no such concept. An application can only access OpenGL from a single thread, and OpenGL just lets the application "go for it."

When the driver and OS need to load balance, a Vulkan application is much easier to load balance. Any rendering or compute in Vulkan is explicitly defined with clear fences, transitions and barriers. The OpenGL application's only mode of operation is "why didn't this run faster?" The GPU vendor's OpenGL driver contains hundreds of application-specific tweaks to the OpenGL API to try to accomodate one particular application. The GPU vendor's Vulkan driver has not been around long enough to accumulate much of that bitrot.

In summary, neither API explicitly triggers load-shedding behavior in the application. The Android app lifecycle is a completely different story.

On desktop machines, Vulkan and OpenGL applications are designed with very few constraints. They mostly are expected to be the main or only application running, and expect to run on machines with medium or high-end specs. The OS and driver manage load-sharing and resource-sharing silently behind the scenes. With Vulkan, however, the OS and driver have a much easier time for the reasons discussed above.

I recommend Vulkan strongly for all new development.

[1] https://stackoverflow.com/questions/6354208/glgentextures-is...

Re: Bringing Vulkan everywhere

#68

Post by kvark »

shmerl wrote: post #65
kvark wrote: post #64

Earlier quoted context omitted.

gfx-rs does expose Vulkan frontent: https://github.com/gfx-rs/portability I'd love to get started on GNM but licensing is tricky, given that gfx-rs is a community project.

You mean getting Sony's SDK is a problem? May be you can partner with some developers who already have access to it?

I think the time will come for it when we prove ourselves useful on Metal/D3D12 and get those developer partnerships in the first place.
Post reply on HN