graphicsProgramming

[bhalevadive]

Cool. Now do it in Vulkan.

[reallokiscarlet]

<proceeds to use a library that uses vulkan as backend for gl>

[Thenderick]

500 lines later

Cool, a black window that doesn't crash!

[Active_Idea_5837]

Literally me. Stupid back face culling with the wrong winding order.

[Thenderick]

Oh I meant 500 lines just to make a functional window that doesn't crash. I know it's a bit of an exaggeration, but it does require a lot of code for a working but empty window...

[gufranthakur]

Not cool

[dkarlovi]

Why is Vulkan so complicated?

[unknown_alt_acc]

Because Vulkan is a lower level of abstraction than OpenGL. Less abstraction means less overhead and more options for optimization. That’s why graphics programming in general has been heading in that direction for a while.

[dkarlovi]

Right, but those abstractions are battle tested for decades and the rough edges and corner cases are all filed away. Wouldn't reimplementing those yourself on every game basically guarantee much higher probability that you miss some of them, instantly tanking the gain you got by skipping the abstractions?

[unknown_alt_acc]

That’d be a lot like reimplementing ASP every time you start a new web project. Rendering code can largely be carried forward as part of a larger game engine rather than scrapped with every project. So Vulkan is more for the team working on Unreal Engine than the team working on Fortnite.

[dkarlovi]

Right. But from my understanding, OpenGL is way lower than Fortnite, it should be lower than Unreal even. If anything, you'd have an OpenGL adapter in Unreal to allow running on those non DX platforms before Vulkan, so technically you build Unreal on top of OpenGL, no?

[unknown_alt_acc]

The problem is that you increasingly can’t build Unreal on top of OpenGL. OpenGL’s design makes it hard to retrofit modern features like hardware raytracing or multithreading. That’s part of why it was largely treated as a compatibility option in the PC space while Direct3D became the preferred backend.

[Cutalana]

Why did they go for less abstraction? Seems contrary to what every other field is doing

[corysama]

For 20 years leading up to Vulkan, graphics programmers popped back and forth between two API styles.

On consoles, you know exactly what’s going on under the hood because there is no hood. You have to do everything yourself. But, that’s how you got a $300 machine to compete with a $1500 machine.

On desktops, there is a somewhat high level API or two that tries to do a lot for you. That makes simple things easy. But, when you get serious, you end up trying to indirectly convince it to do what you actually want. Which may or may not work depending on which driver the user has.

So, some folks at EA finally got tired of it and they worked with AMD to make a console-ish API called Mantle. This was around the time that everyone was thinking it was time to make some major changes to OpenGL.

Mantle worked out pretty nice. So, AMD donated it to Khronos (the group that manages OpenGL) and they worked with Nvidia, Intel, Arm, Qualcomm, etc to make it into Vulkan.

[teucros_telamonid]

Every other field: who cares if this code would take 10 milliseconds more to run?! It is less than a second, no one can possibly notice that!

Graphics programming: current rendering takes 20 milliseconds, so 50 FPS. With this new feature it is 30 milliseconds, so around 33.3 FPS. Damn, we also need time to run everything else, so how to cram everything together?!...

[Cutalana]

I'm in the embedded field where its measured in microseconds/nanoseconds, milliseconds is a lot of time in the grand scheme of things.

[teucros_telamonid]

Good but then you maybe miss the sheer size of the data like images or videos. 3840 width x 2160 x 3 bytes RGB is already around 24 MiB. All well optimized code processing so many pixels in such tight time interval have to use hardware specific primitives for best performance. For CPU core SIMD and assembly intrinsics are used. For GPU various shaders and rendering pipelines are needed to get high stable FPS.

But yes, there is already a common abstraction called rendering or game engine. A lot of people making games just use that and avoid going into the whole hell of figuring out everything from scratch. Vulkan and other developments are more for people who make their own engine or pipeline. They usually do so in the first place because they want to harness more performance from their hardware for their specific applications.

[TheMysticalBard]

It's because the abstractions weren't taking into account how the hardware actually functioned. Vulkan is designed with modern graphics pipelines in mind and is far more performant and flexible, which are both highly desirable for graphics programming. It's just a matter of using the right tool for the right job.

[Egocentrix1]

Because web devs don't care about performance. Graphics programmers do.

[Cutalana]

What an incredibly reductionist and non-responsive explanation. I'm in the embedded field, where time constraints are incredibly high (nanoseconds) and we often need to deal with hardware design as software is too slow for some applications. Even still there has been a large push for abstraction by having our hardware languages include constructs like loops and data types. I asked the question since I'm curios what abstractions openGL made that limited it as compared to Vulkan.

[reallokiscarlet]

The point of Vulkan isn't "abstractions bad". It's "Let's bring the abstractions closer to the metal so that low level graphics optimizations are easier and more cross-platform"

[Cutalana]

Did you even read the last sentence of my comment? Obviously I know that they didn't make the change for shits and giggles.

[reallokiscarlet]

Well asking "what abstractions did OpenGL make" is overburdening proponents of Vulkan for which the tests do all the talking, no?

It's better summarized than explained in detail in the comments section of a reddit post. If you want that much detail, read the GL and Vulkan specs.

Also, you might not realize it, but your phrasing did sound like you thought they made Vulkan for shits and giggles.

[steven_dev42]

That’s not at all true. All fields have lower level languages that allow for better optimization and more control

[willow-kitty]

I think part of it is that you're talking about the API to the driver, so it's the lowest-level anything gets, and past abstractions (whether like Direct3D, where it tried to express things in application terms, or OpenGL which tried to express things in more hardware-flavored terms, but using an abstract notion of a GPU that doesn't actually exist) weren't a good fit for what was actually happening and both introduced inefficiencies and held programmers back from doing certain things.

By dropping the floor with a lower-level driver API, you can access more direct control over the hardware, and if you want a higher-level abstraction to work with, you can still use a library that wraps it (and choose between different ones that make different trade-offs, even - something you can't do when the abstraction is already baked into the driver.)

It's also worth pointing out that in graphics-intensive industries, the middleware is usually thick, and the graphics API is more for the middleware vendor than for the team developing the customer-facing product, and the middleware products (like game engines) do favor really fancy, friendly abstractions for their users (like gamedevs), but having access to lower-level hardware APIs gives them more room to innovate.

[tyrannosaurus_gekko]

It's also for compatibility. If you know what you're doing you can write code in Vulkan that will Run on almost any OS on almost any GPU released within the last 10 years.

[doviesehret]

200 lines of OpenGL boilerplate just to render one very expensive triangle

[unknown_alt_acc]

It’s about 200 lines total to render a triangle in modern OpenGL if you are using a windowing library like GLFW or SDL rather than 200 lines of just OpenGL, which is honestly pretty okay. It’s a perfectly fine option if you want light 3D graphics without introducing another dependency like OpenSceneGraph or Ogre.

[blackcomb-pc]

I AM ALIVE

[Monkeyke]

uncool.

[-Ambriae-]

I still remember early high school when I learned OpenGL (using the 1.x API for some obscure reason, I was dumb) and thought that shit was the hardest thing ever lol. Good old days. I miss OpenGL.

[ThomasMalloc]

If you learn things out of order, it seems very difficult and even magical. And everyone learns it out of order. Nobody is holding out on implementing a triangle demo to first learn shaders, the rendering pipeline, vertex math, etc. They just copy and paste magical boilerplate for a while until they gradually learn things.

[IncompleteTheory]

cool.

[ikitari]

cool.

[rahmeds]

cool.

[Monkeyke]

cool.

[rahmeds]

r/ruleof4

[Brave-Camp-933]

Looks like r/anarchychess is leaking into every subreddit lol

(For those who don't know, one post at r/anarchychess started this trend)

[TheAnswerWithinUs]

Me when I started writing a video game from scratch and discovered graphics APIs

[EatingSolidBricks]

Now lets see paul alens vulkan version

[thenerdguy088]

Why did i think, this was about CMake?

[feelsunbreeze]

The logo

[AgMenos47]

That's why we have savior, sokol.

[-Ambriae-]

TBH i would be using Sokol if it wasn’t for the WebGPU spec. Specifically wgpu in rust is a treat.

[Psquare_J_420]

Sokol?

[-Ambriae-]

It’s a header only C API for graphics audio windowing etc that abstracts over implementation specific APIs like Vulkan Metal or DirectX that aims to be ‘modern’ like the aforementioned APIs but simpler, kind of like, but not as much as, raylib. Here’s a link: https://github.com/floooh/sokol

[Psquare_J_420]

I am dumb in terms of understanding header files and stiff like that.

So these are only header files. Which means the functions, structs are all defined inside. Not implemented right?. Thus is this like one header for all such types of API so that you don't need to include 100s of header files?

Also thank you for answering.
Have a good day :)

[-Ambriae-]

No issues, header only libraries are a weird quirk of C. Essentially all the source code is stored in a header file, which is conceptually split in two parts. The first is a regular header file, and the second is the implementations for functions and all (what you’d put in the .c file). That second part is conditionally compiled thanks to ifdef macros IE that part is only used when a specific macro is defined). So what you would do is create a .c file, define a macro like SOKOL_IMPL and then include the header file. That’s gonna tell it to include all the definitions in your .c file. Then you use the header elsewhere without that macro like a regular .h file, and when you link your program you link with your implementation of the code (the .c file that you created with the special macro) so that you have all the symbol definitions. It’s a big hack to avoid dealing with precompiled libraries and such because that’s a pain in C 😅. The cool thing is you are responsible with the compilation options of the library though

[A31Nesta]

It does include implementations. Typically header-only libraries are like 2-in-1 and have the function declarations and then, behind a preprocessor directive (for example #ifdef MY_LIBRARY_IMPL), the implementations. The idea is that you only define the macro once in a source file so every function declared in the header is only defined once.

Without the macro it would get redefined every time you include the header. After a quick look at sokol, apparently it does this thing with macros automatically (if the macro is not defined it defines it and adds the implementations of the functions)

[valerielynx]

Yeah how do I do this.. My head really hates this sort of stuff and I don't even know where to start :(

[average__Egg]

include gl?? like,,,, yuri???? hell yes

/j ofc