Scheduling jobs from NOT a MainThread

Hi,

I have got a large code base of jobified and Burst compiled physics simulation, which is scheduled from the main thread.

However, now I need to support a use case where I have got a native thread spawned and owned by haptics hardware API, which should schedule all the calculations in sync. It runs at more or less constant rate of 1kHz, which gives less than 1ms to do the physics calculation and send the resulting force-feedback vector to the haptic device (so called "hapitc frame").

@Joachim_Ante , @xoofx I would like very much to reuse my current jobified code, which does the job very well and took me a lot of time to develop. I don't want to schedule/complete jobs from multiple threads, just be able to do this from non-mainthread. I don't need advanced profiler or debugger support.

I think this is not that unusual use case as it is quite common while working with hardware, for example, with automotive sensors. Currently, such use cases prevent the use of JobSystem and Burst, which are great tools

Thank you

 

Hi @Joachim_Ante and thanks a lot for a quick response!

Yes, exactly. I would like to schedule jobs as well as complete them from C# callback(s) on a custom C++ thread.

 

I see @Joachim_Ante . Having a fully deterministic simulation would be great indeed. However, for, now, I am breaking determinism anyways by using [NativeDisableUnsafePtrRestriction] to call native code or [NativeDisableParallelForRestriction] to atomically write to other indices during constraints solving, which is typical in physics simulation.

Taking these under consideration, would it be possible to make a "non-deterministic" job scheduling, which would omit all the main-thread safety checks, in a similar spirit how the aforementioned attributes work?

Regarding Burst would it be possible to get a small code snippet to manually compile and invoke the job? The Burst documentation does not mention this.

Summarizing, job scheduling is more important to me as I have got a quite complex jobified physics solver, which already schedules hundreds of jobs from different sub-systems each frame (collisions, deformation, heat propagation, logic). Burst is undoubtedly great piece of software but, in the worst case, with some extra work, I could port the performance-critical algorithms back to native C++, just the way I did it for last couple of years...

Thanks

 

+1 on this feature very much. If safety system is biggest issue, maybe you could do it without it at first(unsafe) and we would use it at own risk, I mean we're not all children playing in sandbox

 

Disagree. We are more a childs, than other, because we make games If you lost child inside - you can't create games with soul

 

You should see my face when I get a new toy to play around (like ECS, Jobs, new .NET version, etc)... I drop all my matchboxes immediately and jump in the sandbox with drawn toy shovel and bucket, head first.

 

Hi @Joachim_Ante,
I have been developing a workaround for a while. I have modified my physics solver to be scheduled at 1kHz from the haptics native thread. The solver loop runs a bunch of math heavy functions, which I am porting from Jobs/Burst back to native C/C++. However, it would be great not to double the work and later maintain quite complex algorithms in both HPC# and C/C++.

I have tried calling IJob.Execute() from my native callback and it worked fine. Unfortunately, it is not Burst accelerated. The IJobExtensions.Run(T), although the docs say "Perform the job's Execute method immediately on the same thread.", gives exception saying that it has to be called from the MainThread.

I can Burst compile a delegate but I have got no idea how to combine all this with IJob

Code (CSharp):

1.          
2. public delegate void ExecuteJob();
3. (...)
4. ExecuteJob exec = BurstCompiler.CompileDelegate<ExecuteJob>(what should go here???);

So going back to your quoted answer from few weeks ago, could you please provide some code snippet of my own scheduling method? I would appreciate this very much.

Thanks!

 

Hi @Joachim_Ante,

to quickly recap, I have got a heavily jobified surgical simulation system implemented using HPC (JobSystem + Burst, no ECS). It works great with VR controllers input and I am very happy with it. Please have a quick look:

However, now I have got customers, who would like to use my simulator with some more serious, haptic-enabled devices, such as Phantom Omni pictured below. In order to do this, I need to be able to run my simulation physics update at more or less constant rate of 1000Hz to generate realistic and smooth force-feedback.

Unfortunately, it is currently not possible, as Jobs can only be scheduled from Unity's main-thread. I have started porting a lot of performance critical code back to C/C++ to overcome this issue but it is a lot of code and maintaining two math-heavy versions of the same code is rather painful.

I just wanted to ask whether something has changed over the last year in the topic of giving developers possibility to overcome the safety-system and be able to use JobSystem and Burst-compiled jobs from non-main thread?

Thank you

 

Hi @Joachim_Ante, thanks for a quick reply and apologies for delay on my side.

The human haptic perception operates at a far higher rate than our visual system (around 30 times faster).
It is commonly accepted that the required refresh rate to provide realistic force feedback to be at least 1,000 Hz.*

I have already tried what you have described (scheduling 15 jobs inside the graphics frame). This makes sens assuming that I could have the wait period between each subsequent job launch/completion of roughly 1ms. However, in practice, this does not work that well with the hardware, the force feedback is not that smooth and I can feel a small jitter on the device.

To solve this I would need to rather precisely match the hardware timing (its called haptic frame).
Ideally, I would like to to launch burst jobs from the native thread, which is controlled by the haptic device drivers.

I think such use cases are quite common when dealing with timing-dependent hardware. For example, I had similar issues in my previous job in the automotive sector while working with car sensors. If I didn't "tick" them in a given time-frame they were going into error mode.

I am fully aware that Unity is a game engine and not real-time operating system but having a possibility to use such a great tools as JobSystem and Burst for such cases, without the hassle of native code implementations, would be great and enable many more interesting applications in academia and industry.

Thanks!

* “The Role of Haptics in Medical Training Simulators: A Survey of the State of the Art”, T. Coles & N. John, 2010

 

Thanks again for taking time to help me out and quick response.

Yes, that would be already very helpful. I could use some other job scheduler to launch the Burst compiled jobs.

I have found some more info on BurstCompiler.CompileFunctionPointer<T> but, given it's description in the 1.1.1 release notes and some example Burst 1.1.1 new release , I am a bit confused how can I achieve this:

Here is some code sample from my repo with JobSystem/Burst examples examples
https://github.com/korzen/Unity3D-JobsSystemAndBurstSamples

I would be very grateful for some snippet on how to use BurstCompiler.CompileFunctionPointer<T> to launch this job from outside the JobSystem

Code (CSharp):

1. [BurstCompile]
2. struct OceanJob : IJob
3. {
4.     public NativeArray<Vector3> vertices;
5.  
6.     public float time, rippleStrength, scale;
7.  
8.     public void Execute()
9.     {
10.         for (int i = 0; i < vertices.Length; i++)
11.         {
12.             float3 vertex = vertices[i];
13.             float2 offset = new float2(vertex.x, vertex.z);
14.             float ripple = math.sin(time + math.length(offset));
15.             vertex.y = ripple * rippleStrength;
16.             vertices[i] = vertex;
17.         }
18.     }
19. }

Thank you

 

Thank you Joachim! Have a good weekend

 

To be honest, if you trying to control/monitor hardware at such high frequency, you should be using relevant hardware, which does high frequency controls. I wouldn't be calling Desktop as good tool for this nature. It has lots of own internal overheads and risk of instability at such high rate.

Unity should be used more to do visualization HMI, rather than direct hardware control.
I am just not convinced upon using chosen approach, as for surgical precision solution.

 

Hi @Joachim_Ante and @xoofx, I am back to adding support for haptic hardware, which needs to be controlled at the rate of approximately 1000Hz, to my surgical simulation framework.

Above we discussed a matter of Scheduling() a BurstCompiled job from outside Unity's MainThread.

Would it be possible to add possibility to simply Run() it in non-MaindThread? I am fully aware that all the safety mechanisms would not work. Yet still, a vision of maintaining both C# and C/C++ versions of same math-heavy code loom large in my mind... Thanks!