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

31–40 of 68 posts

Re: Bringing Vulkan everywhere

#31

Post by shmerl »

protoster wrote: post #20

Correct me if I'm wrong: 1) this is an effort to provide an abstract graphics API for any OS/CPU instruction set 2) it is rust and therefore usable from rust and C(++). If so, great news! Maybe we'll one day be free from tyranny of Windows when it comes to gaming. In my ideal world, operating systems should be interchangeable like web browsers and competing to provide the best implementation of an open standard rathe…

> it is rust and therefore usable from rust and C(++).

They want to provide C bindings (vulkan.h).

> Have there been any previous attempts to do this? Any success?

MoltenVK translates Vulkan into Metal. Looks like gfx-rs has a potential to break these lock-ins one step further with translating Vulkan into DirectX 12. They should also consider making GNM backend for completeness.

Re: Bringing Vulkan everywhere

#32

Post by shmerl »

jsheard wrote: post #26
drb91 wrote: post #22

Earlier quoted context omitted.

> Vulkan can be used in classic win32 apps but not in "modern" UWP apps. Why is this/how do they enforce that? The Xbox is hardly a surprise, but then again you're only going to target that for games so it's less of a problem.

> Why is this/how do they enforce that? Technically Windows doesn't support Vulkan at all, but the openness of the win32 platform allowed Khronos to define a "backdoor" interface where the application ignores the Windows graphics stack and instead gets a Vulkan context by talking to the graphics driver directly. The UWP sandbox makes this impossible so you're stuck with the native Direct3D APIs.

I don't think UWP with Vulkan is completely impossible.

https://github.com/KhronosGroup/Vulkan-Docs/issues/366

It doesn't exist now though for sure, so for all practical purposes UWP locks developers out of using Vulkan.

Re: Bringing Vulkan everywhere

#33

Post by tomovo »

bodas wrote: post #30
statusreport wrote: post #11

Earlier quoted context omitted.

In this year’s WWDC I asked the same question one of the GPU software engineers and he claimed that Apple is going to completely remove support for OpenGL in about two years from now. Regardless, “deprecated” means “no longer maintained”, meaning that if any regressions will appear in the near future, it’s possible no one will fix them, as these issues will not be prioritized.

I'd take that with a grain of salt. Apple likes to threaten removal of technologies they have deprecated as a way to increase adoption of their replacements but rarely if ever go from deprecation to removal so aggressively, at least on the Mac.

They might exclude deprecated APIs from the pre-announced iOS-MacOS portable platform (Marzipan). That is the move that makes them unsuitable for future use.

This also includes UIWebView and other quite popular pieces of the SDK.

A clean cut - good opportunity to shed some weight, actually.

Re: Bringing Vulkan everywhere

#34

Post by electricslpnsld »

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…

> 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.

Re: Bringing Vulkan everywhere

#35

Post by oliwarner »

pjmlp wrote: post #25
megaman22 wrote: post #23

Earlier quoted context omitted.

> Have there been any previous attempts to do this? Any success? Many over the years, and largely not. Unreal and Unity are probably the closest to successful to date, but they are full-blown game engines, at a higher level of abstraction, rather than just graphics APIs. OpenGl mostly failed as a multi-platform solution, because vendors provide varying levels of compatibility in their drivers, not to mention unholy e…

Vulkan is not any better on this regard. Get ready to play extension and version golf. http://www.vulkan.gpuinfo.org/listextensions.php http://www.vulkan.gpuinfo.org/vulkansupport.php

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.

Re: Bringing Vulkan everywhere

#36

Post by malkia »

bodas wrote: post #30
statusreport wrote: post #11

Earlier quoted context omitted.

In this year’s WWDC I asked the same question one of the GPU software engineers and he claimed that Apple is going to completely remove support for OpenGL in about two years from now. Regardless, “deprecated” means “no longer maintained”, meaning that if any regressions will appear in the near future, it’s possible no one will fix them, as these issues will not be prioritized.

I'd take that with a grain of salt. Apple likes to threaten removal of technologies they have deprecated as a way to increase adoption of their replacements but rarely if ever go from deprecation to removal so aggressively, at least on the Mac.

https://knowledge.autodesk.com/support/alias-products/troubl...

Re: Bringing Vulkan everywhere

#37

Post by berkut »

electricslpnsld wrote: post #34
berkut wrote: post #29

Earlier quoted context omitted.

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…

> 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 been quite an uptick in Linux users in that area, at least where the software allows...

Re: Bringing Vulkan everywhere

#38

Post by imtringued »

megaman22 wrote: post #28
drb91 wrote: post #27

Earlier quoted context omitted.

Ahh, I had no idea UWP implied running on microsoft's terms. Is there a way to run them out of the sandbox manually?

Statistically, nobody actually builds real UWP apps, so it is largely an academic point. But if you're out of the sandbox, I fail to see a good reason not to just build a regular old Win32 app the way it has always been done.

If you are on Windows on ARM then there is no option other than UWP apps. Why would anyone buy an ARM laptop if they have to rely on emulation for everything anyway. It's not like the ARM laptops are any cheaper than the intel ones. (they actually have worse specs and cost more)

Re: Bringing Vulkan everywhere

#39

Post by snaky »

oliwarner wrote: post #35
pjmlp wrote: post #25

Earlier quoted context omitted.

Vulkan is not any better on this regard. Get ready to play extension and version golf. http://www.vulkan.gpuinfo.org/listextensions.php http://www.vulkan.gpuinfo.org/vulkansupport.php

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.

Re: Bringing Vulkan everywhere

#40

Post by pcwalton »

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.

That's not how it works. Most games and apps are just fine with leaving some amount of graphics performance on the table. That's why engines like Unity are so popular: sure, you could always go a bit faster writing your own engine, but in most cases it isn't worth the trouble. Likewise, with graphics APIs, you have to weigh the significant benefits of greater compatibility against the benefits of using vendor-specific extensions. For most apps, the benefits of going wild with extensions are marginal, while the obvious drawbacks are significant.

I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps.

Post reply on HN