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

Vulkan 1.2

khronos.org

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Vulkan 1.2

#21

Post by HelloNurse »

pjmlp wrote: post #14
roenxi wrote: post #2

In case anyone isn't keeping up this is basically the next generation of OpenGl, but they've made enough changes to justify a new name. Good idea too. Make it clear that they are doing things differently.

It is not a next generation OpenGL, unless one wants to become an expert in driver and compiler development on top of mastering graphics programming. Currently Khronos answer for those that don't want to become such experts it to stick with OpenGL, the problem is that is isn't gettting much updates beyond 4.6, and Vulkan is not getting a more developer friendly API. Most devs will be better by choosing a middleware e…

The theory was that OpenGL or any other API of that kind is reasonably easy to implement on top of Vulkan, providing very long term support and compatibility for OpenGL-based applications.

In practice, like 15 years ago, you can use Mesa3D which remains as comprehensive and unexciting as ever with constantly improving performance thanks to using Vulkan.

In the more mainstream part of practice, rendering engines get rid of OpenGL to use Vulkan because it's usually better.

Re: Vulkan 1.2

#22

Post by davemp »

I really like how vulkan tries to model modern hardware--reminiscent of C. I spent a few weekends writing a toy renderer with it and learned quite a bit about the modern graphics pipeline.

Writing vulkan for a quick hobby project is probably a bit much, but it seemed like a great choice where extra control is needed. Hopefully more libraries will mature take care of the dirty work (thousands of lines of initialization).

Re: Vulkan 1.2

#23

Post by thrower123 »

flohofwoe wrote: post #7
boutad wrote: post #5

Does Vulkan have an answer to DirectX Raytracing?

NVIDIA offers a vendor-specific extension: https://www.khronos.org/registry/vulkan/specs/1.2-extensions... I guess this will first be elevated to a vendor-neutral extension and (I guess) eventually will move into the core API.

One would have thought that they might have learned from what happened with OpenGL that this is a clusterfuck and leads to fragmentation...

Re: Vulkan 1.2

#24

Post by pjmlp »

skocznymroczny wrote: post #19
pjmlp wrote: post #14

Earlier quoted context omitted.

It is not a next generation OpenGL, unless one wants to become an expert in driver and compiler development on top of mastering graphics programming. Currently Khronos answer for those that don't want to become such experts it to stick with OpenGL, the problem is that is isn't gettting much updates beyond 4.6, and Vulkan is not getting a more developer friendly API. Most devs will be better by choosing a middleware e…

I think expert in driver and compiler development is too much. It takes a lot more to get started, because it doesn't assume any defaults, but then it isn't too hard as long as you venture into topics like multithreading, but then in OpenGL you never went into multithreading in the first place. I think the best middleground between OpenGL and middleware engines are translation layers such as gfx-rs and bgfx, which of…

Experience has proven that if you aren't really deep into Vulkan, the end result will be worse than just doing it in OpenGL, in terms of performance.

Re: Vulkan 1.2

#25

Post by thrower123 »

boutad wrote: post #5

Does Vulkan have an answer to DirectX Raytracing?

There are days when I wish that DirectX was the open standard, rather than the other way around. It's such a cleaner, better designed API - quite possibly because it was not open, and so it doesn't have anywhere near as much of the design-by-committeeisms that infect OpenGL/Vulkan.

Re: Vulkan 1.2

#26

Post by pjmlp »

badsectoracula wrote: post #20
bullen wrote: post #9

I'm sticking with OpenGL (ES) 3 that brought VAO for life. The returns will diminish to the point that porting or developing on new APIs does not pay for itself. I know both Jonathan Blow and Godot are clear signs that I'm wrong, but I guess we'll just have to wait and see. Until then I have my engine running on Win/x86 and the Pi 4 at good performance with minimal effort. Which is good; simple software will live for…

Similar here, except i'm sticking with OpenGL 1.x (or 2.x for when i want shaders... or 3.x/4.x for when i want MORE shaders :-P), exactly because of the sheer simplicity of the API. I have written a bit of Vulkan code (i wrote this[0] the day the spec came out, after banging on it for several hours - and i found the spec quite readable, at least from the side of someone who wants to use it... someone i know who work…

Somehow ARB, and now Khronos keep forgetting that having something like MetalKit or DirectXTK as part of the specification really matters to onboard newbies.

OpenInventor could have been it, but SGI had other plans for it, and no one at either ARB or Khronos actually cared about it.

Re: Vulkan 1.2

#27

Post by pjmlp »

thrower123 wrote: post #23
flohofwoe wrote: post #7

Earlier quoted context omitted.

NVIDIA offers a vendor-specific extension: https://www.khronos.org/registry/vulkan/specs/1.2-extensions... I guess this will first be elevated to a vendor-neutral extension and (I guess) eventually will move into the core API.

One would have thought that they might have learned from what happened with OpenGL that this is a clusterfuck and leads to fragmentation...

Nah, https://vulkan.gpuinfo.org/listextensions.php

Re: Vulkan 1.2

#28

Post by plopz »

Is Vulkan the response to the fact that single cores aren't getting faster and games need to move towards multithreading? Is there an analogous solution for other systems like physics, collisions or pathfinding?

Re: Vulkan 1.2

#29

Post by flohofwoe »

plopz wrote: post #28

Is Vulkan the response to the fact that single cores aren't getting faster and games need to move towards multithreading? Is there an analogous solution for other systems like physics, collisions or pathfinding?

The TL;DR reason for those new 3D APIs is essentially to drastically reduce CPU work that needs to happen in the graphics driver layer in the "old" 3D APIs (but that also means that if your application isn't spending a lot of CPU time in the graphics driver, for instance because it is fillrate bound, then that application won't benefit much from moving to the new APIs).

OpenGL's original design was a "fine grained state machine" which doesn't map well to modern GPU architectures, and every time a "micro state" in that big state machine is changed the GL driver needs to translate that change into much coarser state that GPUs accept. But it turns out that many 3D application don't even need to change unique states one by one, so each frame your code translates mostly static and coarse "application rendering state" into GL's fine grained state, only to have the GL driver translate that fine grained state back into coarse GPU state.

That's just one piece of the puzzle but I think explains the motivation behind the modern 3D APIs best.

The "other" 3D-API, Direct3D already took steps to group fine grained state into coarser state (starting with D3D10 and D3D11), the problem there was that they didn't come up with a good solution for threaded rendering (generating rendering work on different CPU threads), that's the other big thing that the modern 3D APIs solve properly. You essentially build render command lists on multiple CPU threads, and then enqueue those command lists on the main thread to be processed by the GPU.

Re: Vulkan 1.2

#30

Post by [deleted] »

plopz wrote: post #28

Is Vulkan the response to the fact that single cores aren't getting faster and games need to move towards multithreading? Is there an analogous solution for other systems like physics, collisions or pathfinding?

[deleted]
Post reply on HN