[HN Gopher] How to write a Vulkan driver in 2022
___________________________________________________________________
How to write a Vulkan driver in 2022
Author : mfilion
Score : 56 points
Date : 2022-03-23 18:56 UTC (4 hours ago)
(HTM) web link (www.collabora.com)
(TXT) w3m dump (www.collabora.com)
| shmerl wrote:
| Nice, will this code become the basis of actual nvk for Nvidia
| Vulkan driver in Mesa?
| sylware wrote:
| Hard truth: vulkan is so lean, it almost does not need any shared
| code between hardware vulkan drivers.
| Jasper_ wrote:
| It's quite lean, it requires a lot less code than OpenGL does!
| But it does require some -- partly because there's some cruft
| left in the spec, but also because there's _always_ some work
| that can be shared. SPIR-V and NIR being the big ones, everyone
| needs a shader compiler, and a good chunk of the work around
| that can be shared. And then the stuff on top of that like
| pipeline caches. That 's stuff where the spec got it right, but
| just everybody needs some infrastructure.
|
| There's also things like subpasses, which, if you _can_ ignore
| it, you can just use a "default" implementation that acts like
| a desktop immediate-mode GPU and ignores subpasses. Not always
| appropriate for a mobile GPU or a tiler, where subpasses are
| meaningful to you, so it's provided as an optional helper.
|
| Then there's just leftover spec mistakes like VkFramebuffer,
| where the spec is just thicker than it should be. That's fixed
| in future spec versions but someone needs to implement the old
| way.
| sylware wrote:
| VkFramebuffer is gone in future versions or vulkan? By what
| was it replaced? (I am being lazy here, asking instead of
| going to read the latest specs). I coded my everyday video
| player using vulkan (very conservative), I would move my code
| to this new thingy once it's in mesa. What I liked with
| vulkan, on the main thread of my video player, I just post
| vulkan non-blocking commands, I don't even need a video
| thread! I can even use the main thread to mix fast enough the
| audio data!
|
| NIR is a sweet spot for me (lean C89 code with benign bits of
| c99/c11), even though I would like a configure "switch" to
| remove all non-breaking algebraic optimizations from the
| vulkan drivers (I used to do that myself for a good while,
| near 0 performance impact) since it is redondant because
| those should be directly done in spir-v code.
|
| Since I am an AMD user (I play video games, now all the ones
| I play have a vulkan backend), even if I really dislike a
| bloody lot c++, I am grateful to valve for ACO (because llvm
| is beyond toxic, even from a c++ point of view). But I wish
| ACO would manage to add the possibility for hand-coded
| assembly shaders (AMDGPU ISA is public and really ez to
| code), just need a few relocation types (writing an assembler
| should not be a nightmare like with hw architectures using
| bazillions of relocation types).
| shmerl wrote:
| Congrats to Mesa on reaching the level when some like Imagination
| are already seeing benefits in making an open Vulkan driver.
| tlamponi wrote:
| Collabora has IMO some nice work going on, development and
| educational wise.
|
| Also, I'm getting some strong hints about getting a vulkan driver
| for nvidia soonish, would be nice!
| mhh__ wrote:
| The Mesa codebase does feel quite weird from afar but it would
| fun to contribute. I know compilers but not much about graphics.
|
| Unfortunately I don't have a box to try wacky drivers on so that
| may block my efforts to embarrass myself in one more domain.
| Couldn't tell whether they test in VMs or physical boxes (or
| userspace?)
| shmerl wrote:
| You can simply build it on Linux and test (you can use it
| without packaging anything). It's separate from kernel drivers.
|
| Configuring the build with Meson might look a bit intimidating,
| but you can find examples by checking how distros configure it.
|
| For example on Debian you can see this in the build log:
|
| https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=amd...
|
| Search for
|
| LC_ALL=C.UTF-8 meson
| dyingkneepad wrote:
| The Mesa driver is all in user space, it's simply a library.
| You can develop it without messing with your system or any of
| the applications that are generally open.
|
| Developers can just build and install them to some user-
| controlled directory (e.g., $HOME/opt) and run from there with
| LD_LIBRARY_PATH and other similar variables. You can wrap all
| the variables in a script and run your custom-built mesa with
| simply "$ with-custom-mesa glxgears" and then glxgears will be
| using your custom (and possibly broken) driver, while
| everything else will still be using the default drivers from
| the distro.
|
| You could use containers such as systemd-nspawn, but it's much
| more complicated than simply using $HOME/opt.
|
| Edit: https://docs.mesa3d.org/install.html#running-against-a-
| local...
| corysama wrote:
| I heard it said that OpenGL drivers are essentially run-time
| compilers :) Working on a driver like this would not actually
| involve much knowledge of graphics. It's more an exercise of
| careful spec interpretation and deep knowledge of hardware-
| level interface.
|
| Have a read through
| https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-...
| and see if you'd find that space interesting to work in.
___________________________________________________________________
(page generated 2022-03-23 23:00 UTC)