Question Is there any Limit to use EntityManager in Bursted Job.

As EntityManager is strcut now, I am wondering is there some limitations when using it in Bursted job.
For example, Is it okay to check Entity's existence in job with EntityManager.Exist?

 

I think that they were changed to be struct to be compatible with the bursted systems that seems to be coming, EntityManager is still main-thread-only AFAIK

 

I tried EntityManager.Exist in job. It works fine. I just don't know if it is expected to be used so.
Structural change commands should only be used in main-thread. that's fine.
For now EntityManager.Exist seems to be the only way to test Entity existence.
ComponentDataFromEntity can be used to check entity existence.
But in my EventSystem, I don't know what component the target entity should have at all. I just need a way to check it without referring to any component type.

 

Did you try with any other Job than IJob? Does Burst compiles and can you actually check for entities existence?

I am not convinced, this is right tool to to check for entities. But maybe it will become right tool?

 

Yes, I tried IJobParallelForDefer. And it works. But EntityComponentStore's safety check is a bit of a mass.
I have not figured out exactly if EntityManager itself has the Safety handle that is needed to check entity existence.
But EntityManager.Exist can be used in mainthread when IjobChunks are on the fly without any problem.
So I guess. it is fine to use it as long as your job is not working across a syncpoint.

pass the jobhandle of the job use EntityManager to the next ECBS should be good enough. assuming all structural change is done in ECB.

 

FYI, EntityManager from SystemBase needs to be cache to a local copy to be used in Entities.ForEach. as all System field is not allowed to be used in Entities.ForEach.

 

I also played around with this a few weeks ago to see what's possible and what's not, since the backend in the EntityManager is largely burst-compatible. Just like Lieene-Guo has experienced, I realized that the Job system allows for bursted EntityManager access as long as you don't access SystemBase.EntityManager in the job. You basically need to either store it in a local parameter or pass EntityManager to a job struct. Here's an example:

The code in the Job is fully burstable. The main restriction with accessing the EntityManager this way is that the Job systems prevents you from doing any structural changes while in a Job. That's simply not allowed, even if the job is executed on the main thread via Run.

I therefore started playing around with the thought of whether it was possible to compile the EntityManager access as Bursted code via FunctionPointers to bypass this Job system structural change restriction. This is what I came up with, and it actually seems to work. The job is burstable and performs structural changes. Not sure how safe or actually viable it is, I just found it amusing to play around with

 

If you mark Entities.ForEach by .WithStructualChange(), using EntityManager structural change commands and burst will work. but still, need to call Run() instead of Schedule().
maybe Schedule() + Complete() is okay.
But I don't think SchechuleParalle() +Complete() works.
ECB will do the job anyway.
Still, I want to know in what condition can I use EntityManager.Exist in parallel bursted job.

 

Unless something has changed recently, WithStructualChange automatically turns off burst

 

That sounds incredibly unsafe. Like, base jumping down a nuclear reactor while high on PCP levels of unsafe. But if you always run that job on the main thread and not worker threads, it'll probably live.

 

What a ride hahahahahahah xD