EVE demo woes

Hello,

On my desktop computer at home, I’ve recently successfully built and installed ROOT 5.26 from source. One of the motivations for doing that was to be able to play with EVE at whim. However, I’m running into problems.

The tutorials/eve/alice_esd.C script has been flaky on multiple computers I’ve tried running it on. The group I work for has Dell Optiplex workstations with Core 2 Duos, but the graphics cards are slightly different between the models (I would have to do some digging to find out exactly how). So, some of these workstations seem to be able to run it, while on others, it will send the X server into a blank-screen, catatonic state. On my home desktop (AMD Sempron, 32-bit), the main window will pop up and the frames will be created, but then the frame contents are all black, and my X server is sent into some other sort of catatonic state (the mouse still responds, sort of, but the keyboard does not, and I end up having to push the reset button).

On the desktop where alice_esd.C does work, I tried using a different detector geometry (an adventure from a prior thread of mine), and it seemed the display couldn’t handle it. It would go into a loop where the console spit out a bunch of seemingly threading-related errors.

I really do like the concept though, and I want to try to use it as a starting point for a larger project. Does anyone have any ideas where all the instability is coming from in this demo?

For note, the TGeo tutorials, and the other EVE demos run well, as best as I can determine.

Thanks,
Matthew Lockner

Additional info: The EVE tutorial pythia_display.C exhibits similar flakiness. A common element in the applications behaving this way is the use of the multi-paned viewer. I may try to convert one of the demos to display only one of the panes and see if the problem disappears.

MJL

Attached is a modified version of pythia_display.C that will run on my machine. I commented out the MultiView object.
pythia_display.C (7.86 KB)

Hi Matthew,

The symptoms you describe (X going uber dead) were observed with some buggy intel GL drivers. In particular, SLC5 shipped with those at some point (I think it got improved in the recent versions). Can you send us the /etc/X11/xorg.conf file and the output of xdpyinfo, glxinfo and lspci. What OS do you have installed?

In any case, upgrading GL drivers might help.

Another thing that was causing trouble (but not to such extent) were desktop effects. The compositing window managers do not allow direct hardware access to the applications as they use it up for doing magick with window-textures. If you have it enabled, try switching this off.

Best,
Matevž

[quote=“matevz”]Hi Matthew,

The symptoms you describe (X going uber dead) were observed with some buggy intel GL drivers. In particular, SLC5 shipped with those at some point (I think it got improved in the recent versions). Can you send us the /etc/X11/xorg.conf file and the output of xdpyinfo, glxinfo and lspci. What OS do you have installed?

In any case, upgrading GL drivers might help.

Another thing that was causing trouble (but not to such extent) were desktop effects. The compositing window managers do not allow direct hardware access to the applications as they use it up for doing magick with window-textures. If you have it enabled, try switching this off.

Best,
Matevž[/quote]

I’ve attached the command outputs and xorg.conf; the OS is Debian’s “testing” distribution (I believe it’s numbered as Debian 4.4.2-9). The drivers are kept recent automatically through the apt tool, but I could try fetching a bleeding-edge release (though I’m not even sure exactly which package in Debian handles these). I’ll keep in mind to shut off compositing before starting these.

I can also get the lowdown from those Optiplex machines as well if that would be useful. I know those run SLC of some version.

Thanks,
Matthew Lockner
xorg.conf.txt (4.89 KB)
xdpyinfo.txt (3.92 KB)
lspci.txt (1.03 KB)
glxinfo.txt (5.31 KB)

Hi,

I’m afraid your biggest enemy is your graphics card – it is 7 years old and the last vendor driver for it came out in 2006. The open-source radeon driver that you are using is known to have issues with GL and old hardware. You also only get support for OpenGL-1.3 out of the driver.

Depending on the complexity of what you are trying to draw, I’d advise either to switch off DRI in xorg.conf and use software rendering or to get a recent video card (~50$ should do the trick). Vendor provided drivers for nvidia and ati cards are a much better option for 3D graphics intensive applications.

Sorry about that,
Matevz

OK, thanks. It’s probably time for an upgrade anyway.