>>107788589
is that what you say as your xxl dragon dildo with extra thick cum lube penetrates your hole?

And yet somehow only id software makes it look impressive.

>>107788589
Its garbage.

>>107788589
Is Slang mature enough? I want to use OpenGL and Vulkan with the same shaders.

>>107788589
>OpenGL if it was made by retaeds

And yet no one here can tell you why.
Including OP.

>>107788856
Not OP, but I do graphics programming as a hobby and I'll tell you why...

It's because it was made at a time when GPU resource management and the underlying hardware was incredibly diverse. It was made at a time when GPUs were beginning to converge on a generalized compute-first method of rendering, but instead they decided to bog the API down to support GPUs that were already 5 years old by the time version 1.0 was released.

Nobody wants pipeline state objects. They're the reason we have huge shader caches and stuttering in games. They were an artifact from hardware from before Vulkan was created.

We don't need different binding models between different card vendors anymore. Are there even any GPUs in the past 10 years that don't support bindless resources?

Non-coherent cache layouts were only useful when we had a dozen different chips on the board doing different things. You can expect sane memory layouts on any modern hardware to the point that you can literally use C-style pointers IN YOUR FUCKING SHADERS and expect them to be faster than the old memory models.

Geometry shaders were already known to be a shit concept and on the way out before the API was released. To make this part of the core rendering pipeline instead of an extension so that drivers didn't need to waste the effort of supporting them was absolutely moronic. Honestly I blame Intel on this one.

And now it's even further obsoleted because modern hardware supports ReBAR which removes the need for dedicated transfer queues and specialized memory locations. Not to mention Mesh shaders, variable rate fragment shaders, and all the AI bullshittery being shoved into modern GPUs that basically turn the API into just an extension loading machine where everyone ignores the core API if they're doing anything serious.

Oh, and just to be clear this is also an issue for DX12. We need a DX13 and Vulkan 2.0 that assumes hardware from this decade with compute-first and coherent memory models.

>>107789099
>which removes the need for dedicated transfer queues and specialized memory locations
The only instances of such memory are tiny compared to dedicated DEVICE_LOCAL buffers, and their only advantage is that the host can write into them directly (which they most often do wrong anyway because they all use memcpy and its wonky caching policy).
But aside from that: primary and secondary command buffers, allowing the buildup of instructions in usermode without constant communication with the GPU and kernel validation; multi-stage pipelining (able to modify input buffers the moment data has been submitted to the shader, not when the image has been rendered); and multi-resource binding (unfortunately not creation and destruction).

if you know dx12 already then vulkan is not that different. if you only know dx11 or opengl then vulkan is a nightmare.

>>107788856
Overhead. Shader compilation. Better multithreading.
Similar to DX12.

>>107788856
3DMark has a old API test you can still run that compares the different graphics APIs. Vulkan does way more drawcalls than DX11.

>>107789422
OK, and? I can write shitty benchmarks with any API.

>>107788589
Dumb designed by committee horseshit and everyone involved should be lit on fire for coming up with something so fucking dumb.

>>107788589
Of which you're neither. Tranny

Khronos really need to nuke all 1.0-1.2 tutorials off the internet.
AND ALSO HAVE ACTUAL DOCUMENTED EXAMPLES FOR ALL THE NEW EXTENSIONS
THAT ALSO INCLUDE PROPER SYNCHRONIZATION WITHOUT HALF-ASSING IT WITH UNUSABLE vkDeviceWaitIdle's IN THE RENDER LOOP

>>107791514
They can't even provide a vkCreateImages/vkDestroyImages. You can bind multiple images in one go, but you cannot construct and destroy them.

>>107788598
why are ruskeks like this?

>>107792664
Why are autists like this?

File: file.png (60 KB, 696x290)

60 KB PNG

>>107788589
lol

>>107788589
giving the user too many options is bad design

>>107792984
Enjoy being worked around, then.

>>107789099
>"before vulkan was created"
>"what x in the past 10 years doesnt support y"
>some babble about layouts, doesnt understand why they'd expect in the pipeline, and then just sperges "YOU CAN USE C POINTERS AND ITS FASTER" believing this is a tangible argument spoken in absolute terms
>"x were known to be a shit concept and on the way out before so much as a draft was released"
>nigger babble about rebar
>we can remove pcie blocks in charge of memory transfers now, but wait...
>..."whaaa muh 'who even bothers with feature'-added complexity from 15 years ago / sm4-ish feature level"
>..."whaaa muh nonexistent ai complexity being shoehorned in now is bad"
>
>therefore we need DX13


Is this what reviewtechusa is like nowadays? did you you feed some "d3d13 in two weeks" video to chatgpt?

>>107789481
Yet you're a jit

>>107793146
OK, autist.

107793152
Says the jit, OK.

>>107793152
Stupid Nigger

Two different dumb autists at the same time?
This is 4chan, so it's expected, but still.

I'll be honest I tried porting my OpenGL based rendering engine that consists of about 5k lines of code to vulkan about a year ago and after spending several evenings and 500 ish lines of code just getting it to the point where it could render a triangle again I abandoned it and stuck with OpenGL.

I played Doom 2016 on an R9 380X. With the default render thingy it ran at around 45-50 fps on highest settings, with Vulkan it ran at up to 90
Why doesn't everything run on Vulkan?

File: 1743438633301013.png (262 KB, 680x680)

262 KB PNG

I use OpenGL 3.1 because that's what I know and can't be bothered to learn Vulkan.

File: fab.jpg (14 KB, 296x170)

14 KB JPG

>>107788589
This separated the boys from the men.
~Jerry Sanders, probably

File: vulkan.png (632 KB, 1082x1011)

632 KB PNG

A reminder that Valve says that you should choose Vulkan over DirectX.

the passion with which u guys are discussing this, impressive

It would have a much better reputation right now if the first hit for "Vulkan tutorial" ditched all of the crud that 1.0 started with to appease the mobile manufacturers. Right now you pretty much have to dredge through the Khronos, NVidia and AMD blogs, conference recordings and developer rants first just to deduce which parts are relevant for desktop GPUs.

File: IMG_0133.png (1.09 MB, 1000x1497)

1.09 MB PNG

>>107793998
>Valve said Valve said we must do what Valve says!

>>107793916
Because Vulkan is very explicit about its object use, to the point where sometimes it's just stupid. This means that there is a lot of boilerplate involved that, frankly, a lot of developers simply don't wanna deal with.
>on the other hand it's very opaque about its internal implementation, to the point where you cannot preallocate memory for both its objects and/or its command buffers, and render passes/dynamic rendering is its own very fucking stupid thing

>>107794329
(You) have to. (You) explicitly. Because you're a miserable contrarian with no other personality trait.

>>107794392
Creepy projection on your behalf, anon. Apply yourself.

>>107794405
See what I mean?
>you're a miserable contrarian with no other personality trait
And if you suffer an autistic breakdown, even better.

>>107794416
Much more if you do it properly - i.e. create queues for render and copy and separate instance state from device state from pipeline state from swapchain state (in case the user does something that issues a reset; a lot of developers don't even do that, they just tell you to restart their game).

>>107794392
>if I don’t blindly suck off a corpo that makes me a contrarian
Gabe isn’t going to kiss you bro

>>107794568
This isn't about me being kissed by Gabe.
This is about my entertainment about you being forced to kiss Gabe.

>>107788589
reminder that shitcan is the worst of all modern APIs (dx12, metal, even the old mantle)

>>107794587
Using DX12 just like all the studios that make mega money (such as Hoyo). Sorry.

>>107794601
OK, you autistic Texas Sharpshooter.

>>107794611
The only autism here is your autistic attraction to Valve, the company that has fought several lawsuits in their bids to fuck the consumer.

>>107794645
nta, I think valve is based but for a different reason, creating such subhuman retards that defend their right to keep getting fucked in the ass by the fatty, truly sublime

>>107794416
i'm not a graphics engine developer, but this doesn't sound like a sensible argument to me. like who is developing a game engine to render one triangle? what does it matter how efficient an interface is to render one triangle rather than millions?

>>107794678
>valve is le based for funding loonix development from the good of their hearts and totally not because ms posed a threat to their business model

>>107794645
>to fuck the consumer
If they're all like you, then I wholeheartedly support them. Let them fuck you until you're bleeding from your asshole. And I don't even use Steam or play their games.

>>107794701
Only that MS had to give more and more and more and more control to developers because their nice DirectX abstractions caused too many mode switches and draw calls.

>>107789233
>The only instances of such memory are tiny compared to dedicated DEVICE_LOCAL buffers
On my 30X0 series Nvidia card it covers all of VRAM.

>>107794815
That's what VkPhysicalDeviceMemoryProperties tells you? And the memory supports optimal tiling, too?

>>107794794
>Only that MS had to give more and more and more and more control to developers because their nice DirectX abstractions caused too many mode switches and draw calls.
that post was about windows and the windows store, not directx

>>107794855

        memoryHeaps[0]:
                size   = 8406433792 (0x1f5100000) (7.83 GiB)
                budget = 7601127424 (0x1c5100000) (7.08 GiB)
                usage  = 0 (0x00000000) (0.00 B)
                flags: count = 1
                        MEMORY_HEAP_DEVICE_LOCAL_BIT

        memoryTypes[5]:
                heapIndex     = 0
                propertyFlags = 0x0007: count = 3
                        MEMORY_PROPERTY_DEVICE_LOCAL_BIT
                        MEMORY_PROPERTY_HOST_VISIBLE_BIT
                        MEMORY_PROPERTY_HOST_COHERENT_BIT
                usable for:
                        IMAGE_TILING_OPTIMAL:
                                None
                        IMAGE_TILING_LINEAR:
                                color images
                                (non-sparse, non-transient)

>optimal tiling
You can't do optimal tiling on rebar I'm pretty sure.

>>107793998
>Valve said
Their Vulkan rendrer backend for CS2 sucked ass and only recently became somewhat good. HL Alyx is using DX11.

>>107794896
Nah, that was just confirmation. ReBAR is supposed to be used for tiny linear buffer updates for which a DMA copy would be overkill.

Strange though. On my machine it's only 200 MiB. Not that it really matters because of the usecase.

>>107794860
you can’t expect Valvejeets to have reading comprehension skills for the English language.

>>107795325
Where did Valve touch you? I'd like them to do it again.

>>107788589
Vulkan is based
Contrarians seethe
In the future there would be only Vulkan which we will simply call the graphics API or GPU api.

>>107788589
Khronos makes OpenGL:
>everyone - both hardware and software developers - say it's crap, badly designed (straight up mis-designed) and everyone decides to use whatever Microsoft decided to concoct instead.
Khronos reaction:
>let's create API that's basically not designed at all, giving all possible options anyone could imagine
>still fail and have to release further revisions along the line
>it now takes 10 million lines of code to display a single triangle
>not supported on MacOS anyway - there go promises of better portability

Based. DXVK allows me to play all directx games with vulkan rendering, zink allows me to play all opengl games with vulkan rendering. mpv allows me to watch all videos with vulkan rendering & vulkan hardware decoding. Whisper.cpp allows me to offload speech translation models to the GPU with vulkan. What else is there?

>>107796950
>DXVK allows me to play all directx games with vulkan rendering
DXVK is limited in its effectiveness because it cannot fill and submit command buffers out-of-order. You maybe get some reduced mode switching overhead (because a lot of Vulkan is located in userspace, not kernelspace), but that's it.

File: asdfasdf.jpg (414 KB, 848x1200)

414 KB JPG

>>107788589
Vulkan has filtered me 3 or 4 different times now. Technically I use Vulkan via SDL3 but I'm just not good enough. I want to be. I want to be a low level graphics programmer. But it's so goddamn hard holy fuck.

Maybe I should try Vulkan again.

>>107797105
Learn wgpu instead.

>>107797128
assuming you mean webgpu? I've considered it especially with the recent release. It does defeat the purpose of being that low level, but it would also allow for demos to be far more easily accessible.

>>107788589
Vulkan is for LARPers
DirectX is for men

>>107789099
>Nobody wants pipeline state objects. They're the reason we have huge shader caches and stuttering in games. They were an artifact from hardware from before Vulkan was created.
This is complete nonsense.
Stuttering in games happens because of waiting an unreasonably long time for resources to be available for rendering. Circumventing that is simply a matter of implementing asynchronous execution.

>>107797186
I do not use Windows because I am not Indian.

>>107797268
win32 is the only stable ABI and directx the only non-broken graphics API under troonix

>>107788589
Nah, it's a stupid take. Most people don't need it but think it make them part of some cool gang for it. Meeh, it's how we evolve as a specie I get, young men have to prove themselves somehow, but if you just to want to make some graphics go for opengl already, if only for learning. Or better yet, webgpu (which simplify a lot of things).

That being said, 1.3, dynamic rendering and bindless buffer addressing make Vulkan waaaaay more nice than when it came out.

>>107788694
Yeah, you can compile slang shader to anything (glsl, hlsh, metal, wgsl, spirv, ..).

>>107797105
Depends on when you tried it for the last time, go for WebGPU if you need to learn the basics tho.

>>107797186
DirectX is dead, but it gaves good things to the industry (HLSL for example).

>>107798398
>DirectX is dead, but it gaves good things to the industry
The one thing that DirectX did was force GPU manufacturers to provide a standard feature set. Y'all still remember the mess that SVGA was? Or, heck, VGA. Horizontal scrolling.

>>107793882
>>107794313
This is pretty much why Vulkan will always be a massive piece of shit and everyone involved in it should be deeply ashamed of themselves for creating something such a piece of garbage.

>>107799459
>the sound of getting filtered by Vulkan
>hard

>>107799459
If a framework being low level is enough to filter you and vent on 4chan, maybe you should stick to Scratch.

>>107797105
No, don't blame yourself. Vulkan is just a terribly designed API and the only one not good enough is Khronos for their incompetence.

>>107797266
That's a completely different issue entirely. That point is obviously referring to already well-optimized games where the API is the issue and not something as basic as asynchronous resource loading. We're talking about the API here, get some reading comprehension.

PSO creation is expensive because you're calling the low-level driver's compiler on its creation. And other than the viewport, scissor rect, and stencil values you cannot change any individual part of it dynamically. Which means if you want to get the performance advantage of embedding your rendering state directly into a shader, then you're going to lose a ton of performance at pipeline creation.

The only way to mitigate this is to prebake your PSOs ahead of time, and when you're dealing with different vertex layouts, blend states, and all the other parts that can't be changed dynamically you're talking a huge number of permutations that blow up your memory and storage costs.

But GPUs are no longer a bunch of different chips on a board that specialize in different tasks. Modern GPUs do almost their entire work on wide, powerful, and flexible ALUs. We don't need to have a huge set of PSOs for every permutation prebaked.

Vulkan 1.3 brought dynamic rendering states which helps the issue somewhat, but it's not nearly good enough. If you take a look at Metal's design, it more closely matches how modern GPUs handle this.

Stop talking out your ass about something completely unrelated. This is a well known problem; https://www.sebastianaaltonen.com/blog/no-graphics-api

>>107788598
Nigga ease. I just botched a self circumcision yesterday. I can't be getting bonkers right now.

>>107788589
>Kills dual graphics
Jewish api

>>107793998
>vulkan is at least 10 years old
wtf