CED unusably slow

[Zehvogel]

tl; dr: When I try to use glced from the nightlies or recent releases the performance is absolutely horrible and there are some graphical artefacts.

• OS version: alma-linux9
• Package version: current nightlies, latest release and all other older releases that I tried (spackages6)
• Reproduced by: running ced however you like, e.g. by following https://key4hep.github.io/key4hep-doc/k4marlinwrapper/doc/starterkit/k4MarlinWrapperCLIC/CEDViaWrapper.html or by using

ced2go -d <some-compact-file> -v DDCEDViewer sim-or-rec-file.slcio

• Goal: have a working event display

I get roughly 1-2 frames per second on single particle events and less on more interesting ones. The cpu usage goes up to 100% suggesting that the gl hardware acceleration doesn't work. In general this works on my machine, e.g. glxgears runs hardware accelerated.
Additionally, there are some graphical artefacts and transparency issues:

When I used ced directly from ilcsoft in the past at DESY everything worked fine. @tmadlener do you have any idea on how to fix this?

[tmadlener]

The cpu usage goes up to 100%

I suppose this is for the glced process that is started by ced2go?

e.g. glxgears runs hardware accelerated

Is this a glxgears that comes with the key4hep stack?

Additionally, there are some graphical artefacts and transparency issues:

I am not entirely certain if this explains everything, but at least I also have some transparency issues on Ubuntu 22.04. I am not sure if they are related to Wayland in any way.

Overall I don't have a real idea on what could be the problem, unfortunately. For a working event display it would potentially be good to move to phoenix? I don't know what is required from a detector geometry point of view there, but @kjvbrt has set up an FCC based one, so it should not be impossible to do the same for other DD4hep based geometries, I assume.

[Zehvogel]

I poked around a bit more using my local stack where the same happens (it uses the mesa from the last .scratch nightly).

[acts-env] [lreichen@pcphsft121 acts]$ glxinfo | grep "renderer string"
OpenGL renderer string: Mesa Intel(R) UHD Graphics 770 (ADL-S GT1)
[acts-env] [lreichen@pcphsft121 acts]$ LD_LIBRARY_PATH=$(spack location -i mesa)/lib:$LD_LIBRARY_PATH glxinfo | grep "renderer string"
OpenGL renderer string: softpipe

glxgears is then also suddenly transparent..

so maybe a bug in the software renderer?

[Zehvogel]

No idea how to best solve this for the nightlies and the release, but I found a way to at least get it working locally.

I added the following to the spack.yaml of my environment:

  packages:
    mesa:
      externals:
      - spec: mesa@22.3.0 +glx+opengl+opengles+osmesa
        prefix: /usr

which adds the system mesa as an external package and

  specs:
--- snip ---
  - mesa@22.3.0

which was necessary to make the concretizer actually pick my external mesa, but there is probably a cleaner way to force that.

With this I can even look at CLIC 3 TeV events with overlay with sufficient fps 🥳

[Zehvogel]

@jmcarcell maybe another candidate for #502?

[jmcarcell]

Both this one and #318 should have been fixed in the latest nightly, can you give it a try?