Multithreading for Game Engines
vkguide.dev
vkguide.dev
> If we were talking about OpenGL, there would be absolutely nothing you can do. In OpenGL or other older APIs, it’s only possible to do API calls from one thread.
Isn't really true. You can load textures off thread[1] and other things which come in handy. Vulkan expands that but I've done multithreaded texture loading for instance almost a decade ago.
This is particular important if your not loading compressed textures as there's usually a tiling/swizzle pass and the texture copy can be significant on large textures(unless you're using something like eglCreateImageKHR).
[1] https://www.khronos.org/opengl/wiki/OpenGL_and_multithreadin...
Another small mistake here as well. The source is available to read and modify under license but it’s not open source
You are correct that it isn't Open Source as defined by the Open Source Initiative, nor does it use an Open Source Initiative Approved License.
None of that information, however, is helpful to the author or really changes anything about the article.
As in, "hey come to the seminar with me on Thursday: there's pizza and free beer."
Even as a non-latin speaking person I can identify the difference between those types of "free".
Or, alternatively "Free as in Freedom", which is another phrase I've heard coming from the FSF.
Free as in beer is used in contrast with Free as in freedom, and refers to something made available free of charge.
If an important distinction like this is fading from our language, it's probably evidence that newer members of the community haven't been fully educated on the implications of software licensing terms, and if that's the case we should focus on improving that education, not resign ourselves to important knowledge being lost by the community.
For instance, if you learned that young people were not aware of the dangers of exposure to lead, you would not throw up your hands and say: "I guess we'll just start using lead pipes again". You would make an effort to pass on that knowledge.
I agree with your position. Open Source is not a meaninglessly unclear term, it is a precise term of art. It makes good sense to resist efforts to turn it into a meaningless marketing term like premium.
Some people point out that the term isn't trademarked. That doesn't matter. That isn't how terms of art work.
The official definition of “open source software” [..] agrees with our definition in most cases. However, the obvious meaning for the expression “open source software”—and the one most people seem to think it means—is “You can look at the source code.” That criterion is much weaker than the free software definition, much weaker also than the official definition of open source. [..] Since the obvious meaning for “open source” is not the meaning that its advocates intend, the result is that most people misunderstand the term.
"Open" is clear, widely accepted by the community including businesses, and is defended by the Open Source Initiative (think of them what you will, they do a good job of keeping that definition true, by doing things such as approving licenses).
"Open" has also been extended to other areas, such as "open science" (which does not refer to science for which a paper is available, but to actual reusable science).
I don't see any problem with "open", other than the fact RMS doesn't like it.
That meaning predates the use of "open" to describe software, hence why "open source" isn't that great of a term for something truly new. It co-opts the much older term "open source" which means freely available through non-protected sources. Like, in the intelligence services "open sources" has meant non-classified, non-restricted sources. There's a similar meaning in journalism.
Also how would you actually call software where the source is open but does not fulfill the osi criteria?
Right, which is further evidence against the assertion that '"open source" means absolutely nothing'.
> Also how would you actually call software where the source is open but does not fulfill the osi criteria?
I tend to use the term "transparent software". Goes hand-in-hand with my catchphrase[0] 'round these parts. Basically: if I can see the source code (and therefore can independently audit it, or hire someone to do so), then it's transparent and can (potentially) be trusted, even if the license infringes on my freedoms around that source code (modification, redistribution, etc.).
----
[0]: "transparency is a dependency of trust": https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
It's not really a "everyone has a right to an opinion" type of situation.
You can go on and support the dilution of the term, just remember when the software development culture has another turn to the worst, you had been a part of the problem.
From a hardware perspective just about every Android SoC minus a few odd ones have unified memory so there's really no reason for them to take a lock, at least for the heavy part of the operations that copy the texture and tile/swizzle.
All those users will leave you a one star review when it crashes on their device.
Vulkan is indeed threading-friendly, though.
To me the interesting question is -- what can you do within this constrained subset?
https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual...
https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual...
As of C# 9:
- value types
- proper memory slices
- ability to do stackalloc in safe code
- readonly structs
- generics for blittable types
- zero allocation pipelines
- using without IDispose for structs without implicit boxing
- return scope for zero copy struct parameters
- native function pointers
- static lambdas
- GC free code regions
What HPC# and Burst bring to the table is an enforced GC free code and a compiler that is special purpose for a game engine, taking that knowledge into consideration when generating native code, for example remapping SoA into AoS and similar.
That sounds interesting, do you know if there are benchmarks available?
This seems dated. UE4 shipped in 2015.
Unreal Engine 5 is coming...
Build a 2d grid with two objects. A chest and a hopper. Chests and hoppers are containers that hold up to 64 items. When a hopper (they can point in 4 directions) is pointing at a chest it will insert its inventory into the chest, until the chest is full (one item at a time). If there is a chest on the funnel side of the hopper then extract items from the chest and put the items into the hopper (again one item at a time). Chaining hoppers is allowed.
Now go out and enjoy multithreading hell.
Hint: through weird contortions it is possible to do this without any synchronization and keep it data parallel at the same time. If you did this in a production codebase you would be the only person on the planet that will understand the code.
https://gabrielgambetta.com/computer-graphics-from-scratch/
Another link I found interesting is this one: https://github.com/ssloy/tinyrenderer/wiki
The only way to solve this is to make the GPU concurrent so it can receive instuctions on separate threads at the same time!
Reducing dependencies and organizing scheduling of simulation and rendering tasks in order to perform useful work in parallel, both on the CPU and the GPU, remains challenging, but an important bottleneck has been lifted.
What horrible practices can introduce 10 frames of latency, besides generic slowness and gratuitous buffering?
Using multiple queues is not difficult, just somewhat rare: there should never be so many command submissions that parallelization matters for quantitative performance reasons, it's a niche for unusually independent and/or asynchronous tasks.
With Vulkan/Dx12 you can record multiple command buffers in parallel. That is not possible in OpenGl/Dx11 (There are 'deferred contexts' that let you do things in parallel but it's really not great).
By 'multiple cores on the GPU', I think you mean the hardware queues ? Usually there are 3 (on PCIe discrete GPUs, that is) a graphics queue to record any commands, a compute queue for compute tasks, and a copy queue for DMA copies across the PCIe bus. I don't know if you can access them independently on older APIs, but on Vulkan/dx12 you certainly can.