Refactoring joints

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Refactoring joints

Postby Julio Jerez » Sun Mar 18, 2018 11:30 am

ok I added the pull request, I see a bunch of joint what I am support to do.

there are two tha are kind of dancing in the center, but I do not know what it means.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby JoeJ » Sun Mar 18, 2018 11:56 am

It's that twist swing decomposition we've already tried for inverse dynamics but did not work, then it turned out you've messed some things up and reverted back to december version.

So this joint can serve as a template for your inverse dynamics ragdoll joint, supporting any motor rotation and also limits that can represent any human joint. E.g. the ankle joint which can turn up down widely, but left right only a bit - you can't represent this with a simple cone, but with a cone sliding over an arc.

I've added those various test cases to make it a hinge as well, test motors limits at the same time etc. to see if it's stable.

The two dancers are one using my old joint where rows are aligned to acceleration, and the other using new twist swing decomposition where rows are fixed so suitable for inverse dynamics.
We where worried misaligned rows and acceleration would affect motor speed, but turns out it works all well... remember?
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Refactoring joints

Postby Julio Jerez » Thu Mar 22, 2018 2:38 pm

Hey Joe, I now have the parallel solver working.

if you sync, the test you will see will no mean much, and It all other demos may malfunction, this set to force to call the parallel solve with that simple stack. and check is stable enough.
bodies are not going to sleep, and to my this is sufficient to warrant continjeing developing it.
The big diffrence with prevois solvere is that thsi sone does no requyired a pre collising pass over teh joint array to find teh set that can be solve in parallele in diffrent thread.

The convergerence rata si definitklley lowe that teh sequacial solver, however we already took care of that by assigning improtant contact to be solve exatly wi eth excatc solver.
'for exampel a car or a tack will tak teh contact with it and solve then exactly,

wh eteh paralle solve will so is that It will deal with massive joint set in singel or multiple island, and we can make up fo teh converege by adding more passes fi we need too.

The solve si a striiped down version fo teh odl solve, it does no deal with CCD or sleep oa anythong liek the sequential solver, is just a brute fore many thread joint crunch solver. so it will goes to the maximun numbe of passes.

My analogy is like a express subway in Manhatan, teh have thsi traing that until stop a some specific tation, an dteh have local traing that stop at every station.
if you go from, Long Isaln to the Bronx, it take you 4 or five hours if you take a local train to teh near stop, teh a express, the near close to teh destination and anoteh local to you final, it take problably 45 minutes.

The parallel solve will be liek that, a prepresess face will combine domb joint and make a singel large island, it will filet CCD, smal isnald at rest and stuff liek that, the I wuill sove all smal isnald calling sequential solve, and on lareg island with parallel solver.
This is not done yet, it is still working isnald by island, but that easy to do this weekend. for now I will test more and make sure is stabel and rubust.

Her eis teh godd thong Joe, thes solve can work In hight performance computing, take for example my machine at home, it is and I7 7700, it come with an enveded GPU that if I god to the bios, I do not need a descrete GPU.

It seems that fi we try OpenCL again, we can make this system use these enveded GPU and APU as amtha comprosessors.
The GPU is my cpu is a The HD Graphics 630, the review aren' clear but some say it has 24 compute units and other say 48, whatever that number is, is a hell of a lot more cores than any 8, 10, 16 cores in the CPU. even if is runs at half the speed the mass calculation is worth trying it.
these are DX12 class GPU, so they must be fast.

I figured that if the OpenGL driver let you use the embedded GPU as a coprossesors, amost any system out there has one of these. and the driver probably take advantage of the memory configuration, so maybe there is not the kind of stuff people have to do when using discret graphics.

I know for a fact that is consulse this PCI bus limitation do no exist, because the memory is unified.

anyway if you sync you will see a stack of 20 boxes standing solve using the parallest solver.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Thu Mar 22, 2018 2:46 pm

edit:
there seem to be a bug, I see jitter when adding many thread and not jitter when using one thread.
Ther have to be a race condition some where, I will debug it.

edit2:
and there is one more thing Joe, this solver can be made if we are willing to scarify some small performance, so people who are doing server physics, can use a systems with any number of cores to do the physics and it will all be deterministic. even on GPU, you can get say a Titan car with 512 cores do to server physics all guarantee deterministic.

this deterministic functionality is a nice features because I am using for debugging race conditions. Basically I can runt on instance of the demo with one thread and One with more that one thread and compare results a some check points, and find where a condition is causing divergence.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Thu Mar 22, 2018 3:37 pm

alright I narrow the jitter bug, it seems to be a global in the dgWorld, I will debug it tonight.
but yes determinism makes debugging a one hell of a lot simpler. so that a win already.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby JoeJ » Thu Mar 22, 2018 5:47 pm

Julio Jerez wrote:let you use the embedded GPU as a coprossesors, amost any system out there has one of these.


Unfortunately many of the 'better' CPUs with many cores never have a built in GPU. (any CPU with more than 4 cores.)
But it would be great if you can test this out, I'm very curious about that.

There is this new NV raytracing stuff, and it seems this contains interesting new compute options: Presistant threads seen in Cuda, Device side enqueue seen in OpenCL 2.0 and Mantle, and probably more fine grained stuff to break GPU limits. I hope the focus is on that and not at fixed function raytracing...
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Refactoring joints

Postby Julio Jerez » Thu Mar 22, 2018 6:01 pm

JoeJ wrote:Unfortunately many of the 'better' CPUs with many cores never have a built in GPU. (any CPU with more than 4 cores.)
..

What do you mean, my own system has a gpu in the cup, it even has two HDMI outputs in the motherboard for video.
As far as I know every laptop, has a buil it gpu integrated in the cup, wether is an intel or a amd, with and been better than intel.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Thu Mar 22, 2018 7:25 pm

Ok now I found the race condition and fixed temporarily, and now that 20 stack is solved in parallel using for threads.

The idea Joe, is going the opposite direction that everyone of going, we will have a joint solver that is expensive because is does all the work that is nee to do to get an exact solution.
then the inter joint integration which is the residual if the general mass matrix, is solve interactively and it is here when we will use as many cores as we need and as many iteration as we want.

in an essence the joint solver now can be seen as a compute shader, and is this property that makes this solver suitable for GPU, of any kind of high performance computing.

This property also open the door to the simulation of different body types, we already have the articulated bodies, but we can now add particles, and stuff like ropes that has spatialized solver and it will integrated nicely with rigid bodies.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby JoeJ » Fri Mar 23, 2018 2:35 am

Any Ryzen (up to now) does not have a GPU, but there are upcoming APU variants (Raven Ridge) with 4 cores + GPU.
For Intel it was similar, only recently when they introduced mainstream 6 cores, some 4 cores have been built with iGPU. Many older i7 don't have iGPU.
There is no CPU from any vendor with more than 4 cores AND iGPU, pretty much sure of this.

So you can't rely upon most gamers would have an iGPU, and this is unlikely to change. You need to deal with the latency to use discrete GPU in the common case.

But i agree, using iGPUs for physics looks very attractive and is worth to try.
It may happen that performance is disappointing or even slower (using GPU also reduces CPU clocks and bandwidth is shared) - then we would see it from a different angle anyways :roll:

Ah - forgot, Vulkan seems to already support OpenCL kernels, or at least it's planned. This makes OpenCL more attractive: Physics shaders could run async to graphics with some extra work from your users.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Refactoring joints

Postby JoeJ » Tue Mar 27, 2018 1:58 am

JoeJ wrote:There is this new NV raytracing stuff, and it seems this contains interesting new compute options: Presistant threads seen in Cuda, Device side enqueue seen in OpenCL 2.0 and Mantle, and probably more fine grained stuff to break GPU limits. I hope the focus is on that and not at fixed function raytracing...


After downloading the SDK i know more: It is fixed function and there is no update applicable to GPGPU.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Refactoring joints

Postby Leadwerks » Wed Jun 20, 2018 4:52 am

Is this stable now?
User avatar
Leadwerks
 
Posts: 569
Joined: Fri Oct 27, 2006 2:54 pm

Previous

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 11 guests

cron