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

51–60 of 68 posts

Re: Bringing Vulkan everywhere

#51

Post by microcolonel »

pcwalton wrote: post #40
snaky wrote: post #39

Earlier quoted context omitted.

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-specifi…

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

Beyond that, even where performance is the priority, a generic performance win is usually more interesting unless the IHV is buying the developer time.

Re: Bringing Vulkan everywhere

#53

Post by johncolanduoni »

microcolonel wrote: post #50
muizelaar wrote: post #48

Earlier quoted context omitted.

5th generation Intel chips support Direct3D12 and not Vulkan. https://www.intel.com/content/www/us/en/support/articles/000...

If I'm not mistaken, Mesa/ANV supports Vulkan back to Haswell (with some limitations until Broadwell).

Not on Windows unfortunately :/

Re: Bringing Vulkan everywhere

#54

Post by johncolanduoni »

maccam94 wrote: post #10
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.

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

Older Intel chips (pre-Skylake IIRC) don’t have Vulkan support on Windows, even though they do on Linux.

Re: Bringing Vulkan everywhere

#55

Post by pjmlp »

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.

Microsoft has decided to approach the problem by other means, meaning the introduction of MSIX containers for Win32, and merging both worlds.

The next Office for Windows 10 being store only is already an indication how things will go from now on.

Re: Bringing Vulkan everywhere

#56

Post by pjmlp »

pcwalton wrote: post #41
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.

Note that Apple is still committed to supporting WebGL in Safari, so OpenGL ES will at least be supported that way going forward. So it's arguably not so much "OpenGL is going away" as it is "OpenGL is going to be maintained by the Safari team, and JS will be the only interface to it" :)

WebGL does not require OpenGL implementation.

Most browsers on Windows use DirectX instead and the games consoles also only have their own 3D APIs.

Re: Bringing Vulkan everywhere

#57

Post by pcwalton »

pjmlp wrote: post #56
pcwalton wrote: post #41

Earlier quoted context omitted.

Note that Apple is still committed to supporting WebGL in Safari, so OpenGL ES will at least be supported that way going forward. So it's arguably not so much "OpenGL is going away" as it is "OpenGL is going to be maintained by the Safari team, and JS will be the only interface to it" :)

WebGL does not require OpenGL implementation. Most browsers on Windows use DirectX instead and the games consoles also only have their own 3D APIs.

WebGL is an OpenGL implementation. On Windows, it's often implemented with ANGLE, also an OpenGL implementation.

The GL spec doesn't require that the hardware or OS manufacturers are the ones to implement it. :)

Re: Bringing Vulkan everywhere

#58

Post by shmerl »

microcolonel wrote: post #50
muizelaar wrote: post #48

Earlier quoted context omitted.

5th generation Intel chips support Direct3D12 and not Vulkan. https://www.intel.com/content/www/us/en/support/articles/000...

If I'm not mistaken, Mesa/ANV supports Vulkan back to Haswell (with some limitations until Broadwell).

Up until Ivy Bridge with more limitations.

Re: Bringing Vulkan everywhere

#59

Post by shmerl »

muizelaar wrote: post #48
zanny wrote: post #42

Earlier quoted context omitted.

Is there any hardware that supports only DX12 and not Vulkan? My understanding is the only extant device is the Xbox One, which doesn't support Vulkan not because the hardware lacks the ability or drivers (since its an AMD SoC shared with the PS4 and using GCN 3 tech) but because of politics trying to lock developers into their API over the industry standard. Trying to fight politics with software rarely ends well, e…

5th generation Intel chips support Direct3D12 and not Vulkan. https://www.intel.com/content/www/us/en/support/articles/000...

They support it fine on Linux.

Re: Bringing Vulkan everywhere

#60

Post by pjmlp »

pcwalton wrote: post #40
snaky wrote: post #39

Earlier quoted context omitted.

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-specifi…

It is not going wild with extensions, rather having to deal with extensions for feature X, because everyone does it differently, and when X becomes part of the core, it is just another additional path, as naturally not all GPU drivers do update to the version that has X in the core.

And even then, there are the workarounds to deal with hardware or driver specific bugs.

Post reply on HN