Live data from Hacker News

Bringing Vulkan everywhere

gfx-rs.github.io

21–30 of 68 posts

Re: Bringing Vulkan everywhere

#21

Earlier quoted context omitted.

Is Apple “killing off” OpenGL? Isn’t it just deprecated ie not further development but not removed?

Given that it was already on a very old version, not doing further development counts as "killing it off" in my book. I'm bummed because I did an OpenGL based text renderer in xi-editor, and now have to decide whether to go back to CoreGraphics (assuming they've fixed the performance problems there) or forward with something like this.

I'd recommend something like this. We plan on switching to it for WebRender in the future.

Re: Bringing Vulkan everywhere

#22
post #14

Earlier quoted context omitted.

Are there any D3D12 platforms that don't also support Vulkan?

Windows, partially. Vulkan can be used in classic win32 apps but not in "modern" UWP apps. The Xbox One uses a variant of D3D12 and doesn't support Vulkan at all.

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

Re: Bringing Vulkan everywhere

#23

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…

> 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 extension soup, and you still have to deal with all the platform nastiness of everything else besides sending triangles to the GPU.

Re: Bringing Vulkan everywhere

#24
post #2

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

Is Apple “killing off” OpenGL? Isn’t it just deprecated ie not further development but not removed?

Usually Apple removes deprecated stuff after 5 years.

Re: Bringing Vulkan everywhere

#25

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…

> 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

Re: Bringing Vulkan everywhere

#26
post #22
post #14

Earlier quoted context omitted.

Windows, partially. Vulkan can be used in classic win32 apps but not in "modern" UWP apps. The Xbox One uses a variant of D3D12 and doesn't support Vulkan at all.

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

Re: Bringing Vulkan everywhere

#27
post #26
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.

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

Re: Bringing Vulkan everywhere

#28
post #27
post #26

Earlier quoted context omitted.

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

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.

Re: Bringing Vulkan everywhere

#29
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 heavily utilise the graphics card (for drawing, not compute), and both get a fair share (depending on which has focus in some cases depending on driver settings) of the GPU.

For desktop applications where you're multi-tasking with potentially multiple applications using the graphics card this is often quite important.

For games it's obviously less so.

It's definitely a reason we're not jumping on the new low level APIs in the VFX industry currently.

Re: Bringing Vulkan everywhere

#30

Earlier quoted context omitted.

Is Apple “killing off” OpenGL? Isn’t it just deprecated ie not further development but not removed?

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.
Post reply on HN