I was wondering if Burst is friendly with Tuples/Tuple*/Nested Tuples. I like Tuple’s because it creates a visible layout inline. For example;
NativeHashMap<(int bits, (int, int, int, int, int, int, int, int, int) seq), (int count, (int, int, int, int, int, int, int, int, int) seqSwap)>
Seemed to crash Unity when trying to use this method. There isn’t an int8, so I had to go with int2x4
NativeHashMap<(int bits, int2x4 seq), (int count, int2x4 seqSwap)>
Here’s the relevant section in the docs:
Burst supports value tuples
ValueTuple<T1,T2>in Burst-compiled jobs or static methods, but not across the interface to them. This is because value tuples are of struct layout LayoutKind.Auto. Burst does not support LayoutKind.Auto (to see a list of struct layouts Burst supports see the section Struct types).
I had no problem using tuples when they aren’t exposed from Burst-compiled code to the outside. Putting them in a native container may be breaking this promise. (Unless you never access the native container from Mono?) As far as I understand, this is because Burst can’t guarantee that the auto-layout of the tuple in a Burst-compiled context matches the layout used by Mono.
But I think it usually gives you a compilation error when this happens instead of crashing, so consider filing a bug report.
NativeHashMap<(int bits, (int, int, int, int, int, int, int, int, int) seq), (int count, (int, int, int, int, int, int, int, int, int) seqSwap)>
Oh, I’ve been there! Tuples are very convenient, but I find it that when my types start looking like this it’s pretty much always an improvement to just declare a dedicated struct.
Thank you and yes, I should make a struct although then have to set up the interfaces to work with the NativeContainer. This is top level anyway, I’m using the ints as bits because its easier to work on an algorithm, but later probably work with bitshift on a utype which will speed things up, and avoid this issue. But only if I find a working algo! Working with compression, something that fascinates me 