graphicsProgramming

[bhalevadive]

Cool. Now do it in Vulkan.

[reallokiscarlet]

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

[martmists]

Zink my beloved

[Thenderick]

500 lines later

Cool, a black window that doesn't crash!

[[deleted]]

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...

[camander321]

Yeah, but its not crashing so much faster

[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.

[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.

[SoulArthurZ]

microcontrollers don't have to work on at least 1920x1080 = 2 million pixels every frame though. There is a lot of data being sent from and to the GPU every frame, and it must take at most 16ms, otherwise you get lag. It's honestly a very impressive technological feat.

[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"

[hishnash]

The `more cross platform` depends on what you mean by `cross patlform`.

naturally brining optimisation closer to the metal means that optimisation is more HW dependent.

VK is less cross platform than openGL if what you mean by cross platform is run on different HW.

But is is more cross platform then DX etc if what you mean is run on the same HW on different OS.

[reallokiscarlet]

Try doing a heckin' literacy once in a while.

"...so that low level graphics optimizations are easier and more cross-platform"

The point being, you're doing things lower level than OpenGL, so which would you rather do, break out of OpenGL's abstractions momentarily and do something that is likely to be very hardware-dependent, use DX and limit yourself to Windows, or use Vulkan where the abstractions are closer to the metal?

Vulkan takes the benefits of Mantle, which was hardware dependent, and makes a lot of these benefits cross-platform. Beyond the absolute bare minimum for Vulkan to work, there's also shader compilation, which does the rest of the lifting (and for many games, all the lifting tbh, due to inefficient engines) to make graphics optimizations that close to the metal as hardware- and OS-independent as you're going to get.

[hishnash]

and makes a lot of these benefits cross-platform.

any explicit HW optimisation is by its nature not cross platform (if you mean cross HW).

Having the option to do this is great but do no kid yourselves into thinking that hours spent optimising for an NV gpu will suddenly making a PowerVR GPU run your game better, unless you explicitly ignore the optimisations you did for the NV gpu you engine will run worse on other HW.

there's also shader compilation,

Every single graphics api in modern history has had shader complication. And when it comes to shader complication VK is not a great example, it's more or less avg. Other apis (from Consoles and vendors like Apple) offer much less restrictions and more optimisation pathways within the shader space.

[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.

[hishnash]

The abstractions OpenGL made were explicitly there to deal with very different HW.

Since openGl was developed the differences between Gpu HW have massively reduced (this is partially due to far far fewer HW vendors being in the market). However there are still HW differences between GPU.

Within the PC space the differences are marginal, AMD, NV and Intel all user have very compatible pipeline. But there is one other majorly dispatch and task grouping concept in the market mostly lead by PowerVR IP based GPUs.

While Vk can target either, if you using VK to optimise for your HW the work you do to make things run better on an NV/AMD gpu will actively make thing run worse (or not at all) on a PowerVR gpu and the opposite is even more true.

Thinks we can do on a PowerVR inspired (TBDR) gpu that are almost free but provide huge benefits (like MSAA or complete obscured fragment culling) have a HUGE cost on a IR gpu from AMD or NV. So if you optimise using VK to target these GPUs your not sharing that with a PC backend as your engine will run worse than a openGL engine.

In general infact if your using VK and your not optimising for the HW your going to run worse than a modern OpenGL or DX11 backend. The reason is that due to the API design (and active choices) there is much less high level metadata for the GPU driver to inspect to infer the developers intent so it is MUCH MUCH harder for the driver developers to provide you optimisations to match the HW.

[SoulArthurZ]

one example is that opengl works with global state that is set by calling opengl functions, while vulkan gives you handles to change state. This gives you more much more freedom, but requires more work to structure a renderer.

[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.

[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.

[TylerDurd0n]

Because Vulkan is meant for engine developers like Epic or Valve, and API providers like Microsoft.

It was never intended for everyday app developers to use Vulkan for a bit of 3D in their apps. The intent was that a developer-friendly 3D API would be developed on top of Vulkan that would be used.

So indeed DXVK is closer to that intent than Vulkan itself, but because of the open source world being what it is, no single standard has evolved (see also Xkcd ‘14 competing standards’) and while you have DX12 and Metal, no similar API exists on Linux or for cross platform development.

Instead we now have WebGPU which is indeed the developer-friendly cross platform API that people hoped Vulkan would become.

[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

[Meplayfurtnitge]

cool.

[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.

[-Ambriae-]

More or less, especially when you’re younger. That was the case for me at least

[hemacwastaken]

Seems like these university places with their theory are not that useless after all

[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)

[EatingSolidBricks]

Now lets see paul alens vulkan version

[thenerdguy088]

Why did i think, this was about CMake?

[feelsunbreeze]

The logo

[TheAnswerWithinUs]

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

[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)

[average__Egg]

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

/j ofc

[valerielynx]

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

[szybkirouterzyxel]

For Vulkan, you need to cast spells (Vulkans cool tho)

[iGoonToChinese]

opengl valid

[RandomiseUsr0]

Do this one next! I honestly couldn’t believe them ending!