GDC 2022: The Future of .NET and Unity

Any reason for the delayed release of the recording?

 

Thanks for your reply. I'm really excited about this talk.

 

Well, GDC is/was selling online-only tickets, I guess it would defeat the purpose if we got the content for free right away.

 

Oh, completely forgot about that

 

Has a blog post or other summary been released that covers the content of this session for those of us not attending GDC this year?

 

To quote JoshPeterson

 

@JoshPeterson Any update on the blogpost / recording?

 

Thank you! That's perfect

 

I know it's not your responsibility, but you may be able to reach the people, who are... please stop posting your videos 'unlisted'. It is extremely tiresome to hunt down various Youtube videos on various websites. We could just open up Unity's Youtube account and see all the videos... Unity lately is submitting everything unlisted and hide videos on landing pages. I know, marketing and all, but I'm sure there are better solutions for this.

 

All Unity @ GDC talks:
https://www.youtube.com/playlist?list=PLX2vGYjWbI0TMJrYFmLi-inr7DiIkGO4W

 

@JoshPeterson Thanks for the great talk!
One of my questions is that the current serialization and domain reload process does not scale very well with the growing number of packages and tools built with managed code. It's painful to work on large complex projects with a lot of package dependencies. Will things get even worse after the introduction of NuGet packages and msbuild? Do you have a plan to fundamentally change the reload process so that we can have significantly faster iteration time?

 

The answer is AssemblyLoadContext:
https://forum.unity.com/threads/unity-future-net-development-status.1092205/page-17#post-8060684

It's still in the prototype phase, nothing guaranteed, but it's looking great on the paper!
Imagine you're working on the big project and change something in the Assembly-CSharp.dll, since nothing depends on it, all you need to do is to reload that

When working on something else (e.g. you modify script in some package), it will reload more assemblies, but it's shouldn't be that common and for an occasional bug fix it's fine. The most important thing is that Unity assemblies doesn't need to reload ever (in ideal case).

 

Great talk!
I really hope we can see some of that bright future soon.

 

Awesome @JoshPeterson! I wish you all the best for the transition. The engineering team has to move some mountains, but it will be for the greater good!

 

Hi @JoshPeterson, loved the GDC talk and this all sounds very exciting for the future of Unity.

During the talk, around 13 minutes in, you describe a custom in-house marshalling layer for C#/C++ interop for the engine layer, with advantageous performance characteristics compared to P/Invoke. Are there any plans to expose this kind of interop to users of the engine? I often use native DLLs in my projects and being able to benefit from Unity's own improved native interop tools would be very helpful.

Certainly that mixed mode debugging sounds like a huge improvement if it works with user-provided native (Rust?) DLLs.

 

With new C# versions, you'll be able to use IL instruction

Calli

indirectly. The feature providing this is called Function pointers and is available in C# 9.0 draft. On top of this, you'll be able to suppress GC transition when making unmanaged call.

These two features can get you as much performance as possible when calling native code.

Btw, Calli was also used looong time ago by @xoofx when making SharpDX.
At that time he didn't have compiler support for Calli, so he used DLL patching or similar method to sneak that in.

More information here:
https://docs.microsoft.com/en-us/do...erence/proposals/csharp-9.0/function-pointers

 

Hey,
I have been using Rust in Unity for a long time now, mostly with a custom library loading layer. It works really well, and I enjoy it a lot because of Rust itself and the highly improved performance over Unity C# (sometimes orders of magnitude faster). We also investigated ways of automated real-time bindings generation with Code Orchestra. We were able to seamlessly integrate C# into C++ code (with bidirectional bindings so that C++ can interact with code written in C#) and Rust would have been the next target. The same technology could be adapted to work in Unity.

Here are some demo videos of the technology in action:

I have also been working on the Cinematic Rendering Pipeline (CRP), which is a massively enhanced version of DenseLOD (which was mentioned on the forum a while ago: https://forum.unity.com/threads/so-nanite.889714/page-3). It is a fully custom DirectX12 rendering engine implemented in pure Rust and a rendering backend abstraction compatible with Vulkan. The DenseLOD part is essentially a Nanite-like technology for rendering an infinite amount of geometry. The second-latest iteration of CRP easily managed 100 billion triangles, with the latest version being significantly faster but still unfinished. The other major part is a custom light pipeline with real-time global illumination and support for the latest ray tracing features. Since CRP is implemented from scratch and highly decoupled from Unity itself, it could be used anywhere and is also not limited by what Unity supports but instead by what the latest DirectX/Vulkan features are.


We are happy to cooperate with the Unity teams regarding the use of CO in Unity to provide first-class support for arbitrary languages or CRP to provide next-gen graphics without sacrificing performance.