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

41–45 of 45 posts

Re: Vulkan 1.2

#41

Post by slavik81 »

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?

That's part of it, but there's other reasons too. Promit[1] had a nice post that described four goals of the new generation of APIs: improving validation, reducing the complexity of the driver, allowing useful multi-threading, and giving developers more control over how the available hardware is used (e.g. multi-GPU). It's not an exhaustive list, but he filled in some of the backstory quite well.

[1] https://www.gamedev.net/forums/topic/666419-what-are-your-op...

Re: Vulkan 1.2

#42

Post by skocznymroczny »

earenndil wrote: post #37
skocznymroczny wrote: post #17

Earlier quoted context omitted.

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 (G…

TBH, opengl has been improving in that respect. See, e.g., glTextureSubImage2D[1], which takes a pointer to the referred texture, unlike glTexSubImage2D. 1: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl...

Yes, I am aware of the direct state access extensions. It was a good step forward, but a bit too late. And it still applies only to GL objects like buffers, samplers, textures. For things like setting scissor test, blending, depth test/write, color masks, binding textures, you're back to the global state.

Re: Vulkan 1.2

#43

Post by pjmlp »

amaranth wrote: post #34
flohofwoe wrote: post #6

Earlier quoted context omitted.

Unfortunately the API update model hasn't changed much from OpenGL it seems ;) ...not talking about the idea to first test out new ideas in vendor-specific extensions, and then elevate them to the core, this is definitely a good idea - but about stacking new stuff on the previous API version, this approach is what turned OpenGL into the heap of accumulated cruft it is today. Direct3D instead was a new API with each n…

OpenGL deprecated the cruft in 3.0, removed it in 3.1, then added a way to get it back with the compatibility profile in 3.2. Turns out a lot of people still wanted that cruft and they were a big enough market that people listened to them. I believe it was CAD software asking for this which on Windows is the only major user of OpenGL. Direct3D is mostly used for games so if your new game has to use a new API that's n…

The CAD market is also not that much impressed with Vulkan's complexity.

Re: Vulkan 1.2

#44

Post by badsectoracula »

pjmlp wrote: post #36
badsectoracula wrote: post #35

Earlier quoted context omitted.

It isn't just newbies, i write OpenGL code for almost 2 decades, i see no reason to do use the harder parts of the API when i can simply use the easy parts :-P. Though i disagree with OpenInventor, it is too complex and takes too much upon itself, which few wanted - see Direct3D Retained Mode which despite being a much simpler API (both compared to D3DIM and OpenInventor) didn't see much use and in an uncharacteristi…

I think that widespread adoption of middleware engines has proven that retained mode was the way to go. The ones that don't use one, end up reimplementing their own scene graph anyway. As for the rest, full with you.

That middleware is a different beast though, they are different engines providing different solutions for different problems - you can't have any single one of them be the solution to all problem and most of them are very complicated to be defined as a standard that is supposed to live for decades.

OpenGL, Vulkan and Direct3D are at a level where they enable you to write your own engine, but not at the level where they provide your the engine themselves. Microsoft tried it with Direct3D RM and it didn't work and Sun also tried it with Java3D as the official way to do 3D in Java but also didn't catch on (it caught on more than D3DRM but that is mainly because there was no other official way - however its popularity paled in comparison to OpenGL bindings that appeared soon after and nowadays it has been reimplemented and lives on top of these bindings).

Re: Vulkan 1.2

#45

Post by MaxBarraclough »

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…

> Vulkan is not getting a more developer friendly API

It's not going to be 'dumbed down', sure, but developer-friendly APIs may still be possible through higher-level systems like Unreal Engine, no?

Plenty of developers will benefit from Vulkan without mastering it. I presume they already have.

Post reply on HN