Performance overhead of managing floating-point hardware

[lukego]

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 https://github.com/3b/cl-opengl/issues/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.

[kaveh808]

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.

[JMC-design]

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.