@alexx999_ sorry for the delay, will have a poke around your draft PR now!
@alexx999_ sorry for the delay, will have a poke around your draft PR now!
Abtw, I can prove that moving structs is not a breaking change
Khate to brag, but 14 lines of change to go from empty struct to struct with full member functionality https://github.com/dotnet/Silk.NET/commit/f948995066801ddd53b0cc9d8363f1ca84c18485
Don't think I've ever managed incremental dev to this degree
Don't think I've ever managed incremental dev to this degree
KAlso sleepy brian messing up indent and intend again 
Psleepy brian
Lwho
K as you can see, I'm sleepyKHi Sleepy, I'm brian
Lhi brian, im dead inside
Pbyeee briann
A@Perksey namely, struct names doesn't really matter because extensions are broken - you cannot use GetProcAddress for OpenCL
and if you can't use any extensions with Silk then it's not a breaking change to break them
and if you can't use any extensions with Silk then it's not a breaking change to break them
Phow are extension functions even loaded then
Pthat was the best guess i had at the time
Ayeah, that's the funny bit: even the official Khtonos ICD dll (that I'm using) is not exposing cl_khr_icd extension method (clIcdGetPlatformIDsKHR) which is literally the only feature this DLL has
Aso you must enumerate platform objects and then query extensions per platform
Ait's done this way because each platform may reside in separate standalone .dll
Pyeah course, like vulkan
Pughhhhhh
Pwell we can do what we did for vulkan and have a TryGetPlatformExtension
Panyways, i want to curl up in a ball in bed now, so putting the laptop away for this evening
Ayeah, that's what has to be done
Aand a different NativeLoader impl
AI've even tried on Linux machine and it's the same - extension entrypoints aren't exported
soooo breaking changes to extensions are 100% fine - no one complained about this so no one is using them anyway
soooo breaking changes to extensions are 100% fine - no one complained about this so no one is using them anyway
P@kaijellinghaus what do you feel about the above
KIf it 100% didn't work before no reason to ensure that it stays that way
P@alexx999_ ok cool, you've won us over on the struct package refactoring
ALOL
Pbut i think on the enums front we'd probably want to generate overloads on top of the naked
uint typesPwhereas rn they just get mapped directly to the enum type
Pwith the only exception being cases where the enums are not 32-bit, we can just map those willy nilly
Awe circle back to the problem that not all enums are uints, and having CLEnum64 sounds a bit... over the top
Pyep, i agree. i want to phase out CLEnum tbh in favour of new overloads/completely refactoring the signature where it's just broken so far
Aand having some one way and some the other is... very inconsistent?...
Pit's about not breaking where we're not already broken
Athe extensions are transparent, and having uint CLenum extension overload over ulong native enum is fine for the most part
Ptbh rn i'm leaning towards just merging as is and then adding overloads for bits where we don't want to break.
Pthe struct stuff is pretty much good to go as i see it
Abtw, I have one more idea (breaking)
Awhich is, have typed, ugh, "object handles"?
Awould be handy to have "Device" struct that will be only accepted by "clDevice...()" methods
Anow it's nint which is nice and all but not helpful, I had a bug where I passed wrong nint to the method and it... partially misbehaved? Like, no error just wrong result, very "fun" to debug
KI think done with struct layouts (pending review) and will start working on the Scraper now
Fnot sure if you're aware of this by now, but
osx should be a valid runtime identifier for fat libs (x86_64+arm64)
Psee also help-and-questions
Vroeyskoe#4938
I just tested with my M1, and actually I need to fix my pr a bit. For some reason the
osx folder only works with an Intel Mac, on M1 you need to use osx-arm64.Original Message
Quoted by Perksey#6579
Tjust look at how SkiaSharp does it
Pno thanks
Pthis isn’t even my code/library
PI don’t know why I’m hearing about it haha
Finteresting... can someone link the PR? we've used
osx and managed to publish and have a working native-library nupkg using it so farPI suppose our loader could just not account for it, but that’s unlikely