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

11–20 of 45 posts

Re: Vulkan 1.2

#11

Post by st_goliath »

boutad wrote: post #5

Does Vulkan have an answer to DirectX Raytracing?

As flohofwoe has pointed out, yes this can currently be done using Nvidia specific extensions.

If you are interested, a friend of mine and a few coworkers pieced together a small proof-of-concept game engine in their spare time that uses Vulkan ray tracing on Nvidia RTX cards. They finally released it on GitHub a few days ago:

https://github.com/W4RH4WK/Raygun

I also submitted it on HN, but with little interest so far: https://news.ycombinator.com/item?id=22037474

Re: Vulkan 1.2

#12

Post by pjmlp »

boyadjian wrote: post #8

Im am eager to have a usable implementation of OpenGL over Vulkan, like Zink. At last, no more different implementations of OpenGL from one vendor to another.

You just get different implementations of Vulkan from one vendor to another plus the OpenGL middleware on top instead.

Re: Vulkan 1.2

#13

Post by FpUser »

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.

LOL. It is not the nextgen version of GL. It is a tool that would let you make your own OpenGL. It is way too low level and takes insane amount of work comparatively to OpenGL/DirectX. Sure big engine developers would love it. Smaller guys like myself: not so much.

Re: Vulkan 1.2

#14

Post by pjmlp »

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 engine and just check the respective box of the desired graphics API backend.

Re: Vulkan 1.2

#15

Post by [deleted] »

boyadjian wrote: post #8

Im am eager to have a usable implementation of OpenGL over Vulkan, like Zink. At last, no more different implementations of OpenGL from one vendor to another.

[deleted]

Re: Vulkan 1.2

#16

Post by pingyong »

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…

Hmm. I've only really played around with both (OpenGL 4.x and Vulkan), but while Vulkan had an insane amount of boilerplate initially, it was really intuitive to me. The situation of "what do I even have to google here?" never came up, while that happened a lot with OpenGL. If you already have a working code base obviously that doesn't really matter, but if I was writing a new engine today, I'd probably use Vulkan just because the API seems so much more intuitive to me. (Well, Vulkan or D3D11.)

Re: Vulkan 1.2

#17

Post by skocznymroczny »

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…

I'm considering switching away from OpenGL just to get rid of the global state. It's too tiring to track the OpenGL state just to realize you forgot to unset some texture in a completely different part of code.

My favourite of the newest APIs is Metal, because it's very easy to jump from OpenGL (triangle in Metal is about 30 lines of code). Perhaps WebGPU is an alternative once desktop translation layer is created (Google is working on one called Dawn).

Re: Vulkan 1.2

#18

Post by usrusr »

pjmlp wrote: post #12
boyadjian wrote: post #8

Im am eager to have a usable implementation of OpenGL over Vulkan, like Zink. At last, no more different implementations of OpenGL from one vendor to another.

You just get different implementations of Vulkan from one vendor to another plus the OpenGL middleware on top instead.

Sure, but the vendor specific black box is getting much smaller. The idea is that it's better to have client and/or middleware code paths battle actual hardware differences than having them battle actual hardware differences and different sets of smoke and mirrors.

Re: Vulkan 1.2

#19

Post by skocznymroczny »

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…

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 offer a low-level but userfriendly API and can compile to several different graphics API backends.

Re: Vulkan 1.2

#20

Post by badsectoracula »

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 worked on the implementation side has told me that it wasn't that great), but i find the API way too ugly and verbose for my taste.

I have considered writing a small OpenGL-like wrapper on top of it since i am concerned that OpenGL quality will deteriorate in the future (though that would break a TON of games, including the ultrapopular Minecraft), but for now things work fine.

[0] https://i.imgur.com/rd8Xk84.gif

Post reply on HN