Hacker News Reader

Comment by nothis | Hacker News Reader

Jesus christ.

I understand that Vulkan is very, very niche but as someone who doesn't know much more than the basics of maybe setting up an OpenGL window to draw anything, the "drawing a triangle part" just seems insane!

I knew this is some hardcore, hardware-level stuff usually only ever touched by rendering engine programmers but I figured, if I had some super special niche case that could be sped up by Vulkan, I could maybe "give it a try". But this? 800 lines of code to draw a triangle! I never knew the difference to OpenGl was this extreme!

View on HN

> I understand that Vulkan is very, very niche but as someone who doesn't know much more than the basics of maybe setting up an OpenGL window to draw anything, the "drawing a triangle part" just seems insane!

Every time a Vulkan/DX12 post is shared, this sort of comment is written. Modern GPUs are complex. They have a lot of knobs to turn. OpenGL has a lot of these same knobs, except they are implicitly turned for you in the most basic cases. But your average rendering code is nothing like the most basic OpenGL case, and involves much more knob turning.

You'll be fine. If you want to learn about how your modern GPU works, this will suit you. If not, no worries, you still have game engines.

Maybe that's old-fashioned but I'm just not a big fan of the "just use Unity" argument. Game engines tend to be horribly bloated, it's in their nature. Plus you're now dependent on a costly, proprietary black-box for the lifetime of the game, good luck if a screw is loose between the layers.

I guess the answer is that there is now a greater purpose than ever for in-between graphics libraries if all you want to do is draw a few triangles with a texture. They say they continue to support OpenGL in parallel, but considering that Vulkan was originally called "GLNext", I have my doubts about how long they want to continue to do that.

It's just that I haven't come across such a wall of code in a "beginner's guide" tutorial in quite a while. Feels a bit like they are moving to target big-budget engines exclusively, now. I see that this is in the nature of modern graphics hardware, but still.

Well, what are you trying to do (from a beginner's perspective)?

Are you trying to quickly understand how to draw a triangle to a screen with a texture? I would say...write a quick software rasterizer.

Are you trying to understand how modern GPUs work, and how to use them? Use Vulkan/DX12/Metal.

Are you just trying to draw a ball on the screen and kick it around? Use a game engine.

At this point, OpenGL doesn't really fit any of those boxes. What it does kinda do is...conceptually show you how 3D rendering works, but does it faster than your first software rasterizer would, and abstracts a bit of the math away if you use the API in just the right way.

The most important aspect of OpenGL is that it has a huge legacy catalog of software, including courses that teach 3D graphics programming with OpenGL.

> They say they continue to support OpenGL in parallel, but considering that Vulkan was originally called "GLNext", I have my doubts about how long they want to continue to do that.

Meh, they've been using "GLNext" in internal presentations forever. "Vulkan" as you know is basically AMD's Mantle more than an evolution to OpenGL. And don't you fret about OpenGL: lots of workstation apps still use it with no intent of changing, so...it'll stick around.

I look at Unity as a Camera. 100 years ago you needed to build your own camera if you wanted to shoot a movie. Now, almost no directors build their own cameras except for special needs (filming underwater for example).

So, do you want to make cameras or do you want to make movies? Translating to games. Do you want to make game engines or do you want to make games? Like the camera example, if you have some special needs maybe you want to make the game engine but for most games, like most movies, just using an off the shelf game engine will be good enough.

I agree with you GL is dead. There might be one more version of GL but after that there will be zero pressure to update it because all the top graphics people will be vulkan/metal/dx12 only

I suspect that you'll be able continue to use the tried-and-true methods, far, far into the future. OpenGL and DirectX11 aren't going anywhere anytime soon, and there are still games coming out with DX9 minimum specs. Last time I checked you can even use mid-90s OpenGL immediate mode calls.

At the very least, there will continue to be support for all of the thousands and thousands of legacy games, one way or another.

Well obviously there's a lot more boiler plate than OpenGL, but Vulkan's goal isn't to replace OpenGL in cases like yours. And honestly, 800 lines of configuration is probably a godsend for people who want it, considering there's not much of a leap in terms of number of lines between drawing a triangle and drawing... well, anything else.

This sentence stuck out to me, from the 'Overview' page:

"Because Vulkan is so explicit about every operation and the validation layers are so extensive, it can actually be a lot easier to find out why your screen is black compared to OpenGL and Direct3D!"

So Vulkan is verbose? Meh - do it once, put it in a function/class/etc abstraction of your choice. On the other hand, while I now know OpenGL well enough that I rarely have the black screen problem anymore, I've had the kind of lingering, conditioned fear of it hammered into me. I haven't spent enough time with Vulkan to witness it for myself yet but I find the above sentence encouraging.

The goal is that libraries will pop up to wrap around vulkan and give bare metal access to those who want to use it. It is necessary in order approach zero driver overhead. OpenGL is also not geared for multi threaded applications.

I figured that. I guess the days where an indie-ish indie developer would ever touch the bottom-level graphics API are over. Somehow that just seems a little sad.

> I guess the days where an indie-ish indie developer would ever touch the bottom-level graphics API are over.

They weren't touching it before, either. Great complexity is hidden in GPU drivers. Vulkan and DirectX 12 just makes it so you have to write a great deal of that complexity yourself, in hopes that you'll be able to optimize for your specific use case.

It's 800 lines including setup code, not 800 lines of code solely to draw a triangle.

It's the difference between the C standard runtime library (OpenGL), where you can call `read` and calling the kernel directly via custom system calls to implement the functionality of read (Vulkan).

And like many modern applications, this power is necessary (like OCamal uni-kernels that re-implement system calls for high performance servers). Virtual reality can barely work on cutting edge graphics cards, even then the quality has to be low; to say nothing of augmented reality (which also uses the cards for image processing).

> It's the difference between the C standard runtime library (OpenGL), where you can call `read` and calling the kernel directly via custom system calls to implement the functionality of read (Vulkan).

In fact, that's just one line: syscall(SYS_read, fd, buf, size);

I guess it's like writing your own SATA commands for the disk drive. Or like a car analogy of some kind.

modern OpenGL requires quite a ridiculous amount of code to draw a triangle as well.

>But this? 800 lines of code to draw a triangle!

Developers that deal with high performance graphics want as much control as possible with their rendering pipeline. Vulkan gives them this control. Developers complained about the overhead that OpenGL and DirectX (before 12) imposed on their rendering pipeline and these bottlenecks would always be in the API of these graphics libraries. When you need to render a frame in 16ms or 30ms you can't afford precious milliseconds being wasted by bloated and inefficient API calls. Vulkan was created to address the years of complaints AMD received from game developers. So, while you may think that's a lot of code, a game developer would think otherwise.

When I put my head into C++ head space, 800 lines seems like no big deal.

Isn't it about that to open a window that you can draw on in windows from first principles too?

Not that this is an acceptable situation, it just is.

It's only ~50 lines of code to create a window:

http://pastebin.com/drrRJ6Kd

Well, isn't Windows quite a mess as well?

Reply on news.ycombinator.com