5 ms·
Vulkan 1.2
- roenxi 7y agoIn 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.
- rustybolt 7y agoI don't think that is a suitable way to refer to Vulkan. It's much more low-level than OpenGL.
- theandrewbailey 7y agoIn addition, it has a completely different lineage than an 'updated' OpenGL. It started off as AMD's Mantle API.
- flohofwoe 7y agoUnfortunately 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 new major version, which in the beginning sounded insane, but turned out the better decision in the end because that made it possible to discard the cruft (the crucial part is that old API versions are frozen but still supported).
- amaranth 7y agoOpenGL 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 not _that_ big of a deal. You don't start from scratch every couple years with regular software though.
- pjmlp 7y agoThe CAD market is also not that much impressed with Vulkan's complexity.
- FpUser 7y agoLOL. 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.
- earenndil 7y agoI'm a 'small guy'. Only person working on my game engine. Would love to add vulkan support, except my GPU is fried.
- FpUser 7y agoThat's the difference right here. If you are in business of making engine then yes you can benefit basing your engine on something like Vulcan. To me: I am not exactly doing games/engines. I do use hardware accelerated graphics for some other type of development. OGL/DirectX are already a nuisance enough for me (just a friggin too that I want to use and forget). Having to go even lower level will not make me any happy at all. Well that is unless I find suitable rendering library. Hopefully some candidates are available now, just have to find time to evaluate.
- pjmlp 7y agoIt 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.
- skocznymroczny 7y agoI 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.
- pjmlp 7y agoExperience 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.
- HelloNurse 7y agoThe 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.
- MaxBarraclough 7y ago> 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.
- davedx 7y agoThis blog series on Vulkan is apparently pretty good (written by an id software engineer): https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and-so-can-you-part-1 https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and... Talk by the same guy at GDC about porting Doom 3 to Vulkan and Stadia: https://stadia.dev/intl/en/blog/gdc-2019-session:first-light-bringing-doom-to-stadia/ https://stadia.dev/intl/en/blog/gdc-2019-session:first-light...
- boutad 7y agoDoes Vulkan have an answer to DirectX Raytracing?
- flohofwoe 7y agoNVIDIA offers a vendor-specific extension: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_NV_ray_tracing.html 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.
- thrower123 7y agoOne would have thought that they might have learned from what happened with OpenGL that this is a clusterfuck and leads to fragmentation...
- st_goliath 7y agoAs 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 https://github.com/W4RH4WK/Raygun I also submitted it on HN, but with little interest so far: https://news.ycombinator.com/item?id=22037474 https://news.ycombinator.com/item?id=22037474
- thrower123 7y ago
- boyadjian 7y agoIm 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 7y ago[deleted]
- pjmlp 7y agoYou just get different implementations of Vulkan from one vendor to another plus the OpenGL middleware on top instead.
- usrusr 7y agoSure, 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.
- bullen 7y agoI'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 forever.
- pingyong 7y agoHmm. 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.)
- skocznymroczny 7y agoI'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).
- grovesNL 7y agoThere is another translation layer called wgpu (https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu) being developed as well. It's written in Rust and has bindings for C, Rust (https://github.com/gfx-rs/wgpu-rs https://github.com/gfx-rs/wgpu-rs), and some initial support for other languages (Python, Julia, Scopes, etc.). Dawn and wgpu have also been collaborating to create a common set of WebGPU headers. The WIP headers are located at https://github.com/webgpu-native/webgpu-headers https://github.com/webgpu-native/webgpu-headers if you're interested in contributing or following.
- davemp 7y agoI 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).
- plopz 7y agoIs 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?
- flohofwoe 7y agoThe 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.
- deleted 7y ago[deleted]
- slavik81 7y agoThat'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-opinions-on-dx12vulkanmantle/5215019/ https://www.gamedev.net/forums/topic/666419-what-are-your-op...