Where does it all go?

The thing is even with lots of cores to work with in our games we still need to funnel our data back into Unity via the single main thread/core?

Or do I have this wrong, are there ways to pass data directly from worker threads into Unity or is Unity working on this problem?

 

For data that is best passed in directly (eg mesh data, texture data, etc) there are already ways to pass the data to Unity.

 

And Unity are working on multi-threaded transforms so what other data would you need to pass to the Unity main thread?

 

...dude.

Have you EVER done actual multithreaded programming? You know, with semaphores, critical sections, synchronization issues, and such? When bugs may be harder to catch and reproduce?

Do you want to cry bloody tears in frustration? Do you want to wake up at late night screaming in horror realizing there's a hidden race condition you have not thought of? Do you want to tear your hair out trying to find that one rogue thread which is breaking your program when it is run on the day of full moon? Then multithreaded programming is for you!

Spoiler

Alright, that was a joke. The joke has a bit of truth in it, though.

Be happy that your game can fully utilize one or two cores (where one core is conveniently few thousands times more powerful than computer used to send people to the moon) and still have plenty of resources left for OS needs.

I still remember porting that one game to DX9, where some asshole decided it was a good idea to make it utilize fifteen threads, BUT did not account for true parallelism

Spoiler

not a single mutex/critical section anywhere, because, hey, it was originally ported from dos to OS2 then from it to Windows and obviously there was no chance that home CPUs will ever become dualcore. I mean would could possibly go wrong with only 5 megabytes of of C code mixed with C++

, and kept passing function parameters through global variables.

 

Regarding your question:

Depending on graphical API being used certain operations will HAVE to happen in the main thread, where API was initialized. I believe back in DX9 enabling multithreaded support actually caused performance drop, because certain portions of GPU behavior had to be protected with critical sections.

Having multiple cores will not guarantee easy performance boost (because it is up to OS to decide what gets done, when and in which order), and you'll still need to periodically synchronize. Meaning if ONE of the other threads will take longer, everybody will have to wait for it to finish, doing nothign useful meanwhile.

Multithreaded programming is considered to be inherently more difficult. Standard/traditional synchronization primitives are very error prone. There are newer paradigms like async execution, "future" and "future watcher" classes, etc. also, there is a belief that functional languages are more suitable for multithreaded environment (because no side effects means no way to screw up data in another thread). The fun thing, in C# those new and fun concepts would be using anonymous lambdas, and anonymous lambdas in C# produce garbage at every every opportunity, because data is getting wrapped into anonymous classes. Meaning, lots of fun.

In general, multithreading your game is something you DEFINITELY don't want to touch unless there's no way aroudn it.

 

Dx9 was released in 2002!
Dx10 2006
Dx11 2009
Dx12 2015 / Vulkan - Designed to be Multi-threaded

 

Except most games aren't using DirectX 12 and won't if they want to target as many people as possible. Most people simply aren't on DirectX 12 hardware or supported OSes yet.

https://en.wikipedia.org/wiki/List_of_games_with_DirectX_12_support

There are seriously only three upcoming DirectX 12 games in that list and one of them is Star Citizen which has been "upcoming" for years now and one of the others only has support "planned".

By the way where I say "DirectX 12" I obviously include "Vulkan". Just saying it now before someone comments on it.

 

Most people have DX10/11 spec hardware http://hwstats.unity3d.com/pc/gpu.html

With 88.3% able to use DX10+ features.

 

Only if they use Vulkan (most people are still on Windows 7). What is the status of Vulkan driver support these days?

http://hwstats.unity3d.com/pc/os.html

 

Okay. Went searching a little bit because I had nothing better to do.

Intel added non-beta support for Vulkan as of Feb 10th.
https://software.intel.com/en-us/bl...rom-beta-support-to-full-official-support-for

NVidia added support for Vulkan as of Feb 16th.
https://blogs.nvidia.com/blog/2016/02/16/vulkan-graphics-api/

AMD has had it since May but that's to be expected from the company that basically invented the precursor to it.
http://support.amd.com/en-us/kb-articles/Pages/AMD_Radeon_Software_Crimson_Edition_16.3.aspx

That's further along than I was expecting but it's still basically within the past several days.

 

These two posts (with a little glue) explain the error in your thinking:

...and those activities are already recognized to be slow:

Just because certain internal activities (like your transforms example) may be internally multi-threaded doesn't imply the entire stack will magically become thread safe. Parallelism is a subset of multi-threaded programming, and we've had excellent support for that in shaders (including languages that go to heroic lengths to hide synch complexities from day to day dev concerns), yet performance pitfalls and problems are everywhere.

The bottom line is that synchronization is a performance killer, in addition to everything neg mentions about it being a total nightmare to debug and maintain. Been there, done that. This will also be true in Vulkan, by the way, since you keep bringing it up. There is nothing magical about how it opens up the API to multi-threading, you still have to undertake significant effort to avoid shooting yourself in the foot as soon as you decide to go there.

In other words, your imaginary "MOAR THREADS" button is not a magic bullet to improve performance by generically running lots of stuff at the same time. Threading is primarily a solution for managing concurrency with bound processes. There is significant overhead managing that concurrency which is the reason it's usually limited to scenarios where it is unavoidable... and then only when wait times far exceed the processing delays required to manage concurrency.

Threading solves very specific problems and you generally only want API support (and usually, corresponding performance tradeoffs) only at those touchpoints relating to your specific problem. You don't appear to have anything specific in mind (as usual), so it's pointless to gnash and wail that it isn't available to you.

TL;DR: MOAR THREADS ≠ performance magic wand

 

Stop grasping at straws.

It doesn't make any difference.

In multithreaded environment certain operations will always be slower because of overhead introduced by making them thread-safe. When multiple threads will attempt to perform those operations at the same time, they'll be queued and only one thread will be allowed to perform said operation at a time. Meaning that they'll be effectively working in an equivalent of single-threaded mode - one threads does the work, the rest of them wait.

 

Interesting can the basic actions needed for a game engine be made thread safe?

Most of the time we are only:

• Manipulation Vector3/Quaternion values that are then passed back into the engine.
• Responding to Events timed/inputs/physics collisions that cause us to trigger actions e.g. Particles/Sfx/Transforms/Physics.

Making a game thread safe would simply by categorising these areas and making their interfaces atomic.

Within a frame you take the old data and events and output new data to the engine.

Maybe some way to cluster linked components to the same thread e.g. A player in a mech, a player's gun or a group of enemies.

I just think it's an interesting problem.

What if Unity introduced a thread safe Action / Event model where events are light enumerated thread safe elements that act on components triggering Actions which are atomic and can only talk to other components via events?

 

You'll need to program the whole game engine in a strong functional language where no side effects are allowed. That'll make it thread safe. It may not make the game any faster though. It can actually make it much slower. Ideally you'll also want to rewrite OS and graphic API in the same fashion.

Basically, if you propose those kind of action on a team, expect your programmers to quit, or demand x10 salary increase, because asking to rewrite game engines to use only atomic operations and/or to utilize languages where no side effects is insanity.

------

On related note, the world woudl become a slgihtly better place, if you stopped chasing buzzwords and concentrated on making games.

Your demo in last year's january jam demonstrated that you have some potential as a developer. Instead of pursuing that potential, you threw it all away and spent the next year of your life chasing unicorns, looking for miracles and getting fascinated with buzzwords.

This is truly depressing.

 

For what purpose? You're still skipping the justification and jumping straight to "WANT" under the assumption that it must be better.

There are reasons (which I've already described) that APIs like the .NET Framework have separate thread-safe APIs that mirror non-thread-safe APIs. For example, System.Collections.Concurrent. You don't use this stuff unless you absolutely need it.

And you probably don't.

 

Threading is a pain to deal with. I like Unity's current approach, everything that can be threaded sensibly in the engine is going to threads. But we just get a single thread to manage.

You can still spawn your own threads where it makes sense. But we don't have to when it doesn't.