https://github.com/Meetem/ILCall

ILCall is now released at version 1.0.0 🎉🎉
You can make your IL additions by using provided sln to generate new ILCall.dll.

Binaries could be found in "Releases" section on GitHub.

A little example on how to use IL to our profit and how to overcome C# limitations.
In this case I'll show you how to call an arbitrary function by a pointer.
https://meetemq.com/2023/09/06/saddling-up-il-to-our-benefit/

An article on getting field offset of struct or class object, and how to make it cross-runtime, so it works in Unity (Mono/IL2CPP) and real dotnets.

Field offsets are good stuff to read/write fields without incurring into reflection, so we can avoid TypedReferences (not supported in IL2CPP) and also we avoid GC allocations for fieldInfo.SetValue(object target, object value), if both target and value are structs that's two boxing operations!

Let's dive in!
https://meetemq.com/2023/09/10/nets-fields-and-their-offsets/

How do I know if I'm running under Mono or .NETFX, or may be Burst, should I say .NET Core?

Here's how you can tell it at JIT/Compile-time!

https://meetemq.com/2023/09/12/detecting-net-runtime-at-compile-time/

Запустил стрим, подпиливаем и пересобираем dotnet-runtime, буду юзать его для кастомного движка в поддержкой шарпа

https://www.youtube.com/live/U57DD1g6_nA?feature=shared

Тестовый стрим имхо прошел не плохо. Правда задачу решить не получилось, буду дальше думать))

Раз уж сегодня пятница, вечером в 19:00 МСК проведу стрим с ответами на вопросы. Буду рад ответить всем. Вопросы можно задать в комменты под постом, или прямо на стриме.

Наверняка у вас накопилось много вопросов.
И вот вам стрим где все можно спросит. Вопросы в чат на ютубе или в под этот пост. Начинаем через 5 минут.

https://www.youtube.com/live/Oy2LpjdmjFg?feature=shared

What we will get when Unity finally implement .NET Core?

Short comparison of the new .NET 8.0 with Burst in terms of runtime performance.
Spoiler: .NET IS AWESOME!

https://meetemq.com/2023/09/18/is-net-8-performant-enough/

Написал статью как работать с классом Gradient из под burst. И в процессе малость охренел, от того что моя реализация метода Evaluate оказалось в разы быстрее c++ реализации.
https://habr.com/ru/articles/761572/

Finally!
There's a new article on .NET object layouts.
In the Part 1 the layouts of:
1. System.Object
2. T[] array
3. string

This article also reveals how to access those types in unsafe or unmanaged environment. How we can change the object type or get array/string length pointer to change it later.

https://meetemq.com/2023/09/27/managed-primitives-part-i/

Через полтора часа начинаем.
Пишите вопросы в комменты под этим или предыдущим постом.

18:00 CET
20:00 Msk
19:00 Kyiv

https://www.youtube.com/watch?v=vTXDPntqs6Y

Все знают что произошло.
Тем кто сочувствует — мои соболезнования. Сам только отхожу.

Сегодня сделаю стрим по обзору Unity Native Rendering Plugin
и ответами на вопросы.

Подключайтесь)

19:00 MSK
19:00 Kyiv
18:00 CEST

https://www.youtube.com/watch?v=XcjNVTHRxqI

Начинаем через 3 минуты!

How to build Unity Native Rendering Plugin for Windows, Linux, WebGL and Android.

https://gist.github.com/Meetem/b8538de3e7800de3242b6e4f830b87c6

Quick overview on using Vulkan-native features in Unity's HLSL:
(bonus point: adding Unsupported functionality in Unity's DXC)
https://meetemq.com/2024/06/14/using-vulkan-in-unity-shaders/

Interseting discovery about Unity when using Vulkan.
See, Vulkan have two entry points to resolve functions: vkGetInstanceProcAddr and vkGetDeviceProcAddr.
vkGetInstanceProcAddr returns functions for a given VkInstance.
vkGetDeviceProcAddr on the other hand returns functions for a given VkDevice OR device child, e.g. VkQueue and VkCommandBuffer.
According to the docs, vkGetDeviceProcAddr is preferred when resolving device/-child functions, because returned address induce less overhead (probably because it doesn't need to resolve the child from VkInstance).

So, Unity requests vkGetDeviceProcAddr from Vulkan (or native plugin if hooked with InterceptVulkanInitialization). But actually never using it.
That means that all of the device/-child functions have an overhead to them. E.g. vkCmd* functions, vkQueue* functions etc. Those functions are actually used with insane frequency, in draw calls, uploading constants, binding buffer ranges etc.

The good thing is that we can reroute vkGetInstanceProcAddr to return pointers as vkGetDeviceProcAddr via native plugin. Which can give potential performance increase when events count is high.

How much performance? Well, you never know before you try. I think for 10K calls, say, on Android it could be measurable, like 0.5ms or something, but that's just my speculation.

VkSharp is out 🥳
Fully-featured Vulkan interop compatible with .NET and Unity Burst.
GC Free (just a couple for initial setup)

https://github.com/Meetem/VkSharp