#Need help understanding passing data to and from jobs + NativeArrays
1 messages · Page 1 of 1 (latest)
Sorry btw I realized my question doesn't really ask anything specific...
I just want to make sure that my jobs process it and update the info, I don't want it to be temporary
Afaik native arrays are practically just pointers to a block of memory with some safety attached.
While they're a struct, and their value is copied when they're passed around, it's a pointer, so it's still pointing to the same place where your data is stored
Native collections are the only way (outside of ECS) to get data back out of jobs
Okay but there is something that confuses me a bit Vertx, so outside of the job, if I try to do for instance... an array of colors
colourArray[i].r = 0;
Fails because it says it's a temporary value?
color.r *= AntSettings.current.trailDecay;
pheromones[index] = color;```wonder if I am meant to do something like this or not
The struct you access via the indexer is a copy, so you have to set its value back
So like the code I showed prior?
Yes
Okay so the general concept is that I want to pull data out of it, work on it, then set it back
Yes
Oh... I think I'm starting to understand this... This reduces the amount I work on the source (memory) to prevent constantly writing to it so that multiple jobs only update it when they are finished?
I could be wrong there Vertx, I am stretching haha
Why there's value in it being a value copy in the case of array is kinda out of my expertise. But I think it's a safety thing where if you could modify it inline then it would have to be a reference, and that would mean you could use the struct outside of the lifetime of the time it's allocated for.
Why there isn't a way to selectively do stuff via reference in a very small scope, that can be safely inferred, no idea.
Okay, at the very least I think I'm starting to understand it, I appreciate it greatly thanks
It's been really hard navigating the docs and manuals with all the fancy memory talk lol
So inside my IJobFor, at the start of execute I do
AntDots ant = ants[i];
And the end when I'm finished I do
ants[i] = ant;
And this is how I handle getting data? to sum up the answer to the original question
Wait, I duno if that's right because I did [ReadOnly] on it
Yeah, or you can just
ants[i] = new AntDots { ... };
if you're just creating it all in the job
If you're writing to the collection don't put ReadOnly on it, otherwise, sure
The thing is I am processing like 2000 ants and I think if I am writing to it in every job, it's going to be really taxing on access safety
Also, if you want to get a single value out of a job there is a NativeReference struct in the collections package which is just a nicer wrapper for an array of length 1
JobHandle antJobHandle = antJob.ScheduleParallel(ants.Length, 64, default);
This is the job call for instance
Which is why I get so confused.. it's that multithreading support that trips me up when it comes to letting all the jobs access it and update it
Does that make sense? I was thinking there would be a way to do it where the structs are independent updated and each task is changing that ant without changing the array
You can read from any index in parallel, you can only write once to an index in parallel, but that's all of them once, so there's no issues with you writing to every index once.
Oh well that sounds awesome, my limitation are on the index and not the array as a whole
Yup. If you can't make that happen then your logic may need to be split into steps where you collect the data, process it, and reorganise it so it can be written out properly
Would I be best marking it as [ReadOnly] if I can guarantee that each index is only ever updated once?
No my system is designed for each index to be completely processed in 1 job
[ReadOnly] should be added to things where you only access values
Basically 1 task per index job
If you're writing to the collection, do not put ReadOnly on it