[quote=“elect,post:3799,topic:49634”]
I suspect there are many different abstractions possible that are very different from OpenGL. Very few people will actually develop games or applications using Vulkan directly (just as not too many people are using OpenGL directly). I’m just guessing that Vulkan will allow the open source community to develop some interesting new API’s on top of Vulkan.
I think… Vulkan is not for me. And never will be.
Cas 
This is the point of Vulkan. OpenGL is a fungus growth attempting to be low-level, mid-level and high-level in different growth spurts. Vulkan is supposed to be a low-level interface. Everyone writing directly to Vulkan is like everyone writing there own low-level interface to all devices…that’d be crazy. To have one final bitch about OpenGL that I haven’t said before: Did you know that Quake 3 allocated a fixed amount of memory for GL extensions? And to keep the program from crashing OpenGL drivers detect and don’t return too much. How nuts is that? Like I said…fungus growth.
For something completely different: #gamedev 12 tips for making the best use of your time by Mike Acton
The thing is that Vulkan IS a better API, hands down. It’s more complex, in some cases needlessly complex and you can make a wrapper for those parts, but the idea of building command buffers from multiple threads and later submitting them for execution does have use, even for OpenGL.
A frustrating part of OpenGL is that it’s so difficult to thread. That means that you essentially need to split up non-OpenGL graphics tasks (culling, skeleton animation, etc), which means doing parallelizable work interleaved with OpenGL commands. Currently the optimal way of doing things is this:
- Do culling with N worker threads. Save all visible objects in a list/lists.
- Map buffer(s) on the OpenGL thread. Even with persistent buffers you may have to resize the buffer(s) so that all data can fit, which means OpenGL communication may be needed anyway.
- Calculate matrices, skeletons, etc for all visible objects and store them in the buffer(s) using N worker threads.
- Unmap buffers on the OpenGL thread.
- Do all OpenGL commands on the OpenGL thread.
This maximizes parallelization and respects OpenGL’s limitations. Mapping a buffer causes a synchronization point inside multithreaded drivers, so if you’re going to map buffers you should map all of them at the same time, not interleaved with draw calls, as that causes needless stalls.
Frame | Frame 1 start | Frame 2 start |
| | |
Workers | ---Frustum culling--- ---Write data--- |---Frustum culling--- ---Write data--- |
OpenGL | -map- -unmap- --Draw calls--| -map- -unmap- --Draw calls--|
Driver | ---Driver thread processes frame 1---SYNC! ------<stalled>------ --Process frame 2 draw calls....
In other words, the driver offloads heavy OpenGL calls to an internal driver thread that processes stuff in parallel with the game. This system maximizes the amount of time the driver thread has to finish its job before mapping a buffer for the next frame, which forces a sync. The final draw call processing pretty much only does the draw calls decided on after the first culling pass.
With Vulkan we can throw that entire thing out and just map buffers on any thread, write data on any thread and generate command buffers on any thread. Sure, the vkQueueSubmit() calls to run the command buffers have to be done on a single thread, but you can actually run all your created command buffers with a single vkQueueSubmit() call, so it’ll be fast. Very fast.
The thing is, this approach has uses in OpenGL too when threading things. Consider this loop:
for(GameObject o : objects){
if(frustumCuller.isVisible(o)){
o.draw();
}
}
Interleaving OpenGL commands and frustum culling is bad, since frustum culling can be very expensive (data structure queries, etc) so we want to do that on multiple threads, but OpenGL doesn’t allow drawing from multiple threads. So we end up doing this:
//Parallel loop:
for(GameObject o : objects){
if(frustumCuller.isVisible(o)){
visibleObjects.add(o);
}
}
//OpenGL loop:
for(GameObject o : visibleObjects){
o.draw();
}
And, well, there’s your home-made command buffer. So why not just queue up draw calls directly instead of objects? There’s actually something to gain from doing that even in OpenGL, so it only makes sense to take that approach for a generic abstraction that supports both of them. Even if we can’t make a GPU command buffer directly with OpenGL, we can (and should) still minimize the amount of extra work we do while doing all the draw commands.
TL;DR: Having command buffers in an abstraction that can run both OGL and VK under the hood is useful for OGL too, so an abstraction should feature command buffers.
Best way to do culling is on the gpu itself so you exploit: cpu offload, gpu parallelism and data locality
Not sure I agree. The GPU is a lot less flexible, so you won’t be able to use any advanced data structures efficiently.
The OpenGL spec + extensions is a very complicated environment to work on, especially for new users, and stuff like Nvidia’s AZDO I find absolutely crazy and worse than Vulkan. Whenever I do any serious development with OpenGL, it feels like I’m in a constant fight with the drivers. So many details to get right, for all kinds of crazy reasons, so easy to get sub-optimal performance, so easy for things to just plainly don’t work (even if you ignore driver bugs). The only other environment that feels like that is database SQL, where you often have to resort to vendor-specific functionality and you’re battling the shitty decisions the optimizer makes all day long.
Screw that, never again.
I’ve gone through the Vulkan spec now and not once did I think “oh, that’s doesn’t make any sense”. It’s a very well-thought-out API. There are two aspects that are complicated and hard:
-
Initial setup and figuring out supported features and various hardware limits/constraints. This is understandable, you have a cross-platform & cross-vendor API that also covers a wide range of hardware. From tiny, low-power, phone GPUs to Titan/Fury. It even supports tiled architectures out of the box. This aspect can easily be hidden away in libraries, used by many projects. Worst case, you’ll only have to worry about it once (or once per market you’re targeting).
-
Safety under concurrency, the user is responsible and has to worry about a lot of stuff. But this unlocks opportunities for better performance. Also, I believe that over time it will get easier, once people have experience with the API and best practices are published. I don’t think engines with proper architectures will have that many locks/waits in them.
Anyway, I just prefer a more verbose API over having to worry about what the driver is doing behind my back. The most important aspect though is performance. Even if you don’t care about any of it, better fps or fancy graphics, if you think game mechanics is the top priority (like it should), the fact that Vulkan has the potential for optimal resource usage, is absolutely critical. Keep it simple, keep the same fps, keep the same graphics, just stop wasting power. Especially battery power on mobile devices.
Plus: even if something is a good match to run on the GPU doesn’t mean you’d want to run it there.
A super plus of low-level APIs is that if there’s a bug in the code based on it, it’s highly likely to be in user code.
I didn’t test yet by myself, but this is what several presentations, sample and results from nvidia show
If that is a very complicated environment for new users, you can image Vulkan
Which one exactly? Because most of them reflect the same concepts in Vulkan…
That’s a vendors’ problem, not (really) an OpenGL’s one, hopefully things with Vulkan will be different.
It’d have been weird if it wasn’t like this…
As I said, it’s a compromise, a double edge sword, it’s always good to have choices 
Trying to stay objectively and non-biased here, I’d say with a straight face that Vulkan is actually easier than OpenGL. And that is for two reasons: consistency and explicitness
- no semantic heavy overloading of functions.
- no implicit hidden state (and there is alot of state in OpenGL)
That may result in larger code at first, but that code is indeed easier to understand, because there is nothing going on which you don’t see and you don’t have to constantly juggle state/bindings in your head like you had to when you move from one line of OpenGL to the next.
Vulkan is low level but that is not why it’s fast. It’s fast because it’s designed for modern architecture. Because Vulkan is low level all sane developers will wrap it and add ton’s of safety mechanism around it to crash as possible(asserts). That kind of abstraction won’t cost anything on release build but keep it clean. API is also super slim so it’s pretty easy to wrap. One nice One nice example of low level abstraction is this. https://developer.nvidia.com/open-source-vulkan-c-api c++ API for Vulkan to get all c++ benefits with zero cost.
It may be easier, but I don’t agree this applies also to beginners.
Anyway what you say it is right, but sometimes many OpenGL functions are perceived as overloaded because of knowledge lack and/or outdated tutorials everywhere when they are instead clearly not.
Right, but modern OpenGL offers you a lot of tools to greatly reduce that constant state/bindings switching.
Low level is one of the reason why it may be faster, if properly implemented. Same for its design.
Those mechanisms are today part of the job’s driver. Anyway we will see the abstraction to come how they will impact control and performances.
Drivers today take care of a lot of different things and they are really quite efficient.
However don’t get me wrong, guys, I am not trying to push you people away from Vulkan, on the contrary. Vulkan is great and is something actually needed and somehow late, because of the laziness of Microsoft and its monopoly, things nowadays have changed, but this is another story.
What I am trying to say is that OpenGL and Vulkan have some overlapping areas, but mainly different targets. Vulkan requires you to have a quite different background skill on what you were used to have on gl.
I’d just like you to be aware of this because I have the feeling most people underestimate this. I am convinced that nowadays, starting right away with Vulkan is a suicide. It’s like trying to climb the everest without having climbed smaller mountains. One should start by OpenGL, moder OpenGL and then, if he wants more, move to Vulkan.
Actually I would expect OpenGL to be implemented in the future as a library on top of Vulkan instead of a driver…
A frustrating part of learning OpenGL is filtering through all the dead ends and deprecated features… a shiny new API like Vulkan is at least internally consistent. That might make learning a bit easier…
I agree with Cas - I already have all i need - Shader, OpenCL
Performance not a problem - its all about caching ^^ + new physical(device) upgrade
[spoiler](+ I can’t run in on my GPU :P, same as million other ppl)[/spoiler]
Maybe later…
+Vulcan not for game development – its for Engine dev
For game dev ppl have Unity + Unreal ^^ - with Vulcan support from devs
Somebody could do worse than wrap all the fiddly boilerplate of Vulkan up into some simple one-liners for the common use-cases / targets.
Cas
I don’t know, I guess I’m just old-fashioned. I’ll stick with OpenGL.
I recently started work on a 2D game engine. I know, I know, there are lots of game engines out there that are way better, but Java is lacking in popularity in the game development industry, and I want to do what I can to change that for the better.
It’s not really going to be an engine, it’s more a framework, but I’ll try my best to pull it off. This is actually my first time doing 2D stuff in OpenGL, but it’s really simple and I really enjoy it. It’s going to be a great learning experience for me.
I’m currently working on a sprite batcher without following any tutorial of any sort, so…yeah. I haven’t finished it yet. I’ll update you guys on my progress as often as I can. Thanks 
Figured out how to use blender transparent texturing on palm trees
