6 hours ago, taby said:

What are static command buffers?

What's the point of using glDispatchComputeIndirect?

Both is about avoiding expensive communication with CPU.

Lets say you have a task that determinates necessary work, e.g. frustum culling which writes a list of surviving triangles, or texture space shading which generates a list of blocks requiring update. Both tasks generate a variable list size each frame.

With indirect dispatch the list size can be used to set the necessery number workgroups from GPU directly, without it you need to download the list size to CPU to generate the dispatch command, and the command needs to be uploaded to GPU. Huge latencies and idle times caused by waiting.

Command buffers allow to store lots of commands (e.g. cull, draw, deferred shading) into a single buffer and upload it just once, so if you do the same work every frame (like in games), you could implement a complete renderer by just uploading object matrices and executing the command buffer. So the whole frame with just one singel draw call, avoiding all costly but useless CPU<->GPU communication we know from the past.

Like said this makes my complex CS project (realtime GI) almost two times faster - the more dispatches, the higher the win.

But unfortunately there is still something missing from both DX12/VK:

It may happen indirect dispatches end up doing zero work. But then expensive barriers are still executed for nothing. Neither DX12, nor VK Conditional Draw or NV Device Generated Command Buffers extension include support for barriers.  Mantle has it, in form of conditional command buffer execution, and OpenCL 2 has it in form of device side enqueue. So i'm begging for that on every opportunity

And the second issue: If you want to use async compute (which also allows to run multiple compute tasks at the same time, not just render and a single compute task), you have to break your nice static command buffers into multiple smaller ones to feed multiple queues. This and sync between queues adds costly overhead, which can compensate the potential win for small workloads where you need it the most.

So what we want is GPU being able to generate its work completely independent from CPU. It's not clear if (or which) hardware could do this already, but looking at other APIs it's certain we miss at least some things.

Ok cool. Thank you for the insight!

There used to be something like static buffers in OpenGL 1.x: display lists.

1 hour ago, taby said:

There used to be something like static buffers in OpenGL 1.x: display lists.

Haha, yes exactly  ... makes me dream about how easy things could be with a 'proper' high level but fully featured API 

5 hours ago, JoeJ said:

Haha, yes exactly  ... makes me dream about how easy things could be with a 'proper' high level but fully featured API 

There is Unity for all of your physics engine needs. Especially there are things called gizmos, which serve as a visualization tool -- drawing spheres with one statement, etc -- without having to worry about collisions or kinematics.

And as for OpenGL 1.x, I still use it as a prototype development / visualization tool. I am fortunate enough to have a wicked code that takes up to 65535x65535 pixel screenshots, for poster-quality graphics. I contemplated moving over to Unity, but I'd miss C++ too much, plus the large format screenshots in Unity are utter garbage.

A sample of the screenshot function can be found in http://vixra.org/abs/1807.0418

4 hours ago, taby said:

There is Unity for all of your physics engine needs

Likely Unity / UE4 are the reason we no longer need an easy API, with less and less people working on graphics engine themselves.

But my physics needs are the first reason i can not use them, because neither allows to replace the physics engine easily. Actually both seem to work on alternatives for PhysX - maybe they take this oportunity to become more flexible here...

4 hours ago, taby said:

A sample of the screenshot function can be found in http://vixra.org/abs/1807.0418

Nice 'debug renders'  Mine look just like this:

Like many i tried to get those mandelbrot spirals to 3D, but failed. So, side question: I guess each of those quaternion escape paths lie on a plane?

This is what happened to me when i tried to replace complex numbers with quaternions: The spiral rotates as a whole, but all the points keep on constant plane so it's still 2D, and the shape does not become more interesting, just stretched and sheared. Likely that's the reason we have no true 3D fractal yet

I think you're right. They don't all share the same plane, but it does look like they're all constrained to a plane.

Yeah, the axis of rotation is defined by the input coords, but does not change in the iterations. Some people even tried octonions, but they get similar results as with quaternion fractals - just twisted or noisy but no interesting details.

Hey, since you know a bit about fractals, I am wondering if you've ever studied the properties of these paths that are created during iteration? I mean, each path has a length, plus a displacement, plus the traditional magnitude. I looked into it a bit, and found that no matter what criterion one uses (length, displacement, or magnitude), the same fractal shape is produced. Do you know of anyone who has worked on this kind of thing before? http://vixra.org/abs/1906.0407

27 minutes ago, taby said:

I looked into it a bit, and found that no matter what criterion one uses (length, displacement, or magnitude), the same fractal shape is produced.

Wow, what an interesting finding!

No, i don't know much about fractals so can't help, but here's what i tried to do, maybe it becomes useful to you some time...

This is an image where 5 spirals form as an example. (So this never escapes and would not contribute much to the final image)

My idea is to form such spirals in 3D space (like galaxies), not just a 2D plane. Just by intuition i assume nice 3D farctals might become possible.

To do this, i'd like to calculate the points where the spirals converge after infinite iterations, marked with hand drawn red crosses.

Then one could perform some transformantions using those points as the origin, and eventually a simple formula could be found to turn such 'constructed geometric idea' into simple, elegant math...

I even found a paper that gave formulas to calcualte those points analytically, but it did not work for me and i don't remember it's title or if those points have been studied / named elsewhere.

(Feels a bit like fractal guys to mathematicans are like game devs to 'serious' software developers, hahaha  )

Thanks. I'm really happy with the result that I found, but I do not have credentials, and so I could not get my paper published.

What you write is interesting, and I hope it all works out for you if you decide to get back into fractals.

Yeah, the most fruitful research in fractals seems to be done by amateurs. Can't get no respect. LOL