Performance degredation in recent builds on Linux \ VOGONS

Performance degredation in recent builds on Linux

Topic actions

Post a reply

First post, by Epsilon

Posted on 2017-07-27, 23:56

Epsilon Offline

Rank Newbie

Rank: Newbie
Posts: 16
Joined: 2011-01-03, 02:19

I've been noticing some weird performance degredation in recent svn builds. I'm running DOSBox on Linux. With a game on max cycles it will skip and lag. With max 90% and 80% it skips and lags, even with set cycles I see the issue.
If I for instance move the mouse cursor around fast on the menu in Lands of Lore 2, the sound will start skipping, and eventually stop completely. Theres also a bunch of skips and pops in the sound when playing the game. Similarly in Lands of Lore, if I move the character around on the grid fast back and forth, the music starts to slow down.

The build I had before, which was an old build, from december 2016 had none of these issues, nothings changed on the system. I compiled the DOSBox-X master branch, it did not exhibit these issues. The DOSBox-ECE did. All builds were compiled on the system.
I've checked that it's running off Dynamic core, and it's available. Through the "core dynamic" command - > core reports dynamic.
I'm not sure how to figure out whats causing this, or where it's gone wrong.

Reply 1 of 8, by Dominus

Posted on 2017-07-28, 00:33

Dominus Offline

Rank DOSBox Moderator

Rank: DOSBox Moderator
Posts: 9147
Joined: 2002-10-03, 09:54
Location: Ludwigsburg

DOSBox-x does not have the dynamic core and 64bit dynamic core is not fully developed. Try with a 32bit build.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 2 of 8, by Epsilon

Posted on 2017-07-28, 01:18

Epsilon Offline

Rank Newbie

Rank: Newbie
Posts: 16
Joined: 2011-01-03, 02:19

Yeah I found that out, and after having done some more investigation, I came here to amend my post.
I decided to go back to the previous working build which was r4000. But having that compiled I still experienced the same thing. Since I was using the one from the distro's repository previously, I went and looked at that, and that was indeed a 32bit file!. Now I've compiled r4025 in 32bit. Unfortunately I still experience these weird slowdowns. But I'll investigate further.

Edit...
I have to concede defeat for now.
But I made a small recording of the problem. https://youtu.be/wwjQLHLBKz8
This is on r4025 32bit.
File info

1dosbox: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ea744ccb80b67c50f97113d54ac6b8db556a69e4, stripped

Maybe someone else recognizes the issue. I'm going to have some sleep now.

Reply 3 of 8, by Epsilon

Posted on 2017-07-28, 14:38

Epsilon Offline

Rank Newbie

Rank: Newbie
Posts: 16
Joined: 2011-01-03, 02:19

I've tried a few more things now. I've tried compiling main branch against hg sdl. I've tried setting up cpu pstates to constantly be maximum. And I've tried the ece binary distributed by yesterplay80 for Linux. And I've tried compiling it myself for 32bit. But the issue remains.
I really haven't got a clue whats going on here.

Reply 4 of 8, by ripsaw8080

Posted on 2017-07-28, 15:04

ripsaw8080 Offline

Rank DOSBox Author

Rank: DOSBox Author
Posts: 5034
Joined: 2006-04-25, 23:24

Have you tried different output= settings? I had a similar problem with strange speed fluctuations caused by the output=opengl setting combined with vsync being set to ON in the NVidia driver global settings instead of the "application controlled" default, though this was on Win10.

Reply 5 of 8, by Epsilon

Posted on 2017-07-28, 15:19

Epsilon Offline

Rank Newbie

Rank: Newbie
Posts: 16
Joined: 2011-01-03, 02:19

ripsaw8080 wrote:
Have you tried different output= settings? I had a similar problem with strange speed fluctuations caused by the output=opengl setting combined with vsync being set to ON in the NVidia driver global settings instead of the "application controlled" default, though this was on Win10.

I have. With output set to surface, the issue isn't there. However I can't scale that to my desktop resolution, like I can with opengl.

Reply 6 of 8, by ripsaw8080

Posted on 2017-07-28, 15:24

ripsaw8080 Offline

Rank DOSBox Author

Rank: DOSBox Author
Posts: 5034
Joined: 2006-04-25, 23:24

Great, now have you ensured that vsync is OFF? 😀

Reply 7 of 8, by Epsilon

Posted on 2017-07-28, 15:58

Epsilon Offline

Rank Newbie

Rank: Newbie
Posts: 16
Joined: 2011-01-03, 02:19

ripsaw8080 wrote:
Great, now have you ensured that vsync is OFF? 😀

Yep completely, theres nothing in /etc/profile - where I had 'sync to vblank' enabled, and in the compositor I've set tearing prevention to 'never'. Even tried turning the compositor off entirely. The issue is still there.

edit...
oh wait turned this off
And it's gone! Jesus christ what a ballache.
But thanks for spotting what the problem was!, this was giving me more grey hairs than I cared for. 🤣

Reply 8 of 8, by ripsaw8080

Posted on 2017-07-28, 16:05

ripsaw8080 Offline

Rank DOSBox Author

Rank: DOSBox Author
Posts: 5034
Joined: 2006-04-25, 23:24

Okay, it's just that the issue sounds very much like what happened in my case, where opengl+vsync was the cause. It appears the problem is still related to opengl output, though, since surface output is not affected.

Edit: oops, missed your edit, glad I could help. 😀

Go to top of page Go to top of page

Back to DOSBox General

Main menu

Common searches