Meetem

C# lover and Unity Performance Maniac. | 🇺🇦 переможе | Cutting milliseconds for money |

[Meetem @Meetem4]

DX12 Bindless Plugin for Unity3D is now open source, and you can use it in your projects! Can be useful for writing a custom GPU Driven Renderer. (github below)

[Meetem @Meetem4]

@andrewlukasik @s4schoener That's really easy to implement both in real dotnet (since unity is moving to coreclr) and in mono

[Meetem @Meetem4]

@s4schoener Ideally it's done with ILPP patching, so Burst just casually calling C# delegates. Good stop is somewhere in the middle, like that:

[Meetem @Meetem4]

@s4schoener I do that quite a lot, instead of using those handles I prefer to make an ManagedField struct with the same logic + pinned handle, because in that case it's possible to call a C# callback accepting a reference.
One of the prime cases were calling EventWaitHandle from Burst.

[Meetem @Meetem4]

@BoganBits @KostasAAA Is it also applicable to bitshift POT division and multiplication? Or other bitops

[Meetem @Meetem4]

@yak32 @playcanvas That’s really good, you just have to bake lightprobes so dynamic objects will match the scene lighting! Amazing!

[Meetem @Meetem4]

@andkalysh Very nice job! Where can I read more about that implementation?

[Meetem @Meetem4]

That’s true. I’ve asked Josh Peterson if they will remove compacting from GC, and he atm told no. I think I would’ve just remove the compacting entirely and it’s quite easy to do in coreclr.
On IL2CPP perf though I don’t think IL2CPP will beat coreclr nativeaot in all the circumstances

[Meetem @Meetem4]

@SebAaltonen Interesting, last time Ive checked structured buffers in Compute pipeline they were a little bit faster. Probably they are using a different path in compute. Interesting why is that.

[Meetem @Meetem4]

@SoftEngineer Ah, Ive got it. I did something similar for Unity implementing NICE filter on gpu. Constructing a little smaller kernel and take max(currentMip-3, 0) as a source

[Meetem @Meetem4]

@unitygames Will runtime be opensourced and easily recompilable as an original dotnet repo?

[Meetem @Meetem4]

@RED_SIM Oh wait so basically it’s the CHAIR being baked? :O
And the whole world too and then you intersect them?

[Meetem @Meetem4]

@richgel999 This is huge! Congratulations’

[Meetem @Meetem4]

@Mirko_Salm Probably just use SH? I haven’t even knew they’ve patented that!

[Meetem @Meetem4]

@AlperenAkkuncu We became closer to God. E.g. to the glass weights and lightspeed inference

[Ереванский Лесной @ivan4th]

Продолжая тему взвешенного подхода к использованию AI. Наткнулся тут на интересную заметку - "Breaking the Spell of Vibe Coding". Довольно интересный текст о рисках бездумного вайбкодинга. Всем разработчикам (и не только им, конечно) известно понятие flow state ("состояние потока"), то самое, когда хорошим программистам удаётся "своротить горы". Автор статьи рассматривает вариант этого состояния - dark flow, типа того, что испытывает лудоман, взаимодействуя с игровым автоматом, и утверждает, то же самое человек испытывает при вайбкодинге - когда ты вообще не смотришь на результирующий код, но крайне увлечён реализацией своей наверняка великой идеи. В результате такой работы получается "дом на песке", некая конструкция без внятной архитектуры, с кучей воркэраундов и багов, разваливающаяся под собственным весом по мере роста объёма кода. Примерно тот же результат, если вдуматься, что и у лудомана с голой жопой и коллекторами у входной двери.
Думается мне, что что-то в этом есть.

[Meetem @Meetem4]

@James_M_South Getting a better performance for drawing is usually simple, what’s complicated is getting results back without a huge delay from GPU while also maintaining the frontend similar to CPU

[Meetem @Meetem4]

@unitycoder_com Yeah funny thing they are still using cpu to submit drawcalls, and only sub cull draw calls with occlusion culling. Sorting/filtering is basically impossible to get done on gpu with the current API design. At least when I checked it (~half year ago)