Performance overhead of managing floating-point hardware
lukego opened this issue · comments
The viewport became sluggish when I setup a scene with 1600 cylinder meshes:
(with-clear-scene
(dotimes (x 40)
(dotimes (z 40)
(add-shape *scene* (translate-to (make-cylinder-uv-mesh 0.65 0.1 16 1) (p! x 0 z))))))
Profiling suggests that a lot of time is being spent managing floating point hardware state:
This seems to be related to 3b/cl-opengl#98 but I haven't understood the entire issue yet.
I suppose that if kons-9 will have a dedicated rendering thread for interacting the OpenGL APIs then it would make sense to lock down the floating-point hardware according to OpenGL requirements and then suppress these checks.
I tried rebuilding with
(pushnew :cl-opengl-no-masked-traps *features*)
(pushnew :cl-opengl-no-check-error *features*)
... but that didn't immediately seem to help. I haven't dug deep into why not.
Thanks for doing this test and digging into the cause. I must admit I'm not enough of a low-level code expert to understand what a possible solution might be. If you can, please keep digging into it.
Yes we have considered making the main thread just handle rendering OpenGL calls. This seems to be a solution for macOS which requires the UI to run in the main thread.
I think this is just because of using old gl, where you're going to be getting this for every single vertice/colour being set individually.
I doubt this will be much of a deal if you pack an array and pass the pointer.