SDL version and Hatari

[siriushardware]

For some reason, I'm labouring under the impression that running Hatari compiled for SDL2 rather than SDL1.2 causes quite a performance hit and I think I have seen similar opinions expressed elsewhere in these forums, but I can't be sure because I have several flavours of Hatari running on different Linux machines and I can't remember which versions of SDL they were compiled for.

Is there some simple way I can query which version of SDL any given instance of Hatari is running with? I've looked at the entry / exit text generated when I run Hatari from inside a terminal window as I usually do, but I see nothing about the SDL version being used.

[ThorstenOtto]

Is there some simple way I can query which version of SDL any given instance of Hatari is running with?

On linux, you can just run

Code: Select all

ldd <path-to>/hatari


That should tell you atleast whether it is version 1.x or version 2.x. For the exact version, just look at your package manager which version is installed.

For windows, there is a similar tool in the aranym repo (as source only so you have to compile it first).

On macos, you can run

Code: Select all

otool -L <path-to>/hatari


IIRC that tool comes along with Xcode.

[Eero Tamminen]

For some reason, I'm labouring under the impression that running Hatari compiled for SDL2 rather than SDL1.2 causes quite a performance hit and I think I have seen similar opinions expressed elsewhere in these forums, but I can't be sure because I have several flavours of Hatari running on different Linux machines and I can't remember which versions of SDL they were compiled for.

If you have a properly HW (GPU) accelerated modern desktop, use SDL v2. If you don't have HW acceleration, use SDL v1.

On embedded Linux machines that are missing proper 3D driver, SDL v1 can be significantly faster. On Mac, SDL v2 was in some cases significantly faster than v1, because it integrates much better with 3D accelerated desktop.

If your system is really slow, in both cases you can save some performance by using a small resolution and letting your monitor to do the upscaling. This is especially important if using Hatari with SDL v1 when you have a very large resolution monitor.

Is there some simple way I can query which version of SDL any given instance of Hatari is running with?

Check whether Hatari SDL GUI "Hatari screen" options dialog has "SDL2 options" section.

[siriushardware]

Gentlemen, thanks for the replies which I have only just noticed.

I have not been back on the Linux machines in question at this time, but the most powerful (?) one is an HP intel i3 based desktop with integrated graphics, probably the chipset graphics which may or may not have some basic form of integrated 3D graphics handling, but no, it does not have a standalone graphics card

After moving Hatari to that machine from an Intel Atom based netbook I was surprised to find myself having to dial down the Hatari performance - reduce the screen refresh rate, turn off cycle exact emulation and so on, so that it would run Cubase 2 smoothly without stalling from time to time, but I strongly suspect that it was compiled for SDL2 on that machine- I will check it out and if necessary recompile it for SDL1.

[Eero Tamminen]

What's the output of following commands:
* sudo dmidecode | grep -e MHz -e ' MB'
* glxinfo | grep OpenGL
* wmctrl -m
* xrandr

I.e. what kind of memory (= bandwidth), integrated GPU & 3D driver, windowing system and resolutions you have in that device?

(On Debian/Ubuntu, these utilities come from "dmidecode", "mesa-utils", "wmctrl" and "x11-xserver-utils" packages.)

[siriushardware]

Acknowledging your questions, but I am away from that machine at the moment. I'll try to get back to you with the answers.

[siriushardware]

OK, sorry this has taken so long. I have been away for a while.

Hatari on this HP i3 based desktop Running Lubuntu is currently compiled for SDL2, as shown by the presence of SDL2 options in the F12 Gui setup menu,

Here are the outputs from the commands Eero asked about. Initially. Mesa-Utils and wmctrl weren't installed, I had to install them as I went.

Code: Select all

sudo dmidecode | grep -e MHz -e ' MB'

   External Clock: 100 MHz
   Max Speed: 3800 MHz
   Current Speed: 3100 MHz
   Range Size: 3322 MB
   Size: 2048 MB
   Size: 2048 MB

glxinfo | grep OpenGL

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.2.8
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 18.2.8
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.2.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

wmctrl -m

Name: Openbox
Class:
PID: N/A
Window manager's "showing the desktop" mode: OFF

xrandr

Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
VGA-1 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 330mm x 270mm
   1280x1024     60.02*+  75.02 
   1280x960      60.00 
   1152x864      75.00 
   1024x768      75.03    70.07    60.00 
   832x624       74.55 
   800x600       72.19    75.00    60.32    56.25 
   640x480       75.00    72.81    66.67    59.94 
   720x400       70.08 
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)

[siriushardware]

Forgot to mention: glxgears when run at full screen looks very smooth and reports constant 60fps during the run.

[ThorstenOtto]

The 60fps is just your monitor refresh rate. By default, OpenGL syncs to Vsync when swapping frames. In most drivers, there should be an option to disable that. glxgears should be able to produce several thousand frames/sec on a decent machine.

[siriushardware]

Believe me, being able to run glxgears at VBL rate (60Hz) is a big step forward for me. I have had Linux running on systems which could only manage about 10-12fps at fullscreen.

I would be interested to know if the results shed any light on the system's ability - or not - to run Hatari compiled for SDL2.

[Eero Tamminen]

HW you have (Sandybridge), dual-channel memory, small resolution (1280 x 1024), Mesa with GL 3.3 / GLES 3.0 support, and non-compositing desktop (Openbox) shouldn't give any performance problems for Hatari with SDL 2. Unless your cooling isn't working and your machine gets severely temperature limited when Hatari is running, it should perform at least as well as my own ancient desktop machine.

You should try glxgears with Vsync disabled:

Code: Select all

vblank_mode=0 glxgears -fullscreen

Its FPS should on your machine be at least in several hundreds, preferably over thousand.

While that's running, what this shows for your Intel GPU speed:

Code: Select all

watch -n 1 cat /sys/class/drm/card0/gt_cur_freq_mhz

And this for your machine temperature:

Code: Select all

sudo apt install lm-sensors
watch sensors