Search found 1382 matches
- Mon Nov 02, 2015 6:32 am
- Forum: Games & Demos
- Topic: Tempest is possible
- Replies: 704
- Views: 329535
Re: Tempest is possible
Can you post the kernel source that you used to compile it against? That could help narrow down the date range, and then it would be possible to run git bisect in order to discover the exact commit that breaks the sound.
- Fri Oct 30, 2015 5:52 am
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 97014
Re: Get that emu faster
I don't think it should be done. For me, adding update_hardware_fast() everywhere only bumped up performance by 3 percents (see PGO results: 93MHz versus 96MHz), and only by profile guiding (otherwise results were abysmal). For you, by this comment from before: On my desktop, I did notice a slowdow...
- Thu Oct 29, 2015 8:51 pm
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 97014
Re: Get that emu faster
Checked, the software renderer is responsible for this slowdown (-w). It is worse than drawing directly into the window (which didn't have any really noticable performance impact). I have no video card problems here, that was my parents' computer far away. Oh, I only included the -w because I thoug...
- Thu Oct 29, 2015 7:51 pm
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 97014
Re: Get that emu faster
Cool, I'm glad you saw similar gains! There is something wrong with how the flag set is implemented which you use for measuring performance. What do you mean? By default it sets some flags, and depending on what options you pass, it can turn off the SDL_RENDERER_PRESENTVSYNC flag, or turn off both S...
- Thu Oct 29, 2015 6:23 pm
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 97014
Re: Get that emu faster
Yes, you pointed out that I messed the merge up, but all the changes are in upstream, so I'm using the upstream uzem140 branch to test. For the fix, I'm just doing a selective search and replace for update_hardware() with update_hardware_fast(). I have a slower core2, but it went from 55MHz up to 65...
- Thu Oct 29, 2015 5:48 am
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 97014
Re: Get that emu faster
Okay, so I did some benchmarks on my 2.0 GHz Core2. With ARCH=core2, and as long as you enable PGO (which lets you collect the data from multiple runs, so you can profile all of the different video modes, rather than pick favorites) it's faster to call update_hardware_fast() everywhere possible, tha...
- Wed Oct 28, 2015 9:38 pm
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 97014
Re: Get that emu faster
Uh. I am pretty drained right now. Just a note for the performance: If your CPU has enough L1 instruction cache, it is likely that the most common paths of the inflated code fit, so it is fast. My older Core 2 CPU likely doesn't have that much cache, and I was hitting its limits. At least this is w...
- Wed Oct 28, 2015 8:52 am
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 97014
Re: Get that emu faster
I merged Jubatian's code into my uzem140 branch, and added my unrelated fix for the linker errors I was getting with the Emscripten build, along with a making GDB support a compile-time option, since it contained two conditionals that got executed 28M times per second, even when you don't activate i...
- Tue Oct 27, 2015 9:10 pm
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 97014
Re: Get that emu faster
I did the merge along with performance measurements. It is in the commit message: https://github.com/Jubatian/uzebox/tree/uzem140-hacks However I am simply unable to create a pull request today, I am trying to load that page in GitHub since like half an hour without success. My net access is atroci...
- Mon Oct 26, 2015 8:32 pm
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 97014
Re: Get that emu faster
To better coordinate everything that's happening with Uzem right now (since Uze wants to do some refactoring and cleanup once things settle down a bit), I figured I'd let everyone know what I hope can happen before the refactoring. It looks like the only major optimization left to be pulled into the...