Multithreading for Game Engines(vkguide.dev)
vkguide.dev
Multithreading for Game Engines
https://vkguide.dev/docs/extra-chapter/multithreading/
70 comments
> Unreal Engine 4 is open source
Another small mistake here as well. The source is available to read and modify under license but it’s not open source
Another small mistake here as well. The source is available to read and modify under license but it’s not open source
The fact that this "mistake" occurs so frequently and is so trivial to make just tells me that the meaning you want it to have will not survive in the long run.
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.
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.
It's an extremely important distinction. There's a term for software like Unreal Engine, which is "source available", and the difference between this and "open source" has massive categorical differences in terms of what you can legally do with this source code.
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.
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.
This topic turned up on HN 6 weeks ago: https://news.ycombinator.com/item?id=26079067
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.
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.
Just because there are people who don’t understand what “free as in beer” means doesn’t mean that people should stop teaching them what it means.
I have never understood what the hell "free as in beer" means either.
It's confusing to me too when it's phrased that way. Stallman's original quote makes much more sense, "Think free as in free speech, not free beer." In other words, contrasting free as in "no restrictions", versus free as in "no cost".
Gratis vs Libre.
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.
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.
If you see a sign advertising “Free Beer” you understand that the meaning of “free” in this context means “goods and/or services available at no cost”. The English word “free” means a lot of things and the meaning of “free” in the expression “Free Beer” is very different from the meaning in the expression “Free Speech”, where it is used to mean “not legally restricted”.
I guess I just don't know any places that have free beer.
"Free beer" is often used to describe a social or work gathering. If the host/company pays for drinks, it's "free beer."
As in, "hey come to the seminar with me on Thursday: there's pizza and free beer."
As in, "hey come to the seminar with me on Thursday: there's pizza and free beer."
Perhaps Freedoms vs Freebies?
I always thought “free as in beer” meant that you could make your own beer if you were willing to put the discovery, learning, and work in to make it happen. And you were responsible for the output.
That's not correct, the meaning is as humbledrone says.
Free as in beer is used in contrast with Free as in freedom, and refers to something made available free of charge.
Free as in beer is used in contrast with Free as in freedom, and refers to something made available free of charge.
Language develops according to how people actually use it. There are two competing camps on the meaning of "open source"; I understand why there is a battle over it on ideological grounds, but I don't think it is necessarily a mistake, more of a different side of the debate. Much like how some people are pedantic about calling them "tissues", while a large body of people know the difference but just go on calling it kleenex. Not wrong, just a different culture of usage.
One of the camps are members of the open source movement (developers, promoters and satisfied users) and the other comes from corporations trying to co-opt the term and its good reputation.
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.
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.
[deleted]
I've always referred to it as "(has) source access". It is a bit frustrating and misleading when people refer to it as open source.
I call it "source available"
Because "open source" means absolutely nothing. We should use "Libre/Free Software" or refer to actual licenses to be more accurate.
Except "open source" does have a meaning - specifically, the one defined by the Open Source Initiative.
Stallman already wrote years ago why "open source" was a bad name. From https://www.gnu.org/philosophy/open-source-misses-the-point.... :
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.
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.
"Free" is also ambiguous in English, even more than "open". I suppose "libre" is explicit but also not an actual common word.
"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.
"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.
> "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).
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.
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.
'open' and 'source' are also just two words of the English language which have an implied meaning when put together. I do not think any initiative can ban the normal meaning of language. It is like saying the 'real beef initiative' declares the meaning of the word 'real beef' to only apply to kobe beef.
Also how would you actually call software where the source is open but does not fulfill the osi criteria?
Also how would you actually call software where the source is open but does not fulfill the osi criteria?
> 'open' and 'source' are also just two words of the English language which have an implied meaning when put together.
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...
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...
[deleted]
Threaded OpenGL is something you only do if you either have a death wish or a phone number you can dial to speak to a VP at NVIDIA. Everyone I know who's shipped it in games regretted it, and I've had driver developers explicitly tell me I shouldn't bother.
Vulkan is indeed threading-friendly, though.
Vulkan is indeed threading-friendly, though.
Yeah, it’s technically supported, and I have seen the patient ship it in limited use. But it’s certinally not a well tested path and the stability leaves a lot to be desired.
I work on a program that consistently uses it read and load large textures. Never had an issue with it outside of getting the barriers right.
Loading buffers and textures are about the only things that are kind of stable in multithreaded OpenGL. This is the probably the only use case anybody cares about. Go beyond that and you'll have a high chance to hit strange driver bugs.
Good catch, i was unaware that loading textures off threads in opengl was possible, given that ive never seen it used even on commercial engines. Ill update the article to reflect that.
In my experience, even the best Android drivers just took locks when using OpenGL from multiple threads, even for resource creation, so it's sort of moot.
That depends largely on the driver. It's not a guarantee but I've seen pretty solid perf wins on the drivers that support it.
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.
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.
> just about every Android SoC minus a few odd ones
All those users will leave you a one star review when it crashes on their device.
All those users will leave you a one star review when it crashes on their device.
sometimes I cry a little over the fact that people who only have access to under powered phones are the most incentivised to criticise apps despite being consigned to ultimate futility regardless of their actions, whilst it's a rare occasion when the owner of a flagship phone is going to give feedback of any kind about performance to the developers of a poorly performing app that may be software atrocities but given more hardware than the average high end laptop to consume...
this immediately reminded me of SGI's Open Performer and the subsequent failed OpenGL++ efforts :
https://en.m.wikipedia.org/wiki/OpenGL_Performer
https://en.m.wikipedia.org/wiki/OpenGL_Performer
IMO the Burst compiler that can "jobify" and multi-thread your code relatively painlessly is the most impressive piece of tech Unity has produced (disclosure: used to work there, though this was made after my time there). It's not that hard to fit into its constraints, and it often provides 2x-200x speedups. It's still mind-boggling to me that it's possible to get (a constrained subset of) C# to beat hand-optimized C++.
"painlessly" involves writing your code in a totally different paradigm to the standard MonoBehaviour component approach, doesn't it? It's impressive, but I think you understate the "pain" a bit. (Disclaimer: I haven't successfully been able to motivate myself to use it - it's a heavy framework and normally when I'm making games the limitation isn't performance but my ability to get the interactions I want coded, so I prefer the more flexible MonoBehaviour component style).
That's fair - and tbh most games don't need to push the envelope when it comes to performance, so it makes sense to just stay with the most flexible default option. Still, when you compare to something like ECS, which basically needs to take over your whole architecture and give up the flexibility of MonoBehaviours, it's much easier to burst-jobify a smaller, performance critical part of your game.
Burst and Job system forces the user to follow good patterns for the multithreading, and makes sure that the user isnt writing to the same thread-unsafe structure from 2 jobs. In that regard its similar to what Rust does.
It really is great to have all that checking, as if it passes the checks, it probably will work great. Keeping all the read/write dependencies beetweeen tasks in Cpp is very hard.
Is there a technical write-up of what it does and how it works somewhere? I'm not about to write any games, let alone use Unity, so Unity-specific tutorials wouldn't really help me (plus they're just going to be focused on how to use it, not on how it works).
> It's still mind-boggling to me that it's possible to get (a constrained subset of) C# to beat hand-optimized C++.
To me the interesting question is -- what can you do within this constrained subset?
To me the interesting question is -- what can you do within this constrained subset?
The restrictions are: no reference types, manually manage your memory. My previous job was basically writing loads of burst code and it was so ergonomic and fun to write, and (as the GP says) you basically get 200x speed up for free.
These manual pages have an exhaustive list of supported types and language constructs:
https://docs.unity3d.com/Packages/[email protected]/manual...
https://docs.unity3d.com/Packages/[email protected]/manual...
https://docs.unity3d.com/Packages/[email protected]/manual...
https://docs.unity3d.com/Packages/[email protected]/manual...
So, technically, they took into account what parts of C++ are used to optimize a game and they made them low-hanging fruits for C# devs?
C# has plenty of low hanging fruits, more so since C# 7.0, it is a matter of people to learn how to use them.
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.
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.
[deleted]
> It's still mind-boggling to me that it's possible to get (a constrained subset of) C# to beat hand-optimized C++.
That sounds interesting, do you know if there are benchmarks available?
That sounds interesting, do you know if there are benchmarks available?
Does anyone know of a collection of coding problems like "Dining Philosophers" for working through common concurrency scenarios and synchronization issues?
I assume you're already familiar with Rosetta Code and are asking for something subtly different?
https://rosettacode.org/wiki/Dining_philosophers
https://rosettacode.org/wiki/Dining_philosophers
This is what I was referring to. I'm looking for a collection of these.
There's the "Little Book of Semaphores".
Here is an easy (or extremely hard) problem.
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.
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.
Can someone point me to good sourced where I can learn more about the inner workings of graphics? Something thats probably beginner friendly?
Gabriel Gambetta's book Computer Graphics from Scratch is available freely online and was discussed here just the other day:
https://gabrielgambetta.com/computer-graphics-from-scratch/
Another link I found interesting is this one: https://github.com/ssloy/tinyrenderer/wiki
https://gabrielgambetta.com/computer-graphics-from-scratch/
Another link I found interesting is this one: https://github.com/ssloy/tinyrenderer/wiki
When you multi-thread the rendering you _always_ push the motion-to-photon latency up, because you need to hand off the previous work to the renderer, sometimes by up to 10 frames!? That's is why AAA titles like the last guardian and RDR2 are unplayable.
The only way to solve this is to make the GPU concurrent so it can receive instuctions on separate threads at the same time!
The only way to solve this is to make the GPU concurrent so it can receive instuctions on separate threads at the same time!
"To make the GPU concurrent so it can receive instructions on separate threads at the same time" has been one of the major reasons to use Vulkan instead of OpenGL since the beginning, it isn't only a wish.
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?
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?
I don't think you can send instructions on multiple cores at the same time with Vulkan, if so why is it so hard to find examples of it?
You can both build command buffers simultaneously (example by Sascha Willems: https://github.com/SaschaWillems/Vulkan/blob/master/examples...) and submit unrelated command buffers to different queues simultaneously.
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.
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.
But I have to use commandbuffers right? I prefer direct/forward rendering... I wish you could do that directly to the GPU with multiple cores... I heard you "can" do that with OpenGL... but I don't think it accepts more than one context simoultaneously.
There is no such thing as direct rendering, commands are always buffered by the driver before being sent to the gpu. (and Forward rendering as in the rendering technique ?)
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.
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.
> 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...