VOGONS

Common searches


Reply 140 of 152, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Hi almeath,

> The patch is meant to also work with standard (SDL1) DOSBox SVN?

It's bit-rotten since its last update here, but the work has found a home in DOSBox ECE, DOSBox-X, DOSBox Core, and DOSBox Staging.

For SVN, I'd suggest using the latest state of the patch used by ECE - it was last modified here: DOSBox ECE (for Windows & Linux)

> Also, if I am not needing to actually encode any CD audio into the respective formats, are there any baseline benefits to audio playback that are noticeable in standard DOSBox

Exactly; if you're only playing existing GoG (OGG Vorbis) encoded CD-DA tracks or mounting BIN/CUE's, then the extra codecs add no value.

> or is it just the underlying efficiency of the code that is improved?

Right; there was some mild refactoring done, but certainly nothing "make or break" in terms of performance.

Hope that helps!

--
Edit: added DOSBox-X; thanks for the reminder @Wengier!

Last edited by krcroft on 2021-04-08, 01:04. Edited 3 times in total.

Reply 142 of 152, by Wengier

User metadata
Rank Member
Rank
Member
krcroft wrote on 2021-04-04, 15:39:

It's bit-rotten since its last update here, but the work has found a home in ECE and Staging, like you've mentioned.

And it has found a home in DOSBox-X too (of course - thanks to your work). It is already supported by all major forks by now.

almeath:

As you mentioned earlier DOSBox-X performed slower than SVN for your games in macOS, unfortunately. There are many libraries used by DOSBox-X, but I am sure the performance issue has nothing to do with this patch. You can take as many libraries or features from DOSBox ECE or DOSBox-X into your own build as you want to suit your needs.

P.S. The DOSBox-X Team will eventually find out the exact cause for the said performance issue, although this may take some time. Having a goal of implementing emulations in a complete and accurate manner never stops us from trying to improve the performance too, of course. Porting the dynamic_x86 core from SVN to DOSBox-X 0.83.7 was a very good example of such efforts.

Reply 143 of 152, by almeath

User metadata
Rank Member
Rank
Member
Wengier wrote on 2021-04-07, 05:09:

As you mentioned earlier DOSBox-X performed slower than SVN for your games in macOS, unfortunately. There are many libraries used by DOSBox-X, but I am sure the performance issue has nothing to do with this patch. You can take as many libraries or features from DOSBox ECE or DOSBox-X into your own build as you want to suit your needs.

P.S. The DOSBox-X Team will eventually find out the exact cause for the said performance issue, although this may take some time. Having a goal of implementing emulations in a complete and accurate manner never stops us from trying to improve the performance too, of course. Porting the dynamic_x86 core from SVN to DOSBox-X 0.83.7 was a very good example of such efforts.

Thanks, I appreciate all the work you put into the DOSBox-X branch, and I still use it for certain specific purposes. I fall back to SVN when I need the raw speed, and I have also enjoyed progressively working my favorite ECE and X patches into it. Staging has diverted too far from SVN (different coding) which precludes me from incorporating others that I find interesting, such as the extensive improvements to Gravis Ultrasound. On the speed issue, I am really at a loss to explain it, as I have a 9900k system and I highly doubt it gets bogged down in any way, so there must be something specific hiding somewhere in the code. As mentioned on the Github site, I am always happy to help with further testing. Happy to take this up in the DOSBox-X sub-forum as well.

Reply 144 of 152, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

All the stuff DOSBox-X added to the dynamic_x86 core to "handle page faults" is mostly nothing but a huge slowdown. Nearly all memory accesses performed by that core (dyn_read_byte/write_byte/read_word/write_word) already handle faults correctly and the remaining opcodes that can cause problems (pusha, popa, etc) are still unfixed. My suggestion would be to rip the whole lot out, if there's anything that it does actually fix it can be implemented in a more optimal way.

Reply 145 of 152, by almeath

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2021-04-07, 09:06:

All the stuff DOSBox-X added to the dynamic_x86 core to "handle page faults" is mostly nothing but a huge slowdown. Nearly all memory accesses performed by that core (dyn_read_byte/write_byte/read_word/write_word) already handle faults correctly and the remaining opcodes that can cause problems (pusha, popa, etc) are still unfixed. My suggestion would be to rip the whole lot out, if there's anything that it does actually fix it can be implemented in a more optimal way.

Would that then have a negative impact on Win9x support? I notice that SVN appears fine with Win95 and 98 .. fast and stable in almost all instances, as long as I use the "pentium_slow" CPU.

Reply 146 of 152, by Wengier

User metadata
Rank Member
Rank
Member

The non-recursive page fault handling was added to the dynamic_x86 core in DOSBox-X 0.83.10 by a contributor, and according to his description this makes the dynamic x86 core more friendly with Windows 9x. But there are apparently known issues with this non-recursive page fault handling, and if he sees this I hope he can make further cleanups to the code if possible. I think he did try to make the non-recursive page fault handling optional with a setting, but I will see if there is anything not yet covered, e.g. by disabling such code completely and compare the performance.

Reply 148 of 152, by almeath

User metadata
Rank Member
Rank
Member
Wengier wrote on Yesterday, 07:12:

The non-recursive page fault handling was added to the dynamic_x86 core in DOSBox-X 0.83.10 by a contributor, and according to his description this makes the dynamic x86 core more friendly with Windows 9x. But there are apparently known issues with this non-recursive page fault handling, and if he sees this I hope he can make further cleanups to the code if possible. I think he did try to make the non-recursive page fault handling optional with a setting, but I will see if there is anything not yet covered, e.g. by disabling such code completely and compare the performance.

If these changes were the primary cause of the slow downs I am experiencing vs. SVN, then I would have been seeing more even performance (against SVN) in earlier versions of DOSBox-X. However, I recall that when I performed benchmarks last year, I was already getting a speed reduction of about 25-30%, which must have been long before these page fault changes were introduced. I will have to do some more testing with the toggle on/off to see if that impacts anything in the latest version.

Reply 149 of 152, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

Reverting the dynamic_x86 core to current SVN will likely break functionality in the dosbox-x dynrec core. There was also some merging of code between the dynrec and dynamic core (SVN) which may obfuscate future changes to the dynrec core. In any case, any changes or reversions should also be tested against the ne2000 emulation (Win 9x) since that was a problem area for these cpu cores.

For the cases I tested, the speed reduction with the non-recursive page fault handling (dyn_x86) was not >10%. Dosbox-x is intended as a project with experimental features, so it is fairly common that commits are made that break the emulation (see the s3 mmio emulation, for example). Many of the commits are fixes to other fixes, but that is expected with a priority on adding code instead of fully testing a build that is described as stable.

Reply 150 of 152, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

The point I am making is not that it is unstable, but that it tries to fix something that isn't broken; the dynamic_x86 core uses the *_checked memory access functions which don't trigger inline page faults. If it didn't use them it would have issues when self-modifying code touched the currently running block. Currently that can still happen via DMA since it bypasses the emulated TLB/memory maps.

Reply 151 of 152, by Wengier

User metadata
Rank Member
Rank
Member

Regarding the dynamic x86 non-recursive page fault handling - I cannot really say from my own experiences, because when the dynamic x86 core was ported from SVN it worked for me, but both TheGreatCodeholio, Rob and another user stated that even though the core worked fine for them in DOS, they encountered BSODs often when running Windows 9x, which meant it was not yet stable for them for the purpose of Windows 9x. But when the non-recursive page fault handling was introduced all of them reported that it had become much more stable for them to run Windows 9x as a whole (albeit with other known issues). So the non-recursive page fault handling did appear to be important for them, and it was merged to the repository at that time so that they could finally run Windows 9x with the dynamic core reliably, and also as a result it cannot really be reverted from the main code at this time. For me the non-recursive page fault handling is optional because I did not really encounter the issue myself, and I can try to disable it from my own system for performance comparisons etc, but not from the repository yet for reasons mentioned above, unless the said issue is resolved in some better way.

hail-to-the-ryzen: Indeed DOSBox-X includes several experimental features, but it is also needed to be added that the development pattern of DOSBox-X is largely incremental, which means that it is generally expected or hoped that a commit does add values to the existing code. So for the non-recursive page fault handling for example it resolves the major stability issue for people like TheGreatCodeholio and Rob, even though the commit itself cannot be described as 100% stable, apparently. In general DOSBox-X’s experimental features will not be the default option unless they are indeed considered important. Any experimental features are expected to be improved in later PRs or commits of course. This is why many commits are being made to fix existing issues or other fixes, instead of having to perfect it in a single PR or commit. But efforts are being made to stabilize the code before an official release.

Reply 152 of 152, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

A review of the commit history of the dynamic_x86 core is here:
https://github.com/joncampbell123/dosbox-x/co … pu/core_dyn_x86

The commit history shows that some of the SVN patches for the dynamic_x86 core occurred after the non-recursive page fault handling was added. That means it is untested whether the latest dynamic_x86 core is unstable in Windows 9x. Windows 9x was tested and the non-recursive page fault handling was added before all SVN commits were added to this dosbox-x cpu core.