Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I've read that generally opengl is just easier to use than vulkan

[here's](https://learnopengl.com/code_viewer_gh.php?code=src/1.gettin...) an opengl triangle rendering example code (~200 LOC)

[here's](https://vulkan-tutorial.com/code/17_swap_chain_recreation.cp...) a vulkan triangle rendering example code (~1000 LOC)

ye it's fair to say opengl is a bit easier to use ijbol




You’re getting downvoted for some reason, but OpenGL is absolutely easier. It abstracts so much (and for beginners there’s still a ton even with all the abstraction!). No need to think about how to prep pipelines, optimally upload your data, manually synchronize your rendering, and more with OpenGL, unlike Vulkan. The low level nature of Vulkan allows you to eek out every bit of performance, but for indie game developers and the majority of graphics development that doesn’t depend on realtime PBR with giant amounts of data, OpenGL is still immensely useful.

If anything, an OpenGL-like API will naturally be developed on top of Vulkan for the users that don’t care about all that stuff. And once again, I can’t stress this enough, OpenGL is still a lot for beginners. Shaders, geometric transformations, the fixed function pipeline, vertex layouts, shader buffer objects, textures, mip maps, instancing, buffers in general, there’s sooo much to learn and these foundations transcend OpenGL and apply to all graphics rendering. As a beginner, OpenGL allowing me to focus on the higher level details was immensely beneficial for me getting started on my graphics programming journey.


It won't be OpenGL-like, it will probably just be OpenGL https://docs.mesa3d.org/drivers/zink.html


This is a bit misleading. Much of the extra code that you'd have to write in Vulkan to get to first-triangle is just that, a one-time cost. And you can use a third-party library, framework or engine to take care of it. Vulkan merely splits out the hardware-native low level from the library support layer, that were conflated in OpenGL, and lets the latter evolve freely via a third party ecosystem. That's just a sensible choice.


And often those LOC examples use GLFW or some other library to load OpenGL. Loading a Vulkan instance is a walk in the park compared to initializing an OpenGL context, especially on Windows. It's incredibly misleading. If you allowed utility libraries for Vulkan to compare LOC-to-triangle Vulkan would be much closer to OpenGL.


It depends on the operating system. On macOS and iOS it was always just a few lines of code to setup a GL context. On Windows via WGL and Linux via GLX it's a nightmare though. Linux with EGL is also okay-ish.


I mean you're literally suggesting that people should use a third-party framework/engine/library because writing all the Vulkan boiler plate yourself is too hard.


Drawing conclusions from a hello world example is not representative of which API is "easier". You are also using lines of code as measure of "ease" where it's a measure of "verbosity".

Further, the OpenGL example is not following modern graphics best practices and relies on defaults from OpenGL which cuts down the lines of code but is not practical in real applications.

Getting Vulkan initialized is a bit of a chore, but once it's set up, it's not much more difficult than OpenGL. GPU programming is hard no matter which way you put it.

I'm not claiming Vulkan initialization is not verbose, it certainly is, but there are libraries to help you with that (f.ex. vkbootstrap, vma, etc). The init routine requires you to explicitly state which HW and SW features you need, reducing the "it works on my computer" problem that plagues OpenGL.

If you use a recent Vulkan version (1.2+), namely the dynamic rendering and dynamic state features, it's actually very close to OpenGL because you don't need to configure render passes, framebuffers etc. This greatly reduces the amount of code needed to draw stuff. All of this is available on all desktop platforms, even on quite old hardware (~10 year old gpus) if your drivers are up to date. The only major difference is the need for explicit pipeline barriers.

Just to give you a point of reference, drawing a triangle with Vulkan, with the reusable framework excluded, is 122 lines of Rust code including the GLSL shader sources.

Another data point from my past projects, a practical setup for OpenGL is about 1500 lines of code, where Vulkan is perhaps 3000-4000 LOC where ~1000 LOC is trivial setup code for enabled features (verbose, but not hard).

As a graphics programmer, going from OpenGL to Vulkan has been a massive quality of life improvement.


I also am a graphics programmer and lead Vulkan developer at our company. I love Vulkan. I wouldn’t touch OpenGL with a 10 foot pole. But I also have years of domain expertise and OpenGL is hands down the better beginner choice.

The Vulkan hello triangle is terrible, it’s not at all production level code. Yeah, neither is the OpenGL one, but that’s much closer. Getting Vulkan right requires quite a bit of understanding of the underlying hardware. There’s very little to no hand holding, even with the validation layers in place it’s easy to screw up barriers, resource transitions and memory management.

Vulkan is fantastic for people with experience and a good grasp of the underlying concepts, like you and me. It’s awful for beginners who are new to graphics programmers.


I've used OpenGL for over 20 years and Vulkan since it came out. Neither of them is easy, but OpenGL's complexity and awkward stateful programming model is quite horrific.

I've also watched and helped beginners struggling with both APIs on many internet forums over the years, and while getting that first triangle is easier in OpenGL, the curve gets a lot steeper right after that. Things like managing vertex array objects (VAO) and framebuffer objects (FBO) can be really confusing and they are kind of retrofitted to the API in the first place.

I actually think that beginners shouldn't be using either of them and understand the basics of 3d graphics in a friendlier environment like Godot or Unity or something.

Vulkan 1.3 makes graphics programming fun again. Now you don't need to build render passes and pipeline states up front, it's really easy to just set the pipeline states ad-hoc and fire off your draw calls.

But yeah, judging by the downvotes my GP comment is receiving, seems like a lot of readers disagree. I'm not sure how many of them have actually used both APIs beyond beginner level, but I don't know anyone who has used both professionally and wants to go back to OpenGL with its awkward API and GLSL compiler bugs and whatnot.


I'm mostly with you, and for the record have both used OpenGL and Vulkan professionally in shipped titles. I personally have no interest in going back to OpenGL.

But I think the disconnect is that neither you nor me have any reason to fear Vulkan. I love how explicit Vulkan is and that the spec is in such depth, the only thing that comes close imho are the proprietary console APIs. I've also worked with Metal and DirectX and the documentation for those is just bad, you kinda have to know what you are doing already to understand the scraps of information you get and reason about the unspoken implementation details.

That all being said though, the Vulkan spec and setup is just daunting for a beginner. And yeah, you can take a lot of shortcuts like not pre-building your PSOs or being lax with your barriers and memory handling. But I feel like you might as well just not use Vulkan in that case since you are throwing away some of its biggest advantages. Just AZDO it up and take advantage of the IHVs having spent decades beating on their OpenGL implementation (as long as we don't count the red team). A lot of Vulkan is just boilerplate and easy to-do and abstract away, but doing Vulkan right, that's the hard part in my opinion.

Not to mention that it's really easy to build insidious gotchas into your code that are really hard to spot. Nvidia famously just doesn't care about image layouts, so if you just develop on Nvidia hardware it can be pretty easy to write code runs as if it was correct, but will explode on hardware that does care about image layouts. I have a drawer full of GPUs from different IHVs and generations just for day to day development. That's a really high barrier to entry.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: