[HN Gopher] I learned Vulkan and wrote a small game engine with it
___________________________________________________________________
I learned Vulkan and wrote a small game engine with it
Author : eliasdaler
Score : 355 points
Date : 2024-06-06 10:24 UTC (12 hours ago)
(HTM) web link (edw.is)
(TXT) w3m dump (edw.is)
| edu wrote:
| The site seems hugged to death, cached:
| https://web.archive.org/web/20240606103630/https://edw.is/le...
| eliasdaler wrote:
| Thank you! Also, everything explained in the article is pretty
| much here: https://github.com/eliasdaler/edbr
| archermarks wrote:
| Really nice article! I have some OpenGL familiarity and tried out
| Vulkan but bounced off of it due to all of the up-front
| complexity just getting something running. Might give it another
| shot now!
| eliasdaler wrote:
| Thank you. The up-front complexity is still there and it might
| take quite a few days to see your first triangle. But I
| promise, everything will get much easier from that point. :)
| mort96 wrote:
| The thing I'm most interested in doing when starting a new
| project is pretty much never to spend a few weeks and writing
| 10-20k LOC to get a triangle on the screen, I think I'll
| stick with OpenGL for the time being tbh
| jsheard wrote:
| It's not quite as bad as it used to be, various later additions
| to Vulkan like dynamic rendering have eliminated some of the
| complexity it originally had. Figuring out which subset you
| should be using is a challenge in itself though, especially
| since there's a lot of outdated introductory resources floating
| around which still promote the ultra-verbose Vulkan 1.0 way of
| doing things. If a tutorial tells you to use render passes, run
| away.
| galangalalgol wrote:
| Interesting, for a while the guidance for a while was to
| learn webgpu instead unless you needed all that extra
| control. Do you think these changes modify that guidance?
| jsheard wrote:
| WebGPU (or Metal if you're in Apple land) still has a much
| gentler learning curve. The simplifications to Vulkan
| weren't really aimed at making it easier to use, just
| streamlining parts of the API which turned out to be
| needlessly complex, so the parts that are complex for a
| reason are still just as complex.
| galangalalgol wrote:
| Thanks! Other than a project not running as fast as
| necessary, do you have any advice on how to know when/if
| I need to switch to vulkan?
| jsheard wrote:
| Aside from performance there's also just more hardware
| features exposed via Vulkan, as a sibling mentioned if
| you want to do anything with raytracing for example then
| you will have to graduate to Vulkan in order to take
| advantage of hardware acceleration.
| exDM69 wrote:
| With WebGPU/wgpu you don't get mesh shaders, ray tracing or
| shader subgroup/wave/warp operations. Its feature set is
| comparable to Vulkan 1.0, and Vulkan has progressed a lot
| since.
|
| And WebGPU still requires all the RenderPass setup code
| which is a lot of boilerplate that Vulkan no longer
| requires.
| jms55 wrote:
| Subgroups have actually been added very recently. The
| rest, sadly missing (along with multi-queue and bindless)
| :(
| bashmelek wrote:
| Do you have any recommendations for sources? I've used Vulkan
| Tutorial, which is a bit stale but I suppose still good for
| exposure. I've also used Vulkan Guide, before its latest
| overhaul. That one was educational. Not sure if I'll be able
| to do their new guide, my laptop can't run some of the more
| recent versions of Vulkan
| OnionBlender wrote:
| Khronos overhauled their docs last year. I've found the
| "Vulkan Guide" easier to read than the spec.
|
| https://docs.vulkan.org/guide/latest/index.html
|
| Not to be confused with the tutorial you're referring to.
|
| https://vkguide.dev
| BearOso wrote:
| Unfortunately, dynamic rendering didn't come about until
| "recently". Many devices are stuck on Vulkan 1.1. Go to
| http://vulkan.gpuinfo.org/listextensions.php and search for
| dynamic_rendering. It's only supported on about 28% of
| reports.
|
| If you want to support those other devices you have to have a
| non-dynamic rendering path, and then at that point dynamic
| rendering is just more code. VK_EXT_shader_object is even
| better, but availability is that much worse.
|
| _Edit_ : If you are able to find a tutorial using dynamic
| rendering, learn with that. Render passes obfuscate what's
| going on, and with dynamic rendering you can see exactly
| what's happening.
| jsheard wrote:
| You really have to think of Vulkan on PCs and Vulkan on
| mobile as separate things, if you only care about running
| on the former then you can easily count on things like
| dynamic rendering always being available as long as your
| users drivers are up to date. If you need to target Android
| though, my condolences.
| exDM69 wrote:
| > only supported on about 28% of reports.
|
| This information is misleading because it includes old
| reports from years ago, before this feature existed. It
| does NOT mean that 28% of devices out there have support.
| You will need Steam hardware survey results and cross
| reference gpuinfo.org or Android hardware survey results
| which directly list Vulkan versions.
|
| Dynamic rendering is available on all desktop GPUs (Intel,
| NV, AMD), on all desktop OSes (Windows, Macos, Linux) as
| long as you've got drivers that are up to date (no older
| than 2023).
|
| For mobile devices, the situation isn't as good. Updating
| mobile GPU drivers is an unsolved problem.
| BearOso wrote:
| I get your point. But you might be surprised how many PCs
| are still in use that have pre-Skylake Intel IGPs. Some
| people just don't update their drivers, either.
| exDM69 wrote:
| Pre-Skylake Intel never had proper Vulkan support (on
| Linux at least) so it's a non issue.
|
| I use a 2015 Skylake laptop for most of my graphics
| programming project and it's got full Vulkan 1.3 and wide
| set of features. The hardware doesn't do mesh shaders or
| Ray tracing but apart from that every new feature is
| available.
|
| Not updating drivers is a problem, especially on mobile.
| Thankfully auto updaters are very common these days.
| eliasdaler wrote:
| vkguide is a great way to get a feel of modern Vulkan. Maybe
| it'll be still to complex for you - then it's okay to say on
| OpenGL or learn some WebGPU.
|
| I started learning Vulkan as an experiment and it seemed to
| work out well, so that's why I wrote this article. :)
| spicyusername wrote:
| Lots of good advice in this article.
|
| One that stuck out to me: Don't implement something unless you
| need it right now
|
| This is a constant battle I fight with more junior programmers,
| who maybe have a few years of experience, but who are still
| getting there.
|
| They are often obsessed with "best-practices" and whatever fancy
| new tool is trending, but they have trouble starting with the
| problem they need to solve and focusing on the minimum needed to
| just solve that problem.
| Hendrikto wrote:
| > They are often obsessed with "best-practices"
|
| Tell them YAGNI is also a best practice :D
| fuzztester wrote:
| Yes. So is KISS.
|
| https://en.m.wikipedia.org/wiki/KISS_principle
| junon wrote:
| Yep. I attribute YAGNI to a lot of my quickest prototypes and
| some of my best code.
| Narhem wrote:
| Definitely agree.
|
| But there's a fine line between implementing things but the
| difficulty being understanding long term vision and making sure
| short term improvements don't actively work against the
| 'ideal'. Kind of hard for newer programmers to get a good sense
| of system design.
| xedrac wrote:
| Yes, over engineering solutions is a constant thorn in my side.
| The end result is you get a lot of additional complexity for
| basically no benefit. In my experience, if new requirements do
| come down the pipeline at some later time, the generic solution
| you previously built will be completely inadequate and will
| need to be redone anyway. Solve the problem in front of you,
| not some unknown future problem.
| outworlder wrote:
| The only thing I'll add is: do the simplest thing that can
| possibly work, but no simpler.
|
| Don't back yourself into a corner. If a solution will block
| you from doing the right thing later, maybe some additional
| engineering may be needed after all to ensure you can
| continue to iterate. In large companies, inertia is enormous.
| Once a solution is in place and gets replicated, backtracking
| may become a herculean task.
| cubefox wrote:
| On the other hand, often a "quick and dirty" solution
| unexpectedly becomes the foundation of a lot of other stuff,
| which can be a persistent pain in the future, while the cost
| of rewriting the whole thing increases the more other stuff
| depends on it.
|
| There are two poles: On the one side is making everything an
| unmaintainable pile of quick hacks, on the other side is over
| engineering everything. You want to be somewhere in the
| middle.
| sigseg1v wrote:
| Totally agree, it needs a careful balance. But is it
| possible to know when to use what?
|
| Anecdote: A couple years ago I migrated a 1M+ LOC
| application from one database to another, cutting the cloud
| hosting costs practically in half. This was absolutely
| massive for the company. It took a bit less than a year,
| but was possible because the people who designed the
| application didn't write any hardcoded queries, and
| everything went through an ORM or a query builder.
| Everything was built to an interface, even though they all
| only had one implementation. This turned out to be
| absolutely critical when we had to add the second
| implementation (and because we needed to maintain
| compatibility for the original implementation at the same
| time due to some one-off contracts) and the migration would
| not have been worth it cost-wise if the proper architecture
| wasn't in place from the start.
|
| Now take the same application. It has tons of complicated
| architecture stuff implemented in house. Parts of it are
| definitely overengineered. It's been apparent when doing
| other upgrades and finding out "oh... this doesn't work
| because it's using a custom JSON serializer" that the
| choice to do that was poor.
|
| In the end, I think the right choice for that application
| was the complex design that allowed those big migrations.
| For others, they might never do that and only get hit with
| downsides.
|
| What it needs is likely a good vision and someone smart to
| know what to abstract and what to not abstract such that it
| will have been a good choice 15 years down the road.
| dessimus wrote:
| > On the other hand, often a "quick and dirty" solution
| unexpectedly becomes the foundation of a lot of other stuff
|
| This is how Access "databases" and Excel spreadsheets often
| become mission-critical in SMBs. "We'll deal with needing a
| database server down the road..."
| stouset wrote:
| In my 25-year career I've experienced easily fifty times as
| much pain from underthought and hastily-implemented systems
| than I have from overengineered ones.
|
| Sure, build user-facing stuff cheaply and ready to be
| thrown away as requirements change. But libraries, tooling,
| and infrastructure that everything else is built on top of
| should have thought and care invested in it. This will
| return dividends.
|
| We spend so much time as an industry worried that somebody
| might put five percent more effort into a project than it's
| worth, that the overwhelming majority of engineers have no
| idea whatsoever of how to build something to be reliable,
| to be easily iterated on, and to last. And so we spend tens
| of times more effort trying to build on top of a mountain
| of crap.
| pxtail wrote:
| >starting with the problem they need to solve and focusing on
| the minimum needed to just solve that problem
|
| To be fair if held strictly to these principles their work
| would revolve mostly around gluing together various Apis,
| services and sometimes adjusting already written software to
| company's needs. So I'm not surprised they are using every
| possible opportunity to write something here and there, this
| menial digital plumber's work takes its toll and one needs to
| try to squeeze in something a bit more enjoyable from time to
| time just to keep sanity in place a bit longer
| SR2Z wrote:
| Yeah, I am no longer a junior engineer.
|
| When I WAS the bane of my existence was senior and staff
| engineers hoarding all the fun, new work for themselves and
| forcing me into "bitch work" where I'm just cleaning up old,
| broken code and handling bugs. I finally got promoted because
| I explicitly ignored my manager to deploy changes that were
| needed for my company, and that was what finally got me
| promoted. Of course, at that point, I had been looking for a
| new job and just left instead of taking the shitty, bottom-
| of-band promo increase.
|
| It's awful for promotion chances, and it forced me to quit.
| lpapez wrote:
| > When I WAS the bane of my existence was senior and staff
| engineers hoarding all the fun, new work for themselves and
| forcing me into "bitch work" where I'm just cleaning up
| old, broken code and handling bugs.
|
| Oh how I relate to this...
|
| That's why these days I go out of my way to "save"
| interesting work for my junior colleagues and have them
| grow through it.
| vlovich123 wrote:
| > Don't implement something unless you need it right now
|
| Useful advice to start with. It's a rule that experts are
| allowed to break though.
| jay-barronville wrote:
| > [Junior programmers] are often obsessed with "best-practices"
| and whatever fancy new tool is trending, but they have trouble
| starting with the problem they need to solve and focusing on
| the minimum needed to just solve that problem.
|
| I've observed/experienced the same exact thing [0]. I think
| it's due to a combo of (1) not knowing what "the right way" to
| do things are and (2) thinking it'll make your peers perceive
| you as more knowledgeable or advanced if they see you writing
| "best practices" code. Not to mention that sometimes the
| simpler solutions are so simple, they make you feel like you're
| not a real software engineer. I usually just do my best to help
| them understand that simple solutions are okay, especially
| since (1) I've been there myself when I was in their shoes and
| (2) I know they have good intentions.
|
| [0]: https://news.ycombinator.com/item?id=40527071
| proc0 wrote:
| This is in context of a one person team. The next advice makes
| this evident:
|
| > Remember that you can always rewrite any part of your
| game/engine later.
|
| This isn't the case in medium to large organizations. Usually
| you will just move on and rarely have the time to revisit
| something. This is unfortunate of course, but it means you need
| to build things properly the first time around and make sure it
| won't have a chance to create bugs or side effects. I have
| worked in too many codebases were people feel the need to rush
| new features, and then it creates a minefield of a codebase
| where you have to manually check every feature and have the
| entire application in context when changing something small.
| jshowa wrote:
| I agree with this. In a large organization, if you have risen
| to a level where you are being relied upon at a regular
| intervals, it is imperative that you have a well architected
| solution that you can readily change and this is where you
| separate your program from spaghetti code to something
| useful. Sure, its nice to write unmaintainable junk when
| toying around, but I to have seen too many codebases where
| people were just throwing features in without thought and it
| causes the program to become way too constrained to only a
| specific problem domain and it becomes inflexible for solving
| new problems (to the point you have to re-write nearly
| everything from scratch).
| jaggederest wrote:
| The contrast to this is to put in tickets specifically for
| refactoring and reorganization, but I've rarely seen that
| work since they often don't have any sweetener included to
| encourage e.g. product organization to sign off on the
| work.
| eliasdaler wrote:
| I agree. I should probably clarify that in the article. It's
| much easier to write "throwaway" code when you're working
| alone and when you're doing it just for fun. This advice was
| probably aimed at people who tend to overthink things in
| _these_ kinds of situations and spend years implementing
| things in the "right" way, which tends to slow them down
| considerably instead.
| stouset wrote:
| Most importantly, you need to get _interfaces_ right. The
| right interface that allows the caller to express their
| underlying intent allows you to rewrite bits of the
| implementation as-needed without forcing a rewrite from your
| downstream consumers.
| exe34 wrote:
| > it means you need to build things properly the first time
| around and make sure it won't have a chance to create bugs or
| side effects. I
|
| yes! and this means you need to know everything about what
| you're building upfront! so now you have to do waterfall, but
| hide all the actual effort and pretend you're just figuring
| it out in the moment because agile.
| proc0 wrote:
| I agree, and would add that agile is bad because it's used
| to iterate along the product vertical, so first create an
| MVP, then add features. Instead it could be used to iterate
| from a technical standpoint, first adding the helper
| functions, then the interfaces, then some of the core
| functionality.. but the problem there is that most orgs
| prefer immediate "business value" at the cost of long term
| good engineering. In some cases, when the application is
| meant to be short-lived this makes sense, but more often
| than not I've seen teams suffer from this approach, not
| realizing they have been digging their own hole for years.
| exe34 wrote:
| > so first create an MVP, then add features.
|
| It seems to guarantee technical debt starts to build as
| soon as possible and as fast as possible!
|
| (I.e. I'm referring to agile as it is practised, not the
| true scotsman's agile. We apply the same rigour towards
| socialism.)
| jokoon wrote:
| I think vulkan is great, but its only purpose is to take full
| advantage of advanced GPU features. It also leads to better
| performance when using advanced GPU features compared to OpenGL.
|
| Generally, I feel OpenGL is the recommended route if you don't
| really aim for advanced rendering techniques.
|
| There are plenty 2D /lowpoly/ps1-graphics games right now, and
| those don't need to use vulkan.
|
| Vulkan is an example of how the AAA gaming industry is skewed
| towards rendering quality and appearance. AAA game studios
| justify their budget with those very advanced engines and
| content, but there is a growing market of 2D/low poly game,
| because players are tired and realized they want gameplay, not
| graphics.
|
| Also if you are a game developer, you don't want to focus on
| rendering quality, you want to focus on gameplay and features.
| ChadNauseam wrote:
| A middle ground is webgpu. It is much less verbose than Vulkan
| and is guaranteed to run anywhere, including the browser. At
| the same time, it has access to "modern" features like compute
| shaders which would not be available in webgl. It also doesn't
| have much legacy cruft leading to multiple ways of doing the
| same thing, unlike opengl. The main advantage is that it's new,
| so there are many fewer tutorials available for it, and that is
| a very serious disadvantage.
| alexvitkov wrote:
| It's a JavaScript API, it only runs in the browser. It's not
| real.
| ncallaway wrote:
| That's just not true. https://wgpu.rs/
|
| I'm literally writing native code running on linux with
| winit and wgpu right now.
| solardev wrote:
| Wait, is that the same as using WebGPU? It says outside
| of browsers it uses opengl and vulkan and directx.
| ncallaway wrote:
| Yea, wgpu is basically an adapting layer between the
| WebGPU API and opengl, vulkan, directx. So it's the same+
| API.
|
| But WebGPU in the browser is _also_ an adapting layer
| between those technologies, it 's just the browser that
| does the adapting instead of the wgpu library. For
| Firefox, WebGPU is adapted to those underlying systems
| _by_ wgpu:
| https://github.com/gpuweb/gpuweb/wiki/Implementation-
| Status
|
| + There are some "native-only" extensions beyond the
| WebGPU spec that gpu provides, so it does go a little
| beyond WebGPU. But for the most part, it's very similar.
| solardev wrote:
| Wait... so if webgpu (the API) is to allow browsers to
| use the underlying graphics libs... but desktop apps can
| access those directly... why would they want to go
| through the browser abstraction API instead? Better dev
| ex and ergonomics?
| ncallaway wrote:
| > why would they want to go through the browser
| abstraction API instead? Better dev ex and ergonomics?
|
| That and portability. The ergonomics are always up for
| debate, but I find it a much more modern and nicer
| interface than OpenGL which feels...quite dated. How it
| compares to something like Vulkan or Metal is up for
| debate.
|
| But for portability if I write my code using directx,
| then I can only run it on systems with directx. If I
| write it for vulkan, I can only target systems with
| vulkan. If I write for metal, I can only target systems
| with metal.
|
| However, if I use wgpu and the WebGPU API, I can target
| _any_ system that has directx _or_ vulkan _or_ metal _or_
| OpenGL. I can also target wasm and compile my application
| for the web.
|
| So, I can really easily write code that will run natively
| on linux, on osx, on windows and the web and will use the
| graphics library native to that platform.
| solardev wrote:
| I see now. Thanks for explaining! That makes a lot of
| sense.
| alexvitkov wrote:
| wgpu is not WebGPU. One is a Web specification, the other
| is a Rust library.
|
| wgpu is also not a graphics API, it's a library that
| abstracts the underlying graphics API.
| solardev wrote:
| Even more confused now, lol.
|
| (edit: thanks for editing your post. the revised version
| clears it up!)
| alexvitkov wrote:
| Vulkan, Direct3D, Metal and OpenGL are graphics APIs -
| the implementation comes with your GPU driver, and
| they're as close as you can reasonably get to writing
| code "directly for the GPU". When you call a Vulkan
| function you're directly calling driver code.
|
| wgpu is a regular library that uses the native APIs above
| and abstracts them from you. I don't like calling it a
| graphics API because it implies it's the same as the
| vendor-provided APIs - it's a completely different beast.
|
| WebGPU and WebGL are Web standards that the browser
| implements, and you program them via JS. Similarly to
| wgpu, they're implemented on top of the native graphics
| APIs.
|
| The relationship between wgpu and WebGPU is that they're
| basically made by the same people, and in Firefox WebGPU
| is implemented on top of wgpu.
|
| But saying "WebGPU runs everywhere" is plain wrong - it's
| a browser-exclusive API, and on top of that, at the point
| of writing this it doesn't even run on all browsers (71%
| support according to https://caniuse.com/webgpu)
| cubefox wrote:
| But clearly libraries like wgpu implement WebGPU while
| not requiring a browser. So WebGPU is not browser-
| exclusive.
| solardev wrote:
| I thought its browser support was pretty bad?
| https://caniuse.com/webgpu
|
| Firefox and Safari don't support it yet. And how would you
| even deploy it to Steam (edit: or rather, make a desktop or
| mobile game with it)? Can you wrap it in a webview?
|
| Doesn't seem mature...
| bla3 wrote:
| There is a native API too, not just JS. You can link it
| into your game like any other library.
| solardev wrote:
| I'm confused now. I thought by definition it's a browser
| API that allows them to make Vulkan/OpenGL/DirectX calls,
| like an abstraction layer. Am I wrong?
|
| Edit: wgpu is a reimplementation of the WebGPU api for
| use with desktop apps outside of browsers. See sibling
| thread by another poster for an explanation:
| https://news.ycombinator.com/item?id=40598416
| MindSpunk wrote:
| wgpu isn't a reimplementation of WebGPU, it's Firefox's
| WebGPU implementation. It also conveniently runs outside
| of a browser and is accessible with a Rust or C API. You
| can also do the same thing with Dawn, which is Chrome's
| implementation of WebGPU.
| solardev wrote:
| Thanks for the correction!
| hgs3 wrote:
| Not to downplay it or anything, but I'm curious why webgpu is
| receiving so much attention? There have been many low-level
| cross-platform graphics abstractions over the years. The bgfx
| [1] project had its first commit ~12 years ago and it's still
| going! It's much more mature than webgpu. I'm guessing being
| W3C backed is what's propelling it?
|
| [1] https://github.com/bkaradzic/bgfx
| troupo wrote:
| webgpu is a modern graphics API for modern GPUs to
| replace/complement these two APIs in the browser: WebGL (a
| very limited outdated subset of OpenGL) and Canvas
| (basically WinAPI drawing from 2000s)
|
| It's heavily influenced by Metal (based on original work by
| Apple and Mozilla).
|
| People are talking about it because it's on the web and
| it's finally something modern to work with.
| GuB-42 wrote:
| The general idea is that if you care more about gameplay and
| features, use an existing engine, the engine itself takes
| advantage of Vulkan, or whatever backend is the most
| appropriate, so you don't have to.
|
| OpenGL is kind of a middle ground. That's if you want to get
| technical, but not micromanage every detail and write pages of
| boilerplate. It is also a great introduction to graphics
| programming. More than an introduction actually, there is a lot
| you can do with OpenGL.
| MajimasEyepatch wrote:
| > Vulkan is an example of how the AAA gaming industry is skewed
| towards rendering quality and appearance. AAA game studios
| justify their budget with those very advanced engines and
| content, but there is a growing market of 2D/low poly game,
| because players are tired and realized they want gameplay, not
| graphics.
|
| I think the driver here is more likely the financial reality of
| game development. High-fidelity graphics are incredibly
| expensive, and small game studios simply cannot produce them on
| a realistic timeline and budget. Would consumers reject indie
| games with AAA-quality graphics? I think not. It's just that
| few such games exist because it's not financially viable, and
| there is a large enough market that is fine with more stylized,
| lower-fidelity graphics.
| jokoon wrote:
| Yes, I agree.
|
| With current hardware and tools, it becomes much cheaper to
| reach graphics quality that is 10 or 15 years old, so such
| game would be just enough and be profitable enough.
|
| I think that high quality rendering is reaching a tipping
| point where it's mostly of diminishing returns, this means
| AAA studios could differentiate with good graphics, but this
| becomes less and less true.
|
| Gameplay matters, and the innovation is not the on the side
| of AAA studios.
| alexvitkov wrote:
| Vulkan has advantages over OpenGL even if you don't care about
| visual fidelity.
|
| - No global state
|
| - You can select which GPU you want to use at runtime
|
| - OpenGL error handling is terrible
|
| - Validation layers!!
|
| - Cool official artwork
|
| - Fantastic documentation
|
| - You can upload data to the GPU asynchronously from a second
| thread in a sane way
|
| - Fancy GPU features - Mesh shaders, RTX
| hjadal wrote:
| I will say that validation layers alone are worth it. Damn
| they are nice, so many bugs in my code has been found by them
| which saved a lot of time.
| rrradical wrote:
| I switched from opengl b/c I was tired of staring at a
| black screen with no debugging information
| (sure...glGetError) when I tried to implement a non-trivial
| feature. After tons of work to learn vulkan and getting it
| up and running, I still think it was worth it.
| eliasdaler wrote:
| Agreed. I don't even need all these fancy Vulkan features
| most of the time... Just validation layers and RenderDoc
| debugging make the whole experience of doing graphics
| programming so much more pleasant for me, compared to what
| I had to deal with in OpenGL.
| samuellavoie90 wrote:
| It's not just about performance, I think one of the reasons for
| moving away from OpenGL is that the High level functions are
| inconsistent across driver implementations/GPUs. Whats the
| point of an abstraction layer if you keep having to write
| GPU/driver specific code. Its better to have a low level driver
| and a high level library instead.
| Const-me wrote:
| Another good option is Direct3D 11. It's IMO even easier to use
| than OpenGL but still allows to implement pretty good visuals,
| see GTA 5 or Baldur's Gate 3.
| mort96 wrote:
| Eh that's really only an option if you want to only ever
| target Microsoft platforms. Which is fine for _some_ people,
| sure, but in a lot of situations, closing the door on Linux
| (Steam Deck), macOS, iOS, Android and the non-xbox consoles
| is a tough sell.
| MindSpunk wrote:
| Linux you can get for "free" with DXVK or VKD3D-proton.
| MacOS is an even more niche platform than Linux as far as
| gaming is concerned and is not a tough sell to skip
| considering the total lack of market share in games. iOS
| and Android generally come in a pair so unless you're only
| targeting one you need to support multiple APIs anyway.
| Xbox requires Xbox specific APIs so you need explicit work
| there. Every other console uses a bespoke API that will
| require another backend in your engine (yes Switch
| technically supports Vulkan but that is not the recommended
| path from Nintendo, you will likely end up with an NVN
| backend).
|
| D3D11 gives you both desktop platforms that matter for
| games, everything else will require multiple backends
| anyway so if you only care about desktop it's a fair
| choice.
| debugnik wrote:
| Since DXVK exists and Apple dropped OpenGL, the latter
| gains you access to Android and that's about it, unless
| you're ok with ES 3.0 contexts and a lackluster set of
| extensions (ANGLE on Metal).
|
| AFAIK the non-Xbox consoles either don't support OpenGL or
| we reportedly don't want to use their implementations.
| Keyframe wrote:
| I think Vulkan was a mistake. Maybe I should say OpenGL Next
| should've been a (priority) thing and Vulkan could still happen
| on the side.. and not this, push towards everything Vulkan.
| It's not for everybody and not everybody needs it (nor deserves
| it).
| cogman10 wrote:
| I don't think it's a mistake, I think it's targeted and
| leveraged poorly.
|
| Vulkan is a great idea for a general game engine or backing
| something like OpenGL. It's a low-level abstraction that
| should allow you to do something like use OpenGL 8.0 on a GPU
| that has long lost support for from its manufacturer.
| jms55 wrote:
| Exactly this. Vulkan, especially Vulkan 1.0, was never
| really meant directly for graphics developers. It was meant
| specifically for engine developers that didn't want to have
| to deal with buggy and inconsistent drivers, e.g. Nvidia vs
| AMD vs crappy Android phones.
|
| The solution Vulkan came up with was "make everything as
| explicit and user-controlled as possible", and leave
| "implementing a more user friendly driver" up to user-
| space, so that it could be tweaked by users, wouldn't be
| tied to driver updates users would never do, would be
| consistent across platforms, etc.
|
| Except that never really happened. There are some graphics-
| driver-as-a-library projects (daxa, nabla, etc), but none
| with a large amount of community support.
|
| Meanwhile GPU's evolved over time (AMD RDNA1, Nvidia
| Turing, Intel Arc, Apple Silicon), and it turns out that
| some of the choices Vulkan 1.0 bet on weren't great
| (explicit extensive pipeline state, binding model, render
| passes).
|
| Vulkan 1.2/1.3 cleaned up a lot of this (dynamic state,
| descriptor indexing, sync v2), which also happens to
| improve ergonomics a lot to the point that it's much less
| painful to use Vulkan directly nowadays, as long as you're
| ok dropping support for older platforms.
| eliasdaler wrote:
| I can somewhat agree... I don't dislike/fear Vulkan now, but
| I feel like there should have been something in-between
| OpenGL and Vulkan, because in most cases you don't need the
| same level control over the GPU which AAA game require.
| Thankfully, libraries like VMA and vk-bootstrap + new
| extensions like dynamic rendering make Vulkan start to
| resemble what "OpenGL Next" could have been. It's still not
| perfect, but I'm glad that things have moved into that
| direction.
| alunchbox wrote:
| hey just curious, any reason why some of these articles I see
| from time to time don't apply some simply CSS? I don't mind the
| raw html, I'm mostly wondering if there's some benefit to it that
| I might not be aware of.
| PhilipRoman wrote:
| The site definitely has CSS, just not a lot of it.
| eliasdaler wrote:
| Indeed. I used as little CSS as I could because I love
| minimalist websites. And the lack of syntax highlighting was
| inspired by Go blog, for example. :)
|
| Raw HTML definitely looks much uglier, sadly ("Reader mode"
| in most browsers makes websites without CSS easily readable,
| though!).
| cristoperb wrote:
| Your site looks nice and is quite readable! The thing I
| most dislike about sites that just use raw HTML is the lack
| of `max-width` on the text containers (which makes using
| reader mode necessary), so thanks for including that
| eliasdaler wrote:
| Thank you! :)
| solardev wrote:
| Just a guess, but the folks interested in low level graphics
| programming are probably the same people who would want to stay
| away from bloated frontends?
|
| A simple blog post doesn't need super fancy design when its
| content can speak for itself.
| rossant wrote:
| Great writeup! I learned Vulkan myself so that I could write a
| scientific data visualization engine (https://datoviz.org/ still
| quite experimental, will release a newer version soon). I had
| some knowledge of OpenGL before and learning Vulkan was SO hard.
| The learning resources weren't that great 5 years ago. I took up
| the challenge and it was so much fun. It took me months to
| understand the role of the various dozens of abstractions. In the
| process I wrote a small wrapper around Vulkan
| (https://datoviz.org/api/vklite/) to make it a bit less painful
| to work with (it supports a subset of the features, those that
| are the most required for scientific visualization purposes).
| atan2 wrote:
| Great read! Elias always does great work.
| samiv wrote:
| This might come off as a surprise to some people but getting good
| performance with Vulkan (compared to say OpenGL) isn't trivial
| because:
|
| the Vulkan driver is missing that ~20k loc of code that OpenGL
| driver does for you to set up the rendering pipelines, render
| targets etc.
|
| This is all code that already exists in the OpenGL driver and has
| been optimized for +20 years by the best people in the industry.
|
| So when you start putting together the equivalent functionality
| that you get out of the box with OpenGL on top of Vulkan doing it
| the naive way doesn't magically give you good perf, but you gotta
| put in some more work and then the real problems start stacking
| up such as making sure that you have all right fences etc
| synchronization primitives in place and so forth.
|
| So only when you actually know what you're doing and you're
| capable of executing your rendering with good parallelism and
| correct synchronization can you start dreaming about the
| performance benefits of using Vulkan.
|
| So for a hobbyist like myself.. I'm using OpenGL ES3 for the
| simplicity of it and because it's already good enough for me and
| I have more pressing things to matter than spend time writing
| those pesky Vulkan vertex descriptor descriptor descriptors ;-)
|
| Btw this is my engine:
|
| https://github.com/ensisoft/detonator
| harrison_clarke wrote:
| the biggest part for me is the shader compiler. opengl has one
| built in, vulkan requires me to pull in yet another dependency
|
| i've heard that vulkan allows bindless textures now, so the
| descriptor nonsense is a bit less awful that it used to be
|
| vulkan is appealing, but there's a high initial cost that i
| don't want to pay
| sigmoid10 wrote:
| Vulkan is super appealing if you're in the industry and have
| the time and resources necessary to profit from its
| advantages. But if you're a single dev who wants to learn
| game engine design, you're going to have a bad time. Most
| people also don't get that game engine design is very far
| removed from actual game design. You can have a ton of fun
| learning math, physics and computer science when building an
| engine, but beware that you'll likely be mentally and
| physically exhausted long before you actually get to build a
| fun _game_.
| harrison_clarke wrote:
| vulkan doesn't have global state, and the error handling is
| better
|
| but it's not batteries-included, and that's often to be a
| deciding factor at small scales
|
| i think if you're going to dabble in engine dev, you pick
| which one you want depending on which part of the engine
| you find interesting. if you want to make a game, you pick
| up unity or godot or something
| kiririn wrote:
| Also in the case of glslang there are enough references to
| GPL to (probably erroneously) strike fear into legal
| departments
| OnionBlender wrote:
| I've heard the same thing about DirectX 12 vs DirectX 11. One
| book basically said that you will probably have worse
| performance in DirectX 12 vs DirectX 11 if you don't know what
| you're doing.
| sigmoid10 wrote:
| DirectX 12 only gets interesting when you want hardware
| raytracing support to make use of the new Nvidia cards on
| windows. Tbf that is pretty cool, which is why I actually
| dabbled with it a little. But it's not necessary for the
| vast, vast majority of graphics applications.
| dc443 wrote:
| I wonder how much less ergonomic is is for getting there
| via Vulkan. For the ray tracing shaders.
| fire_lake wrote:
| Could someone write an OpenGL to Vulkan layer as a library so
| that we can target Vulkan but at a higher level of abstraction?
|
| Then gradually we can replace that library with routines
| optimised for the use case?
| cluoma wrote:
| There is the Zink project[1]. It is an OGL to Vulkan
| translation layer.
|
| [1]https://docs.mesa3d.org/drivers/zink.html
| sehugg wrote:
| ANGLE is the (certified compliant) OpenGL ES ->
| Vulkan/Metal/Direct3D/etc translation layer used by your
| friendly neighborhood web browser. There are docs about how
| the Vulkan translation layer works: https://chromium.googleso
| urce.com/angle/angle/+/HEAD/src/lib...
| OnionBlender wrote:
| I've been trying to learn Vulkan on and off for years (I used to
| know OpenGL ES 2&3 pretty well).
|
| One thing I found difficult is understanding how to use things in
| a real engine rather than a sample. A lot of samples will
| allocate exactly what they need or allocate hundreds of something
| so that they're unlikely to run out. When I was trying to learn
| DirectX, I found Microsoft's MiniEngine helpful because it wasn't
| overly complex but had things like a DescriptorAllocator that
| would manage allocating descriptors. Is there something similar
| for Vulkan?
|
| Another thing I struggle with is knowing how to create good
| abstractions like materials, meshes, and how to decide in what
| order to render things. Are there any good engines or frameworks
| I should study in order to move beyond tutorials?
| cmovq wrote:
| Take a look at a real engine, something like vkquake is a good
| reference [1].
|
| [1]: https://github.com/Novum/vkQuake
| gmueckl wrote:
| Vulkan is quite similar DirectX 12. Done concepts transfer
| directly. For memory allocation, you can use a library called
| vma to assst you. It takes care of a few stupid edge cases that
| the Standard accunulated over the years and is quite powerful.
|
| For descriptor set allocation, there is only one pattern that
| nakes sense to me: expect the pools to be rather short lived
| and expect to have many of them. Allocate a new one once
| allocation from the current one fails - don't keep your own
| counters for alocated descriptors. The standard allows for all
| kinds of pool behaviors that deviate from strict counting.
| Discard old pools after the the last command buffer referencing
| that pool is finished.
|
| Pipeline barriers and image layouts are a big pain in the butt.
| It makes sense to abstract them away in a layer that tracks
| last usage and lat Format for everything and adds barriers as
| required. It can get complex, but ot's worthbitnonce you have
| optional passen or passes that can get reordered or other more
| complex things going on.
|
| About neshes, materials, rendering order: this goes beyond what
| I can summarize in a single HN post. This depends a lot on the
| choice of rendering algorithms and I do not consider a very
| generalized solution to be worth the (enormous) effortto get
| this right.
| andrewmcwatters wrote:
| For the casual reader who is curious what it takes to write a
| "Hello, Triangle!" in Vulkan 1.3:
| https://github.com/Planimeter/game-engine-3d/blob/main/src/g...
| ku1ik wrote:
| /o\
| eliasdaler wrote:
| Indeed. vk-bootstrap is a bit better with 600 lines of code,
| though: https://github.com/charles-lunarg/vk-
| bootstrap/blob/main/exa...
|
| Vulkan initialization and basic swapchain management is very
| verbose, but things get much better after you do it for the
| first time and make some handy abstractions around pipeline
| creation/management later.
| andrewmcwatters wrote:
| For sure. They just move the roughly 300 lines of code
| elsewhere so you don't have to do it, though.
|
| I'd like to see them move nearly all 900-ish lines of SLOC
| back down into the near 90-ish you'd need to initialize
| OpenGL.
|
| There's so much overlap in basically everyone's graphic usage
| of Vulkan that you realize after doing it yourself they
| should have done some simple optimization for the 99% use
| case, and allowed other people to write the full 900+ lines
| for GPU compute or other use cases.
| eliasdaler wrote:
| I guess libraries like bgfx, sokol and The Forge are kinda
| like that. But I just feel like it's either all or nothing
| if you're already doing your own game engine.
|
| I'm okay with using middleware/3rd party libraries for
| things which I don't care too much about (e.g. physics),
| but graphics is such a core component that I want to handle
| it myself.
|
| In a way, OpenGL drivers were such middleware libraries
| written for you by GPU vendors (or open source community).
| But now they stopped doing that and now you're either
| writing your own graphics abstraction layer or using
| someone else's.
|
| In this case, I choose the hard way. And it seemed to have
| worked out so far. I definitely won't recommend it to
| everyone (especially if they want to make a game in less
| than a year!), but as a learning experience it was fun.
| wudangmonk wrote:
| Its great to have more Vulkan resources but unfortunately this
| one too suffers from the same problem as every other resource
| I've found on getting something on the screen with Vulkan.
|
| They all introduce another layer of abstraction on top of Vulkan
| even before giving you the simple case without it. Its always use
| vk-bootstrap, volk, vma or someother library.
|
| Is there a single resource anywhere that gives an example of
| doing the memory management manually because I havent found one,
| it seems like its either use vma or go figure out the spec are
| the only choices you are given. Is it too much to ask to just get
| the most basic example without having to add any libraries other
| than the Vulkan sdk itself?.
| harrison_clarke wrote:
| there's a common gamedev practice of allocating a big chunk of
| memory up front, and then using a bump allocator inside of it
|
| in most games, there are about 3 "lifetimes": -
| permanent/startup - per-level - per-frame
|
| and they're nested. so, you can use a single stack allocator
| for all of them. at the end of the frame/level, pop back to
| where it started
|
| there are more complicated patterns, but this one will get you
| pretty far. you can use it on the CPU and the GPU
| andrewmcwatters wrote:
| Yes. It's too much to ask. Even the "official" examples by
| documentation do not do it. Reading the Vulkan specifications
| is an exercise in practicing technical bullshit.
|
| When you're corroborating some random person's third-party
| instructions on initializing Vulkan and comparing those notes
| to what's done in Khronos Group repositories and reading the
| Vulkan 1.3 spec and realizing you have to read the
| specification out-of-order to get anything done, it's clear
| that they failed.
|
| They failed. It's bad work by any other standard. But you'll do
| the work once and forget about it for the most part, so
| professionals don't complain too much.
|
| Read my other comment in this thread for a portion of source
| code annotated with the specification chapters and sections.
|
| It's a generic implementation that can be used with SDL and
| others.
|
| Edit: As of the time of writing, the standard approach is to
| use VMA and Volk, both of which are included with the official
| Vulkan SDK. That should tell you enough about the state of the
| art.
| izacus wrote:
| Vulkan was always designed to be extremely low level API and
| with an idea in mind, that libraries would be required to get
| it up to level of OpenGL/DX11 and others. So in this respect,
| extensively using libraries on top of it is very normal, just
| like you don't write your software against syscalls these days.
| tombert wrote:
| That's what bothers me though; why not have an _official_
| higher level API that 's less awful to use? Instead you get a
| bunch of third party libraries bolted on top of everything.
| izacus wrote:
| Why though? Khronos doesn't have the best record of API
| design and there's plenty of other projects that are much
| higher level and simpler to use for a newbie developer. You
| can scroll just a bit up and see just how many webdevs end
| up using webgpu which is closer to the abstraction they
| prefer.
| wg0 wrote:
| Off topic kind of - Can an LLM generate such an article? Reading
| such in depth experiences and consolidating advice makes me think
| that web is made by humans and every other day,I spot something
| on the web that is clearly generated from some LLM.
|
| Great write up. Inspiring.
| eliasdaler wrote:
| Thanks a lot, that's a very touching comment.
|
| I try to make my website to feel like "the old Internet" that
| we seem to be losing and it's great that it's noticeable. :)
| layer8 wrote:
| Is this better than learning Klingon? ;)
| Waterluvian wrote:
| Are there any examples of an academic attempt at putting as much
| of a game into the GPU as possible? Like, architecting a game in
| a way that pretty much everything, including game logic, could be
| implemented as a shader?
| andrewmcwatters wrote:
| Shadertoy is your best bet. There are a few people doing it
| there.
| Animats wrote:
| This minimalism is very effective.
|
| I took the opposite approach, and it has cause great pain. I've
| been writing a metaverse client in Rust. Right now, it's running
| on another screen, showing an avatar riding a tram through a
| large steampunk city. I let that run for 12 hours before shipping
| a new pre-release.
|
| This uses Vulkan, but it has WGPU and Rend3 on top. Rend3 offers
| a very clean API - you create meshes, 2d textures, etc., and
| "objects", which reference the meshes and textures. Creating an
| object puts it on screen. Rust reference counting interlocks
| everything. It's very straightforward to use.
|
| All those layers create problems. WGPU tries to support web
| browsers, Vulkan, Metal, DX11 (recently dropped), DX12, Android,
| and OpenGL. So it needs a big dev team and changes are hard.
| WGPU's own API is mostly like Vulkan - you still have to do your
| own GPU memory allocation and synchronization.
|
| WGPU has lowest-common-denominator problems. Some of those
| platforms can't support some functions. WGPU doesn't support
| multiple threads updating GPU memory without interference, which
| Vulkan supports. That's how you get content into the GPU without
| killing the frame rate. Big-world games and clients need that.
| Also, having to deal with platforms with different concurrency
| restrictions results in lock conflicts that can kill performance.
|
| Rend3 is supposed to be a modest level of glue code to handle
| synchronization and allocation. Those are hard to do in a general
| way. Especially synchronization. Rend3 also does frustum culling
| (which is a big performance win; you're not rendering what's
| behind you) and tried to do occlusion culling (which was a
| performance lose because the compute to do that slowed things
| down). It also does translucency, which means a depth sort.
| (Translucent objects are a huge pain. I really need them; I work
| on worlds with lots of windows, which you can see out of and see
| in.)
|
| The Rust 3D stack people are annoyed with me because I've been
| pounding on them to fix their stack for three years now. That's
| all volunteer. Vulkan has money behind it and enough users to
| keep it maintained. Rend3 was recently abandoned by its creator,
| so now I have to go inside that and fix it. Few people do
| anything elaborate on WGPU - mostly it's 2D games you could have
| done in Flash, or simple static 3D scenes. Commercial projects
| continue to use Unity or UE5.
|
| If I went directly to Vulkan, I'd still have to write
| synchronization, allocation, frustrum culling, and translucency.
| So that's a big switch.
|
| Incidentally, Vulkano, the wrapper over Vulkan and Metal, has
| lowest-common-denominator problems too. It doesn't allow
| concurrent updating of assets in the GPU. Both Vulkan and Metal
| support that. But, of course, Apple does it differently.
| dc443 wrote:
| > WGPU doesn't support multiple threads updating GPU memory
| without interference, which Vulkan supports.
|
| This is really helpful for me to learn about, this is a key
| thing I want to be able to get right for having a good
| experience. I really hope WGPU can find a way to add something
| for this as an extension.
| dc443 wrote:
| Do you know if these things I found offer any hope for being
| able to continue rendering a scene smoothly while we handle
| GPU memory management operations on worker threads?
|
| https://gfx-rs.github.io/2023/11/24/arcanization.html
|
| https://github.com/gfx-rs/wgpu/issues/5322
| jms55 wrote:
| The actual issue is not CPU-side. The issue is GPU-side.
|
| The CPU feeds commands (CommandBuffers) telling the GPU
| what to do over a Queue.
|
| WebGPU/wgpu/dawn only have a single general purpose queue.
| Meaning any data upload commands (copyBufferToBuffer) you
| send on the queue block rendering commands from starting.
|
| The solution is multiple queues. Modern GPUs have a
| dedicated transfer/copy queue separate from the main
| general purpose queue.
|
| WebGPU/wgpu/dawn would need to add support for additional
| queues: https://github.com/gpuweb/gpuweb/issues?q=is%3Aopen
| +is%3Aiss...
|
| There's also ReBAR/SMA, and unified memory (UMA) platforms
| to consider, but that gets even more complex.
| dc443 wrote:
| Thank you. I hope to see progress in these areas when I
| visit later. I was hoping to be able to go all in on wgpu
| but if there are still legitimate reasons like this one
| to build a native app, then so be it.
| jms55 wrote:
| It depends on your requirements and experience level.
| Using WebGPU is _much_ easier than Vulkan, so if you
| don't have a lot of prior experience with all of computer
| graphics theory / graphics APIs / engine design, I would
| definitely start with WebGPU. You can still get very far
| with it, and it's way easier.
| Animats wrote:
| > The solution is multiple queues. Modern GPUs have a
| dedicated transfer/copy queue separate from the main
| general purpose queue.
|
| Yes. This is the big performance advantage of Vulkan over
| OpenGL. You can get the bulk copying of textures and
| meshes out of the render thread. So asset loading can be
| done concurrently with rendering.
|
| None of this matters until you're rendering something
| really big. Then it dominates the problem.
| Animats wrote:
| Short version: hope, yes. Obtain now, no.
|
| Long version: https://github.com/gfx-
| rs/wgpu/discussions/5525
|
| There's a lock stall around resource allocation. The asset-
| loading threads can stall out the rendering thread. I can
| see this in Tracy profiilng, but don't fully understand the
| underlying problem. Looks like one of three locks in WGPU,
| and I'm going to have to build WGPU with more profiling
| scopes to narrow the problem.
|
| Very few people have gotten far enough with 3D graphics in
| Rust to need this. Most Rust 3D graphics projects are like
| the OP's here - load up a mostly static scene and do a
| little with it. If you load all the content before
| displaying, and don't do much dynamic modification beyond
| moving items around, most of the hard problems can be
| bypassed. You can move stuff just by changing its transform
| - that's cheap. So you can do a pretty good small-world
| game without hitting these problems. Scale up to a big
| world that won't all fit in the GPU at once, and things get
| complicated.
|
| I'm glad to hear from someone else who's trying to push on
| this. Write me at "nagle@animats.com", please.
|
| For a sense of what I'm doing:
| https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ
| jms55 wrote:
| > All those layers create problems. WGPU tries to support web
| browsers, Vulkan, Metal, DX11 (recently dropped), DX12,
| Android, and OpenGL. So it needs a big dev team and changes are
| hard. WGPU's own API is mostly like Vulkan - you still have to
| do your own GPU memory allocation and synchronization.
|
| The first part is true, but the second part is not. Allocation
| and synchronization is automatic.
| Animats wrote:
| Vulkan does not allocate GPU memory for you. Well, it gives
| you a big block, and then it's the problem of the caller to
| allocate little pieces from that. It's like "sbrk" in
| Linux/Unix, which gets memory from the OS. You usually don't
| use "sbrk" directly. Something like "malloc" is used on top
| of that.
| jms55 wrote:
| Vulkan doesn't, but WebGPU does do synchronization and
| memory allocation for you.
| brian_herman wrote:
| Those kitties are so cute!
| eliasdaler wrote:
| Thanks! :D
| tombert wrote:
| I tried learning Vulkan a little more than a year ago and I have
| no desire to ever touch it again. It really bothers me that we're
| deprecating OpenGL and replacing it with something that's
| ridiculously hard to do anything simple (e.g. doing a spinning
| cube takes several hundred lines of code).
|
| OpenGL was never "easy" but it was at least something a regular
| person could learn the basics of in a fairly short amount of
| time. You could go to any big book store, buy some intro to
| graphics programming book, and get some basic stuff rendering in
| an afternoon or two. I'm sure Vulkan is better in some regards
| but is simply not feasible to expect someone to learn it quickly.
|
| Like, imagine the newest Intel/ARM/AMD chips came along and
| instead of being able to write C or C++, you're being told "We
| are dropping support for higher level languages so you can only
| write assembly on this now and it'll be faster because you have
| more control!" It would be correctly labeled as ridiculous.
| edflsafoiewq wrote:
| Vulkan is for writing OpenGL-type libraries against. It's
| advantage is largely that much of the library-level code is
| moved out of opaque and buggy device drivers and into user-
| space libraries.
| tombert wrote:
| No, I don't think that that's good reasoning. They could, if
| nothing else, make first-party libraries that have a high-
| level DSL or something that makes it less horrible to use. As
| it stands it creates a bunch of crappy libraries on top
| instead of an officially supported API that could also be
| standardized across operating systems and platforms.
|
| The terrible terrible Vulkan API just kind of feels
| gatekeepey. They got rid of the only open easy-to-use
| graphics standard, made _NO REPLACEMENT_ , and then said "oh
| you should just use this impossible API or let the outside
| world come up with a fix around it".
| edflsafoiewq wrote:
| It doesn't really make sense to have Khronos maintain nice
| high-level libraries. There's no evidence they'd be good at
| it and if you look at their GitHub, they're not
| particularly good at maintaining actual codebases in the
| first place. Their commitee/standard-based process works
| for specs, but I don't think it will work very well for the
| needs of day-to-day application programmers.
|
| Why do you need Khronos to "bless" a particular library
| anyway?
|
| Also they didn't get rid of OpenGL. You can still use it.
| It will probably be the most widely supported graphics API
| for a long time.
| tombert wrote:
| > It doesn't really make sense to have Khronos maintain
| nice high-level libraries.
|
| I guess we'll have to agree to disagree on that.
|
| > There's no evidence they'd be good at it and if you
| look at their GitHub, they're not particularly good at
| maintaining actual codebases in the first place.
|
| Well that's another complaint then, but it doesn't
| detract away from my initial complaints.
|
| > Why do you need Khronos to "bless" a particular library
| anyway?
|
| Because now we're going to have a million different
| wrapper libraries to do everything, or you're going to be
| stuck with the absurd Vulkan API. It was already annoying
| enough that you had to have different wrappers to
| abstract the GUI components, now people have to have
| another mediocre abstraction in addition to the GUI crap.
|
| I suppose you could argue "that's fine", and you're free
| to have that opinion, but I think it's worse
|
| > Also they didn't get rid of OpenGL. You can still use
| it. It will probably be the most widely supported
| graphics API for a long time.
|
| They're not doing new versions of OpenGL. Yes, the
| drivers will support them for the foreseeable future but
| they will get increasingly out of date.
| andrewmcwatters wrote:
| Khronos keeps pushing this in their promotional materials for
| the standard, and it's not an advantage. Now instead of
| vendors writing this correctly once for everyone, everyone
| can do it poorly. Go read a few Vulkan initialization
| implementations across a few repositories. It's all the same
| code, and some people miss portions of it here and there.
|
| I don't know how this lie caught on so well, but it doesn't
| pass the smell test.
| edflsafoiewq wrote:
| Pushing the code into a user-space library used by many
| programs means bugs can be fixed once in the library,
| instead of being at the mercy of every vendor fixing their
| driver blobs.
| andrewmcwatters wrote:
| Yeah, somehow I think putting this one on multi-million
| dollar companies with budgets to work on graphics work
| for products they sell and make actual money off of is
| better than having some podunkian whose popular graphics
| library gets consumed by a bunch of people while they
| make $5 each from less than 1% of their users off Patreon
| and GitHub Sponsors.
| jms55 wrote:
| > Now instead of vendors writing this correctly once for
| everyone, everyone can do it poorly.
|
| _Vendors_ did it poorly, which is why everyone wanted to
| get away from them. You could argue they over-corrected and
| left _too_ much to the user, but better safe than sorry.
|
| Sure users can write bad code as well, but at least it's
| _consistently_ bad, and fully under their control. There
| are so many fewer problems nowadays like "oh it works on my
| desktop, but on this older intel GPU for a user with
| outdated drivers it segfaults in the driver, and there's
| nothing we can do to fix it ourselves".
| SubjectToChange wrote:
| _It really bothers me that we 're deprecating OpenGL and
| replacing it with something that's ridiculously hard to do
| anything simple_
|
| OpenGL is only deprecated on MacOS, AFAIK, it will exist for
| many years to come.
|
| _I 'm sure Vulkan is better in some regards but is simply not
| feasible to expect someone to learn it quickly._
|
| Vulkan is often said to be more of a "GPU API" than a high
| level graphics API. With that in mind, the complexity of Vulkan
| is not surprising. It's just a difficult domain.
|
| _Like, imagine the newest Intel /ARM/AMD chips came along and
| instead of being able to write C or C++, you're being told "We
| are dropping support for higher level languages so you can only
| write assembly on this now and it'll be faster because you have
| more control!" It would be correctly labeled as ridiculous._
|
| IMO, it's more like single threaded C/C++ vs multithreaded
| C/C++ programming. There is a massive increase in complexity
| and if you don't know what you are doing, it'll blow up in your
| face and/or give you worse performance. However, it's the only
| practical path forward.
|
| Anyway, OpenGL can basically be implemented on top of Vulkan.
| Perhaps it is regrettable that the OpenGL standard is no longer
| being actively developed, but nothing lasts forever.
| uwagar wrote:
| life was a pleasure writing programs in IrisGL and then OpengGL
| :(
| eliasdaler wrote:
| Yeah. Even though it might seem I'm 100% enjoying Vulkan, I
| still wish there was something closer to OpenGL and which was
| supported by GPU manufacturers. Other 3d party graphics
| frameworks are not bad, but you don't feel the same confidence
| in their future in the same way as you did about OpenGL.
| rychco wrote:
| I've been lurking & following your project for months in the
| Graphics Programming discord as I work on my own hobby Vulkan
| engine. It's been inspiring seeing all the progress you've made.
| I especially admire your willingness to ask questions & share
| your work-in-progress so openly. Keep up the great work
___________________________________________________________________
(page generated 2024-06-06 23:00 UTC)