[HN Gopher] Vulkan Documentation
___________________________________________________________________
Vulkan Documentation
Author : jlpcsl
Score : 69 points
Date : 2023-10-11 13:14 UTC (2 hours ago)
(HTM) web link (docs.vulkan.org)
(TXT) w3m dump (docs.vulkan.org)
| brianzelip wrote:
| You might add the following CSS to perhaps improve the
| presentation of your header logo (which seems a little awkward
| aligned to the bottom of the navbar as I see it):
|
| ```css .navbar-item > .navbar-item {
| padding: 0; }
|
| ```
| panzi wrote:
| Also: footer.footer { display:
| none; }
|
| Or remove that element. It is empty and just adds an awkward
| gray area when you scroll to the bottom.
| sachahjkl wrote:
| my thoughts exactly lol
| MayeulC wrote:
| This seems to come from there:
| https://github.com/KhronosGroup/antora-ui-khronos/blob/e6d03...
|
| This css seems shared across multiple sites, so I'd be afraid
| of breaking one of them if not introducing yet another class,
| though I am not sure where the HTML for the inclusion of this
| logo is generated from.
|
| Edit: seems likes it comes from there:
| https://github.com/KhronosGroup/antora-ui-khronos/blob/e6d03...
| ForkMeOnTinder wrote:
| Can anyone recommend a good self-contained "hello triangle"
| example with SDL2 + Vulkan? Just yesterday I was trying to start
| a project, and I tried building the top 4 example repos on github
| but couldn't get any of them to compile without errors.
| flohofwoe wrote:
| Not SDL2, but GLFW has something like that under the tests/
| directory:
|
| https://github.com/glfw/glfw/blob/master/tests/triangle-vulk...
|
| (yes it's over 2kloc for a triangle - that's Vulkan for you ;)
| but at least it's all in one file readable from top to bottom
| instead of being spread over a dozen obscure "helper classes")
| MayeulC wrote:
| > yes it's over 2kloc for a triangle - that's Vulkan for you
|
| My understanding is that VK_EXT_shader_object should make
| such examples simpler? https://www.khronos.org/blog/you-can-
| use-vulkan-without-pipe...
| nightpool wrote:
| Ah, yes, one readable file, top to bottom
| https://i.ibb.co/qdjct5K/Screenshot-20231011-095306.png
| flohofwoe wrote:
| That's SPIRV shader bytecode. Does Vulkan actually come
| with an integrated shader compiler these days? Otherwise
| there's not much one can do for a standalone sample like
| that.
| Chabsff wrote:
| "integrated" in the sense that the SDK comes with a
| compiler, but it's not integrated in the same sense as
| OpenGL where the compiler is part of the driver.
|
| If you can compile that code, then you necessarily have
| the compiler at hand. You can't make a simple single code
| file example though. The build system has to get involved
| somehow.
| pjmlp wrote:
| Ah, way much better than it used to be.
| dcow wrote:
| I don't know what the old site was like so maybe this is actually
| an improvement, but I find this site really difficult to use and
| possibly even broken.
|
| First off it's really weird to start with a page that links back
| to the main site and then explains how to navigate the site. If
| it's not obvious how to use your nav bar then you're off to a
| really bad start. The home page should describe Vulkan and give
| me enough info to figure out where I need to go next. It should
| not be a mini tutorial on how to navigate.
|
| Further, when I click on Education from the home page for
| example, it doesn't go anywhere (scrolls to the top of the page).
| When I click on the Vulkan Proposals link, it goes to a one
| paragraph thing that says it's a cross link and when I click the
| link it goes back to the homepage. I'm so confused. I'm using
| mobile right now maybe it's not broken on desktop?
| randomNumber7 wrote:
| It's on purpose, so you get a feeling how it is to use vulcan
| /S
| danielvaughn wrote:
| As someone who's kinda hovered around graphics land but never
| really stepped foot into it, it's pretty difficult to determine
| what Vulkan represents. Is it going to replace OpenGL? If I'm
| going to start learning graphics for the first time, would it
| still be useful to start with OpenGL or should I just dive into
| Vulkan?
| Deukhoofd wrote:
| Vulkan was designed to tackle several issues OpenGL had. For
| example, OpenGL does not do multithreading, while Vulkan is
| able to, and OpenGL has a single global state, while with
| Vulkan you're able to create multiple different command buffers
| to hold the state in. In general Vulkan is also a lot faster at
| rendering, as it's closer to modern GPUs in design.
|
| While Vulkan has been slowly replacing OpenGL, it's also more
| complex than OpenGL is. This means that OpenGL is still great
| for many simple use-cases, as you won't be overwhelmed by the
| complexity that Vulkan can bring along with it.
| reactordev wrote:
| OpenGL has been deprecated on everything but Android, Windows,
| Linux, and PS4. Vulkan is the new open standard modeled after
| Metal (macos, ios) and DirectX 12 (windows,xbox). Vulkan, like
| Metal and DX12, offer direct memory access to GPU resources.
| Modern OpenGL (buffers and vao's) is close to what vulkan is
| but vulkan takes it further. With command queues for
| multithreaded rendering and everything is a buffer. Indices,
| vertices, shader uniforms, everything.
|
| WebGPU (wgpu) is another abstraction on top of all of them that
| I feel is the modern bgfx, that is, a modern abstraction of
| those buffers and queues that work across DX12, Metal, and
| Vulkan. If you aren't in the graphics space, I would skip
| learning vulkan and learn webgpu wgpu-native.
| msk-lywenn wrote:
| OpenGL has never ever been used on PS4, it has always been a
| custom API. Unless you're talking homebrew stuff.
|
| Vulkan was modeled after Mantle, AMD's own API that was
| basically what was available on consoles but less specific
| (ie. supporting more than a few custom GPUs). Direct3D 12 was
| modeled after consoles and Mantle, just like Vulkan. Same for
| Metal, that was made available in 2014, same year D3D12 was
| publicly announced.
|
| https://en.wikipedia.org/wiki/Mantle_(API)
| https://twitter.com/repi/status/446718535616585730
| qiine wrote:
| OpenGL is recommended to get started and learn the base concept
| then if you survive that you can try Vulkan.
|
| Will Vulkan replace everything? Seems unlikely considering
| Microsoft is not dropping DirectX anytime soon, and apple
| pretty much despise The khronos group, while the web seems to
| want to go the WebGPU route now.
|
| And openGL seems to simply not die.
| dotnet00 wrote:
| OpenGL is not dying only in the sense that vendors and Linux
| want to keep support around for legacy reasons and
| applications which don't need to be all that carefully
| optimized. It is pretty much dead otherwise, as it hasn't
| received any meaningful updates and extensions in a while
| exposing the myriad of features that newer GPUs have made
| available in Vulkan.
| danielvaughn wrote:
| I'd heard about this, which I think added to my confusion. My
| general impression is that Vulkan, Metal, and WebGPU are all
| separate attempts at modernizing graphics, so they're all
| kind of related in some sense but they're also distinct and
| incompatible with each other. So graphics in general are
| moving away from the legacy OpenGL model (good), but it's
| also fragmenting (bad). Fair take or no?
| TheRoque wrote:
| WebGPU is different because it's an abstraction of Vulkan,
| Metal or DX. Yes, the fragmenting is bad and annoying,
| WebGPU is the only graphics API that Apple agreed on and
| that would be truly natively cross-platform, but it's still
| new, lacking some features, and evolving.
| qiine wrote:
| The moving away part is taking decade of slow and confusing
| but still huge progress indeed.
|
| And as other have stated the absolutely CRUCIAL question in
| picking your API, is going to be :
|
| what do you want to do ?
| flohofwoe wrote:
| Vulkan, D3D12 and Metal all map to similar GPU hardware, so
| the basic concepts are also similar.
|
| They mostly differ in details like 'programmer ergonomics',
| design philosophy, and of course platform-availability.
|
| WebGPU is basically the cross section of those three native
| APIs.
| hajile wrote:
| Isn't WebGPU far closer to Metal than to Vulkan or D3D12?
| dist-epoch wrote:
| Your average graphics developer is not supposed to use
| Vulkan/Metal/Direct3D directly, but through an engine.
|
| So in a way it doesn't really matter what these low level
| APIs are like.
| flohofwoe wrote:
| > OpenGL is recommended to get started and learn the base
| concept
|
| IMHO learning OpenGL today just fills your head with outdated
| concepts, the API is much more confusing than it should be,
| and error reporting is non-existent.
|
| At least more modern APIs tell you exactly what you did wrong
| in their validation layers.
| cyber_kinetist wrote:
| I wonder if using your library
| (https://github.com/floooh/sokol) instead of OpenGL will
| alleviate some of these issues for newcomers! There's
| already a sokol port of the learnopengl.com code
| (https://github.com/GeertArien/learnopengl-examples), so it
| shouldn't be too hard to match between the tutorial
| articles and these.
| mardifoufs wrote:
| I don't think OpenGL and vulkan are interchangeable in this
| case. I wouldn't really recommend a beginner to start with
| vulkan. Yes, OpenGL might have some "outdated" concepts
| compared to vulkan but I don't think throwing someone
| directly to vulkan is more productive!
|
| Plus, tutorials and in depth guides are much much more
| common on OpenGL, but that's probably a chicken/egg type of
| situation.
| flohofwoe wrote:
| Yeah both options are bad for beginners, at least for
| cross-platform 3D APIs (e.g. D3D11 and Metal are both
| nicely balanced and well-designed 3D APIs, but restricted
| to Windows or macOS).
|
| As other have said, WebGPU is probably the best cross-
| platform option right now.
|
| (also IME the tricky thing with GL information on the web
| is that there's a lot of really outdated and sometimes
| conflicting information around - e.g. worst case is you
| end up with code that mixes old and new GL concepts
| without realizing what's what)
| LandStander wrote:
| [dead]
| [deleted]
| flohofwoe wrote:
| Both APIs are not all that great, Vulkan has a steep learning
| curve and requires tons of boilerplate code to even get a
| triangle on screen, and OpenGL is 30 years of sediment layers
| all pressed into a single 3D API.
|
| WebGPU is currently probably the best balance between:
|
| - easy to learn
|
| - easy to tinker with (in web browsers at least)
|
| - modern concepts (close enough to Metal, Vulkan and D3D12 that
| what you learned carries over)
|
| - platform-agnostic
|
| If you are on Windows, D3D11 is also a good native option, as
| is Metal on macOS.
| no_time wrote:
| >WebGPU
|
| A massive shame that it's more or less bolted to the Sodom
| and Gomorrah of modern software development (Browsers and
| JS). Atleast in mindshare for sure.
|
| There appears to be a non browser implementation of WebGPU
| now looking into it, but I can't find anyone using it or
| attempting to use it in production
|
| https://dawn.googlesource.com/dawn
| crthpl wrote:
| dawn is the WebGPU backend in chromium, while wgpu is the
| WebGPU backend for firefox written in Rust. wgpu is seeing
| a lot of use in non-browser uses; there are some examples
| on their website.
|
| https://wgpu.rs/
| hajile wrote:
| Hopefully, WebGPU will eat all its competition and we can
| finally have just one standard moving forward.
| flohofwoe wrote:
| Nah, competition is good :)
|
| E.g. without Metal as example of what a modern user-
| friendly 3D API can look like, WebGPU would probably look
| very different, and not in a good way.
|
| My personal hope is that the concept of a "3D API" will
| eventually disappear into compilers like Clang and GCC and
| their standard libs.
|
| E.g. WebGPU has a pretty big API surface just for ensuring
| that the CPU-provided data is compatible with what the GPU
| expects, and any mismatches manifest as runtime errors, not
| compile-time errors.
|
| Most of this API surface would simply disappear if the same
| compiler can see both the CPU and GPU side code, integrated
| into the same compilation process.
| Akronymus wrote:
| > Vulkan has a steep learning curve and requires tons of
| boilerplate code to even get a triangle on screen
|
| In regards to the boilerplate: Yes, for the first draw you
| require a lot, but after that, it quickly becomes almost
| neglible.
| [deleted]
| bitwize wrote:
| Vulkan represents a low-level way of talking to the GPU more or
| less on the GPU's terms. As opposed to OpenGL which is a way of
| talking to the GPU on boomer CAD programmers' terms.
|
| As for whether Vulkan is going to _replace_ OpenGL... yes and
| no. Over the next 10 or so years we may see OpenGL drivers for
| GPUs get replaced with Vulkan drivers plus an OpenGL layer
| based on Vulkan. But you will still be able to develop to
| OpenGL.
|
| Ad for what you should start with... what do you plan on doing?
| If you're looking to write a game, use a widely available
| engine like Unreal or Godot that abstracts the graphics library
| details. If you're looking to write your own engine...
| seriously, seriously reconsider.
|
| If you're _still_ interested in programming immediate-mode
| graphics below the engine layer, start with DirectX 11 and 12.
| They 're much more tractable than OpenGL and Vulkan and have
| unbeatable tooling support from Microsoft. Even if you're
| targeting Linux, you will have much more binary compatibility
| across distros by shipping it as a Windows program and running
| it under Wine.
| z3phyr wrote:
| Regarding the last statement, segregation of game and engine
| is one way of thinking. But many a times, you do not need a
| full fledged map editor, sculptor etc. You just implement the
| parts you need for your game.
| lawlessone wrote:
| Yeah Vulkans great if you are in the business of making
| Game Engines / or 3d tools.
|
| You are not going to want work in it developing your own
| game... unless you really want to, it shouldn't be
| necessary.
| auggierose wrote:
| I would start with WebGPU. Gives you hands-on cross platform
| knowledge and good foundations. Can't hurt to also look into
| WebGL, as that is more mature and deployed everywhere.
| Chabsff wrote:
| Seconding the first recommendation. WebGPU is currently the
| sweet spot between classic and modern approaches.
|
| Also, don't be fooled by the name. While WebGPU was designed
| for the web browser, there are already some solid native
| implementations (wgpu and Dawn), and can definitely fill in
| the same role as Vulkan/DX12/Metal for most casual usages.
| adrian17 wrote:
| Note that wgpu, while mostly mirroring WebGPU (and being
| used to implement WebGPU in Firefox), doesn't have an
| identical API; WebGPU being the lowest common denominator*
| of the underlying low-level APIs, while wgpu offering some
| minor platform-dependent features on top of that. For
| exaple wgpu's PrimitiveState has an additional polygon_mode
| field (that can be used to easily draw wireframes) that
| doesn't have a WebGPU equivalent.
|
| (* meaning, while simplified, it's also missing some
| convenience features sprinkled in the lower-level APIs. For
| example, from what I've seen, pipeline explosion is much
| harder to deal with here.)
| Buttons840 wrote:
| https://webgpufundamentals.org/ is the best learning
| material I've found. I've been learning Rust's WGPU and I
| appreciate that the tutorial uses a different language and
| a slightly different API[0], it keeps me thinking instead
| of just copy/pasting.
|
| I never learned OpenGL, but think I will have to eventually
| refer to some OpenGL material, because there's no WebGPU
| material except the spec and like 3 incomplete tutorials.
|
| [0]: WebGPU is a JavaScript API, so Rust cannot implement
| it exactly, but it's very close.
| bobajeff wrote:
| I also used webgpufundamentals.org to learn webgpu
| native. Only for me I was porting the examples to C. (I
| also used WGPU as the backend as I find it easier to
| debug than Dawn.)
|
| I agree it keeps you thinking about how to do things as
| opposed to just copy pasting. It also helps that the
| examples are small and in JavaScript so it's easier to
| figure out the logic that need for them to work.
| z3phyr wrote:
| Start with WebGPU, DirectX11 or OpenGL. Do learnopengl, try to
| write a gITF model viewer in it. Then rewrite the gITF renderer
| in DirectX12, Vulkan or Metal.
| midnightclubbed wrote:
| If you've not touched 3d graphics before start with OpenGL with
| a view to moving on to a modern API soon after.
|
| OpenGL does a lot of work for you behind the scenes and
| abstracts away most of the memory management, state management
| and GPU/CPU synchronization. It lets you worry about 'what' you
| are rendering and handles a lot of the 'how' internally. Vulcan
| and its peers (DirectX12, Metal) assume the programmer knows
| best and requires you to do everything manually. You have more
| control that way but for a beginner it will swamp you with
| minutia and make it far more difficult to things up and
| running.
| dist-epoch wrote:
| OpenGL is Python, Vulkan is C++.
| WithinReason wrote:
| As a car analogy, OpenGL is a Toyota. Vulkan is the pieces to
| a Ferrari.
| jameskilton wrote:
| Vulkan, Metal, and DirectX 12 are lower-level graphics APIs
| that provide abstractions better suited towards the GPUs of
| today (big, big buffers of data, processed by shaders). These
| new APIs came about because OpenGL and DirectX have grown into
| handling too many things are are now themselves the source of
| many bottlenecks for pushing data to your GPU.
|
| These APIs being lower level means they are harder to get into,
| you really have to understand how GPUs work to understand why
| these APIs are the way they are. If you want to know that then
| by all means, dive in! It's fascinating stuff, IMO.
|
| To answer your specific question, yes, Vulkan is intended to
| replace OpenGL.
| danielvaughn wrote:
| Thanks, yeah I'm tempted to just dive into the lowest level.
| My linear algebra is almost non-existent, so I feel like I
| should review my math fundamentals first. But I'm not sure
| how relevant it is to understanding the rendering pipeline
| itself, or if the math comes in at the applied layer.
| [deleted]
| Grum9 wrote:
| [dead]
| whstl wrote:
| Good answer. I would add that, despite all of them being low-
| level, Metal is quite easier than the other two, and DirectX
| 12 is also easier than Vulkan, despite having very similar
| concepts and ideas. This is in part due to API decisions and
| differences in verbosity, in part due to the "easier" ones
| having less flexibility. If your ultimate goal is to master
| Vulkan, starting with another can help. Also: OpenGL and
| DirectX are easier than those 3.
|
| If I were learning those APIs today, I would personally start
| with either OpenGL, Metal or DirectX 11 (or 12 if you're
| _slightly_ braver). They can give someone lots of insights
| that one can use when learning Vulkan.
|
| Like other people mentioned, WebGPU or WebGL are also more
| straightforward and a good starting point.
| drawkbox wrote:
| > WebGPU or WebGL are also more straightforward and a good
| starting point.
|
| WebGL and WebGPU also show some of the difference in how
| rendering libraries have evolved. They used to be all
| "stateful" global state like OpenGL/OpenGL ES. WebGL
| followed that model as it was simple and needed for the
| time, but could have bugs if correct flags weren't set.
|
| WebGPU and other newer rendering libraries (Vulkan, Metal,
| and Direct3D 12) are more "modern" in that they have almost
| no global state. They are also more raw and lower level and
| take a bit more to grok.
|
| This is one of the best overviews of the differences
| between WebGL/WebGPU but also is similar to how OpenGL to
| Vulkan, Metal, and Direct3D 12 evolved.
|
| https://webgpufundamentals.org/webgpu/lessons/webgpu-from-
| we...
|
| > The biggest difference is WebGL is a stateful API and
| WebGPU is not. By that I mean in WebGL there is a bunch of
| global state. Which textures are currently bound, which
| buffers are currently bound, what the current program is,
| what the blending, depth, and stencil settings are. You set
| those states by calling various API functions like
| `gl.bindBuffer`, `gl.enable`, `gl.blendFunc`, etc..., and
| they stay what you set them globally until you change them
| to something else.
|
| > By contrast, In WebGPU there is almost no global state.
| Instead, there are the concepts of a pipeline or render
| pipeline and a render pass which together effectively
| contain most of the state that was global in WebGL. Which
| textures, which attributes, which buffers, and all the
| various other settings. Any settings you don't set have
| default values. You can't modify a pipeline. Instead, you
| create them and after that they are immutable. If you want
| different settings you need to create another pipeline.
| render passes do have some state, but that state is local
| to the render pass.
|
| > The second-biggest difference is that WebGPU is lower
| level than WebGL. In WebGL many things connect by names.
| For example, you declare a uniform in GLSL and you look up
| its location
|
| > `loc = gl.getUniformLocation(program, 'nameOfUniform')`;
|
| > Another example is varyings, in a vertex shader you use
| `varying vec2 v_texcoord` or `out vec2 v_texcoord` and in
| the fragment shader you declare the corresponding varying
| naming it `v_texcoord`. The good part of this is if you
| mistype the name you'll get an error.
|
| > WebGPU, on the other hand, everything is entirely
| connected by index or byte offset. You don't create
| individual uniforms like WebGL, instead you declare uniform
| blocks (a structure that declares your uniforms). It's then
| up to you to make sure you manually organize the data you
| pass to the shader to match that structure.
|
| > Note: WebGL2 has the same concept, known as Uniform
| Blocks, but WebGL2 also had the concept of uniforms by
| name. And, even though individual fields in a WebGL2
| Uniform Block needed to be set via byte offsets, (a) you
| could query WebGL2 for those offsets and (b) you could
| still look up the block locations themselves by name.
|
| > In WebGPU on the other hand EVERYTHING is by byte offset
| or index (often called 'location') and there is no API to
| query them. That means it's entirely up to you to keep
| those locations in sync and to manually compute byte
| offsets.
|
| For a time, supporting four rendering engines did cause
| lots of work for game engines, much more integration and
| abstraction.
|
| As OpenGL support fades at least one will drop off. I will
| miss it as I do still love OpenGL/WebGL. OpenGL and OpenGL
| ES / WebGL in particular opened up mobile/web gaming in
| ways never before possible. Prior to that you had Director
| (3D), Flash (Papervision/Away3D/etc), Silverlight and more
| recently `<canvas>`. Canvas is great for smaller games but
| you need raw power for rendering 3d and WebGL (almost a
| direct port of OpenGL ES) brought that and engines like
| three.js use that well. Mobile gaming became the biggest
| gaming market due to OpenGL ES and web games took a leap on
| WebGL, also apps, interactives and tools became faster
| rendered.
|
| With GL, in many cases the global state is more simple, but
| to take advantage of GPUs and rendering lower level the
| innovations were needed. The naming to index/position based
| for instance is lower level and can also end up in bugs
| just as the global state in GL could. The benefit is
| performance and cleaner global state.
|
| It is probably a good idea to learn OpenGL/WebGL as some of
| the concept in WebGPU/newer engines will be more clear,
| much of it was simpler with naming.
| alexarnesen wrote:
| If you are looking to dig into Metal, this site and book
| might be useful. I have no graphics background and found it
| accessible.
|
| Metal By Example https://metalbyexample.com/
| WCSTombs wrote:
| Of those three, Vulkan is the only one that is cross
| platform, and the only one that natively targets Linux.
| flohofwoe wrote:
| The big advantage of not using OpenGL is that D3D11, D3D12
| and Metal all have excellent validation layers which tell
| you exactly what's wrong when you mess something up. In
| OpenGL you're pretty much left alone, staring at that black
| screen.
|
| Xcode and Visual Studio also have builtin graphics
| debuggers for Metal and D3D11 (not sure if the VS debugger
| also supports D3D12 though).
| reactordev wrote:
| Because you forget to call glGetError and do the error
| check on your previous call. In a world where we are
| driven by exceptions, not excepting and requiring you to
| check is actually a good thing, you wouldn't want a
| shader Parma exception from panicking your game in the
| middle of a gun fight.
| cyber_kinetist wrote:
| I was one of the N people who decided to delve into Vulkan
| because of curiosity for low-level optimization... but
| hearing some news and rumors around the gamedev scene I
| wonder if I should have spent time elsewhere (like, studying
| CUDA instead). Note that I'm writing this as a hobbyist so if
| there are any professional folks feel free to comment on
| anything problematic...
|
| Currently Vulkan and DX12 seem to be in a state of turmoil.
| The main assumption with the two low-level APIs are that you
| need to have a fully specified static list of configuration
| options to send to the GPU when you send render commands (I'm
| essentially talking about the Pipeline State Object) - which
| will aid in optimization since there's not any dynamic state
| for the GPU driver to wrangle with. However, many devs in the
| game industry has tried making performant renderers with this
| model and not many have succeeded, because if you see actual
| GPU usage patterns in game engines they do need some of the
| flexibility previously had in DX11 / OpenGL. Without this
| dynamism, as a rendering engineer you essentially need to do
| one of the two:
|
| - Pre-build all combinations of PSOs to implement your shader
| effects (if you have three different options for your
| rendering with A, B, C possible states each then you need to
| prebuild all A * B * C combinations of PSOs)... which will
| become ridiculous later on.
|
| - Create an automatic caching system that caches PSOs, so
| that the initial pipeline compilation will introduce some lag
| but later cached usage of the same PSOs will be fast. Now you
| have a much worse version of what DX11 / OpenGL was already
| doing behind the scenes... (unless you git gud and surpass
| the abilities of NVIDIA driver developers)
|
| With this in mind and also the various difficulties with
| managing the complexity of the new APIs (such as
| synchronization)... the reality is that a DX11 backend will
| probably be more performant than a naively written DX12 /
| Vulkan engine, since it's really just hard to beat NVIDIA's
| ridiculously optimized DX11 drivers that they have spent
| ridiculous amounts of time and money on. Unless you have a
| world-class team like Unreal or the ID tech folks... it seems
| like a gargantuan task to do. (Even Unreal Engine 5 had
| problems with heavy stuttering that are now fixed... and I
| suspect the issues were with how DX12 / Vulkan works)
|
| Nowadays the problem seems to be widely known in the
| industry, up to the point that both DX12 and Vulkan have
| introduced experimental extensions which provide alternatives
| to the PSO model:
|
| - The initial attempt is Vulkan's VK_EXT_shader_object
| extension (basically "Vulkan without Pipelines":
| https://www.khronos.org/blog/you-can-use-vulkan-without-
| pipe...) - which overhauls the API by introducing shader
| objects that you can dynamically link at runtime. Basically
| somewhere in the middle of DX11/OpenGL and DX12: give back
| some dynamism to the API, but not up to the point where the
| driver struggles to maintain performance because of it.
|
| - Other attempts seem to resemble more closely towards Render
| Graphs, which was a strategy that various game engines have
| already implemented on top of DX12 / Vulkan / console APIs.
| (See https://logins.github.io/graphics/2021/05/31/RenderGraph
| s.ht... for a introduction). For example, DX12's Work Graph
| API as preview
| (https://devblogs.microsoft.com/directx/d3d12-work-graphs-
| pre...), or Vulkan's VK_AMDX_shader_enqueue extension
| (https://gpuopen.com/gpu-work-graphs-in-vulkan/)
|
| But nonetheless, I think I should just wait touching these
| APIs until things have sorted out between GPU manufacturers
| and engine developers. (If I would start making a game engine
| from scratch for my indie game I would probably just use
| DX11.)
| sylware wrote:
| dota2 and cs2 do not even have an opengl backend anymore.
|
| On my side, I am waiting valve to trash their 32bits legacy
| code and get a clean vulkan->CPU fallbacked steam client
| (discovered you cannot libdl libGL because of that pesky ELF
| static_tls flag). I'll get some old games running with
| XWayland(maybe, and I would need a drm/vulkan|cpu
| implementation), and my own wayland drm/vulkan(or CPU)
| compositor.
| Permik wrote:
| Have you tried running Mesa's lavapipe? It's a software
| vulkan backend that should already be able to fit your
| needs if I understood you correctly.
| SotCodeLaureate wrote:
| > you cannot libdl libGL
|
| Hm, I'm doing just this all the time, on Linux and *BSDs
| (see my profile for example) and it seems it just works...
| So, I guess - what I'm doing _wrong_ then?
| jchw wrote:
| Vulkan is positioned to replace OpenGL, but possibly
| OpenCL/CUDA, vaapi/video acceleration libraries, and probably
| more. So honestly, it's sort of understandable why things get
| confusing here. It's quite abstract as well as sprawling in
| scope.
___________________________________________________________________
(page generated 2023-10-11 16:00 UTC)