4 years ago by vvanders
While broadly right this has some inaccurate parts, in particular:
> 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...
4 years ago by hertzrat
> 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
4 years ago by xyzzy_plugh
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.
4 years ago by skohan
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.
4 years ago by willis936
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.
4 years ago by brobdingnagians
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.
4 years ago by hvis
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.
4 years ago by undefined
4 years ago by Bekwnn
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.
4 years ago by kevingadd
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.
4 years ago by Arelius
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.
4 years ago by josefx
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.
4 years ago by gmueckl
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.
4 years ago by vblanco
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.
4 years ago by Jasper_
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.
4 years ago by vvanders
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.
4 years ago by withinboredom
> 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.
4 years ago by m12k
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++.
4 years ago by jan_Inkepa
"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).
4 years ago by m12k
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.
4 years ago by vblanco
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.
4 years ago by vanderZwan
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).
4 years ago by sharpercoder
4 years ago by vanderZwan
Thanks!
4 years ago by jstimpfle
> 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?
4 years ago by camjw
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.
4 years ago by ratww
These manual pages have an exhaustive list of supported types and language constructs:
https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual...
https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual...
4 years ago by Animats
"Unreal Engine 4 will have a Game Thread and a Render Thread ..."
This seems dated. UE4 shipped in 2015.
4 years ago by jayd16
Probably just poor word choice. Links from 2018 and maybe younger are referenced.
4 years ago by geswit2x
>âUnreal 4 will have...â
Unreal Engine 5 is coming...
4 years ago by ozarker
It's just badly worded. I remember following this blog last year when new articles were being posted.
4 years ago by Dowwie
Does anyone know of a collection of coding problems like "Dining Philosophers" for working through common concurrency scenarios and synchronization issues?
4 years ago by imtringued
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.
4 years ago by vanderZwan
I assume you're already familiar with Rosetta Code and are asking for something subtly different?
4 years ago by Dowwie
This is what I was referring to. I'm looking for a collection of these.
4 years ago by IdiocyInAction
There's the "Little Book of Semaphores".
4 years ago by tempnowreal
Can someone point me to good sourced where I can learn more about the inner workings of graphics? Something thats probably beginner friendly?
4 years ago by wernsey
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
4 years ago by bullen
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!
4 years ago by HelloNurse
"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?
4 years ago by bullen
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?
4 years ago by HelloNurse
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.
Daily digest email
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.