57 Replies
damn that's ugly
i don't even understand why the static method does 3 calls
what are the implications of using
Unsafe.As
instead of our as thing1. speed
2. nothing else as long as the IVTable is always the correct type
which it seems to be
but if it's not
how does it blow up
right now we just get a NullReferenceException
i think you get a runtime exception
unrecoverable
would possibly be safer to store the, in this case,
_B
type inside Vk
directly
instead of accessing base.CurrentTable
It can't
Unsafe.As just isn't available
strongly typed field in
Vk
it isYou should really look at the disasm using disasmo or similar, it will show you much of that is the GC transitions
I would, but I can't cause backwards compat
oh? how would this affect compat 👀
Well, there is an interface, or there used to be. You can or could change the underlying caching strategy
We can't just remove it cause breaking
how could you possibly change the vtable if every call expects a strong type anyways 🤔
You really can't anymore, iirc I couldn't convince @Perksey at the time
well yeah, it will just nullrefexc now
we can have a strong typed protected field so long as assignment in CurrentVTable is checked
and then Unsafe.As at call site
i'm happy with that
you can't replace the _B type though
i know, but back compat
See https://discord.com/channels/521092042781229087/587346162802229298/749748329612836965 for the original asm after I optimized it the last time
interesting
The logic is that we'd rather have someone report they are getting nullrefs everywhere instead of it just failing to load and we have to figure it out
I could probably invest some time in this, but I'd rather build the direct call stuff that will ship in 3.0
yeah i would leave this opt as community-only
Cause given the new abstractions + partitioning we can get the preload asm I linked above, which is still a good amount better then the other one
pfft i would rather have 3.0 magic
And for some (especially Vulkan) functions we might even be able to skip transitions, which would result in the literal best asm possible
still in design!
We should make a notebook somewhere with ideas
just put a note on the 3.0 tracker 😛
Not detailed enough
you can have big notes now
Might start a wiki folder or something
Markdown??
yep
Oh that is cool
Time to write
so yeah i think i'd be happy with
and then using
_b
in codegen
or at least that's the only way i can think of in a non-api breaking way
(can't just make the property abstract because that's a break)yeah looks fine, shouldn't break it more than it already is
This is wrong cause we still allow swapping the vtable to a new one with the same type using CreateVTable
(this was a feature that was very important to you, I still don't know why, but hey it exists for a reason I guess)
the _B type is private though
But CreateVTable sort of exposes its constructor
then it could still sort of be a strong type _B field in Vk 🙃 /S
that will continue to work, the public API will continue to work as is but just blow up at assignment time rather than call time if you pass an invalid vtable
mainly for Vulkan and OpenXR for swapping out device and instance vtables. see CurrentInstance and CurrentDevice for more.
if you wanted to implement this i'd be happy to accept a PR for this change
Ngl good luck you'll need it
Maybe I can have a look later 😅
sounds like joy, especially on a 8GB laptop 🙃
just do
nuke sln --projects silk.net.vulkan
and it'll create a solution with only the projects you need, which by my count is just 4 projects
(nuke sln --projects vulkan
would load all of vulkan + extensions, so probably don't want that!)do extensions not need fixing? do they all use the same source generator
they all use the same source generator
relevant links are:
- https://github.com/dotnet/Silk.NET/blob/main/src/Core/Silk.NET.SilkTouch/NativeApiGenerator.cs#L414
- https://github.com/dotnet/Silk.NET/blob/main/src/Core/Silk.NET.Core/Native/NativeApiContainer.cs#L32
- https://github.com/dotnet/Silk.NET/blob/main/src/Core/Silk.NET.SilkTouch/VTableGeneration.cs (probably won't have to change this one)
- https://github.com/dotnet/Silk.NET/blob/main/src/Core/Silk.NET.SilkTouch/NativeApiGenerator.cs#L253
also looks like CurrentVTable isn't settable, so forget about
SetVTable
and just make SwapVTable
virtual insteadso how would i go about debugging the source generator? 👀
CreateDefaultContext is missing 🔥
so there's a commented out WriteAllText line in NativeApiGenerator, you can use that to get outputs
CreateDefaultContext is missing 🔥that's a source generated method, so it's probably a silly IDE warning
ok i got a "launch debugger" prompt out of nowhere
that's.. odd...
unless you put one there
was here in VTableGeneration
........................................
that was me
fuck
well there you go that's how you debug the source generator lmfao
feel free to move that to here (the start of source generation) https://github.com/dotnet/Silk.NET/blob/main/src/Core/Silk.NET.SilkTouch/NativeApiGenerator.cs#L32 (but really it should be commented out when not needed)
i usually add a
DebugAnalyzer
configuration to my projects and #if DEBUGANALYZER
that sounds like a much better solution
the silktouch.lock thing is so we don't get spammed with debug prompts
as we have a lot of targets and tfms etc
i could make two PRs
hah, however you want to do it. we've (kai's) seen it all
maybe a lock file that deletes itself after program exit 👀
too bad the compiler is a long-running process
does nuke read configurations from the Silk.NET.sln?
yes it did, great