I am just doing game dev on the side but i think nowadays the graphics abstractions are fairly similar in how they work (the modern abstractions, i.e. Metal, D3D12, Vulkan). Of course ideally you choose the graphics abstraction that is "native" to the platform, but vulkan seems to be supported very well on windows (many AAA game use it and it works great, many games run even better with vulkan abstraction than with their d3d12 counterpart). I use vukan so my graphics can run on windows and linux (which is why i chose vulkan instead of d3d12).
You are correct that idTech targets Vulkan (and they have some great GDC talks to boot)
They are however very much the minority.
I am suspect of your claim about Vulkan abstraction layers running better than DX12. If there is a performance difference, it’s likely elsewhere in the stack and just tangentially related.
I haven't done this stuff for quite a while, so my memory might be foggy, but the main advantage of Vulcan was that you can control all the CPU locking rather than the API doing it. This allows you to do stuff like prepare on one thread and submit on another, etc.
But that would be negated if you're using an abstraction layer.
Before reading DDIA you can have a look at the book "Web Scalability for Startup Engineers". I found it to be easier and more informal. After you read that book you can read DDIA.
As someone new to deployment this book was a great read. I learnt a breadth of new techniques (ssh, security (e.g. fail2ban, selinux, permissions), bash commands, dns and configuration of a vps) and i also liked, that the author gave advice on which tools could be helpful (e.g. Ansible).
The book however does not go into detail on these tools (ansible, terraform), its goal is to teach the basics of deploying an app on a linux vps.
Thanks for a nice review. The book is already long as it is, so I only provide some general ideas behind these tools. The path forward might be very different from person to person. Some will want to convert the Bash code to Ansible and some are already running Kubernetes clusters at work :)
I am also trying to learn modern DevOps techniques. While researching i found that many people recommended the courses from KodeKloud (https://kodekloud.com/).
I have not taken them myself already, but i think they also include labs so you can practice the techniques.
Could you elaborate why the java spring framework is a bad choice? I wanted to get into backend development and i thought spring is a good and battle tested framework? I also thought of using rust, elixir or go. I chose java spring because i already know java and compared to rust and elixir the support for third party libraries is much bigger.
The Java ecosystem is culturally heavyweight and verbose with the needs of very large, bureaucratic organizations and Spring is one of the biggest examples of it (although Spring Boot has done a fair bit to modernize workflows). The struggle I can point to with a previous company was that our Java based stack made hiring extremely hard for our small company because large companies with deep pockets could hire for largely the same job at double our budgets, and for people wanting to work on sexier languages and platforms such as Rust, Go, or even Python other small companies offered that freedom. The hiring pipeline was so problematic it’s led to several years of delays rolling out features that the rest of the market has had and whatever intrinsic advantages the business had is possibly irrelevant as even the larger players have been able to do 99% of the same things.
So being able to quickly move is a large advantage of being a smaller organization and anything that demonstrably hurts that advantage should be stricken from the company’s investments ASAP as long as it stays small and has no other material market advantage.
It really all depends upon what makes sense for one’s situation but I was very frustrated with our hiring pipeline and the outdated stack made things much more complicated to do basic things than it should have.
I prefer apps built using APIs like Vulkan or OpenGL to apps built using electron because they do not feel as sluggish. I think the Blender UI also uses OpenGL to render the interface. One criticism of this approach that has come up in many threads on the same topic however was the lack of accessibility. This is a big pro for electron (and also native development).
It not even a drawing API, even. It's a 3D triangle rendering API. Things like lines, bezier curves, gradients are all do-it-yourself. None of it super-hard, I've done them all, but before you write your UI you have to write all your drawing routines, which probably wasn't what you wanted to be doing. And you get all the fun texture management issues for any gradients and images you want to display. And you probably won't have optimized it like the platform rendering will have.
And then there's text... You've got to load a texture for every glyph of every point size used in the app for every font used in the app. Mind you, the OS already has a cache for this, but you don't have access to it, so that's more memory wasted. Which would be sizeable if every app on your system was using Japanese, or worse, Chinese, and making a copy of all this stuff.
it isn't the main point of your comment... but why is Chinese worse than Japanese? is it about the font itself being different or about Chinese text containing on average more unique characters?
More characters. I believe there are a mandated 2000 characters that learned in school and used by newspapers. I believe 3000 Chinese characters only gets to 97% and 5000 is still 99.44% [0]
This is a very good point that I feel gets overlooked way too often. When people talk about the UI feeling sluggish most of the time they are talking about responsiveness.
Like, who cares if your app is rendering at 120 fps if it takes me 3 seconds to focus on a text field? I feel like that’s where most cross platform tooling has their work cut out.
Hi Paul, not sure if this an appropriate place to mention this but I hope you please consider at some point using OpenGL or Vulkan to at least render the track view in Ardour. I have a large project with around 50 tracks that is extremely slow and laggy to render when zoomed all the way out, it is making the program unusable for me. I could provide a profile to put in a bug report but I'm not sure the best way to go about that. Thanks.
We use Cairo for all rendering. Cairo has various backend implementations, and when it gets a Vulkan backend and you're using Ardour on a system with Vulkan available, it will be used.
We're not going to write renderers at a lower level than Cairo at any time in the foreseeable future.
Also, most of the issues with slow rendering are caused by your video interface driver and/or bugs in Cairo that we provide a few workarounds for already. Edit > Preferences > Appearance > Graphics Acceleration has two options ... you need to try all 4 possible combinations to exhaust the possibility that we've already solved the issue you are facing :)
Thanks for the tips, I will try that and try to get some perf, I am currently compiling Ardour 6.9 :)
On a side note, I don't mean to be the bearer of bad news but I think you need a better plan than this, cairo has been in various states of inactivity and deep maintenance mode over the last several years, if anything more backends will be removed, not added. Also, cairo is an immediate mode-style renderer following the PDF imaging model made for print -- it's fundamentally the wrong approach for high performance rendering. You may not see much improvement even if it did have a Vulkan backend.
I really feel as though Vulkan is a brilliant leveller, with the chance to replace DirectX with a cross-platform, open source standard, funded by Valve and Sony? Sign me up.
