Concept Unity CPU Driver...

What if Unity could add a CPU Driver into a Unity game to boost it's performance on new hardware?

Unity has been working hard on DOTS/Burst/Jobs to boost our games performance, but the technology is not product ready yet.

In addition the optimizations that Unity can deliver today may not be the fastest available on tomorrows CPU hardware (big / little cores, new SIMD instructions ).

If CPUs had a Driver just like GPUs that could allow older games/apps to take advantage of the latest hardware features ensuring they get the best performance available.

Unity could introduce a "Driver" into the engine that ensure any Burst/DOTS/Jobs code takes best advantage of the hardware latest features e.g. latest SIMD instructions, Jobs allocated to more cores or big jobs to big cores and smaller jobs to little cores.

With Unity's work on DOTS and Burst in theory a Unity CPU Driver could even boost none DOTS games.

I imagine it would work by checking the game/app to see if boosted code exists specifically for that app and if not scanning the app/games code for hot regions that could be boosted then storing those boosts profiles for next time. So a small slowdown when loading new apps but it should be made up for in the performance boost achieved.

 

How is this different to a VM?

 

There is a much more resourceful approach to this: Use the IL2CPP backend: https://docs.unity3d.com/Manual/IL2CPP.html
This means your C# scripts are converted to C++ code which then is compiled to assembler with an actual compiler for the target architecture. That compiler does exactly that: Chose the most efficient code for the target architecture.
Keep in mind that no CPU executes C# code. Not even Burst code. It all comes down to some form of assembler.

Btw. while DOTS is still under heavy construction, I'd say Burst, the Mathematics library and the Job system are certainly production ready.
They might not cover everything (would still love some mesh manipulation ) but for several versions, the APIs have barely changed, so it seems you can rely on them. What makes you think otherwise?

 

Ummm... what? I fail to see how unity maintaining a driver, no less for the CPU of all computer components could be anything but a seriously bad idea at best, and a waste of resources and sure to get killed project at worst?

I am curious, do you actually understand how drivers work and the work that goes into maintaining them?

How would this make anything more "product ready" than the products already in development that have a lot of resources thrown at them and spread thin in some places already?

I mean its an interesting point for conversation ofcourse, but it makes absolutely no sense in any practical world except an extremely hypothetical one where CPU drivers are powered by magic and developed in a single afternoon by one guy, and require next to no maintenance afterwards...

Thats before you even factor in the extreme risk that drivers bring. You can seriously adversely hurt as much as help with a driver, and no driver is perfect for every product. This at best would make some games work better and a lot of games work worse / stop working / introduce hard to fix driver-level bugs that a developer can no longer do anything about without the help of the driver maintainers.

 

This is effectively what compiling to a native binary is, which is what IL2CPP already does.

 

Compiler technology is updated constantly to ensure developers can take advantage of the latest instruction set from the latest CPU's but it cannot update the code it generated for older software.

• A CPU driver could allow older games to take advantage of the performance of new hardware as soon as it is released.
• Just like GPU drivers popular games and apps could see performance improvements from driver updates.
• The CPU driver would be built and maintained alongside compiler technology and save programmers from having to re-compile older programs every time a new CPU drops.

Lets face it your latest game is already getting old and newer hardware is already on the way with better features your game cannot use.

Or what if the latest DOTS/Bust/Jobs performance advances could with a Unity driver update allow all your current games to gain in performance.

Actually could the more modular Unity Engine be made up of Drivers that govern aspects of our games that then could be updated as performance/hardware improvements allow?

 

Compilers are updated constantly to make better use of existing instruction sets, not new ones. On top of that, any performance gains would effectively be lost in the virtual machine system you are effectively proposing. This is a non-starter of an idea.

 

That's not how ""drivers" work.

Some of what you describe (adapting the code for the CPU) already exists: it's called JIT and it's how Mono and DotNet work, for example, where the IL bytecode is turned into machine code at the user machine.