Skip to content

Version 47.1 #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 48 commits into
base: master
Choose a base branch
from
Open

Version 47.1 #11

wants to merge 48 commits into from

Conversation

tangalbert919
Copy link

Lots of things are optimized here. Only the ARM binaries succeeded in compilation.
x86 now utilizes AsmJIT, but whether or not it compiles remains unknown.

Tsunamical and others added 25 commits August 15, 2017 12:05
-Bump up to minimum API level of 14
-Drop ARMv6 and below support, only ARMv7 devices and above received ICS, so we can safely drop it and still cover well over 90% of devices
-Drop CPUFamily, we'll get all the information we need from CPUType
-WRITE_EXTERNAL_STORAGE is depcreated past SDK version 18
-Clean up XML tags
-Update build tools
-Shift some settings from the manifest to build.gradle
-Use Android Studio's built-in native compilation system
-Drop sourcesets, that dir doesn't even exist
-Enable fmodulo-sched and floop-strip-mine
-Remove some flags already enabled by -O3
-Add -fno-branch-count-reg for x86
Merge v47-1 to v48
Flag "-ffast-math" is already used with "-Ofast", making the flag redundant,
app/build.gradle Outdated
@@ -1,7 +1,7 @@
apply plugin: 'com.android.application'

android {
compileSdkVersion 26

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No reason to drop it, it's released, and allows us to use mentioned APIs without errors. targetSdkVersion is what you want to watch.

@@ -4,7 +4,7 @@ APP_STL := gnustl_static
APP_ABI := armeabi-v7a x86 arm64-v8a

# For releases
APP_CFLAGS := -Ofast -fmodulo-sched -fmodulo-sched-allow-regmoves -fsingle-precision-constant -fvariable-expansion-in-unroller -fomit-frame-pointer -fno-math-errno -funsafe-math-optimizations -ffinite-math-only -fdata-sections -fbranch-target-load-optimize2 -fno-exceptions -fno-stack-protector -fforce-addr -ftree-loop-im -ftree-loop-ivcanon -fivopts -ftree-loop-if-convert-stores -floop-strip-mine -ftree-loop-distribution -floop-interchange -ftree-loop-linear -floop-block -Wno-psabi
APP_CFLAGS := -O2 -fmodulo-sched -fmodulo-sched-allow-regmoves -fsingle-precision-constant -fvariable-expansion-in-unroller -fomit-frame-pointer -fno-math-errno -funsafe-math-optimizations -ffinite-math-only -fdata-sections -fbranch-target-load-optimize2 -fno-exceptions -fno-stack-protector -fforce-addr -ftree-loop-im -ftree-loop-ivcanon -fivopts -ftree-loop-if-convert-stores -floop-strip-mine -ftree-loop-distribution -floop-interchange -ftree-loop-linear -floop-block -Wno-psabi

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason for dropping Ofast? This will hinder performance a bit.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ofast is basically O3 plus a few other things. O3 is actually a very dangerous optimization level, and even though it might bring better performance, it can also break the code.
O2 is the recommended level of optimization without risking breakage, according to the GCC manual.

Copy link

@NotTsunami NotTsunami Aug 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naturally, a majority of our optimizations are dangerous - but they work, and they've been tested, hence why they're here. O3 is the minimum I'd recommend, it's Ofast that would truly be dangerous, but it hasn't really shown us any issues.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should really change that back. The Ofast thing also enables "-ffast-math", so we don't need to define that flag.

@@ -49,22 +49,22 @@
#define FLOATING_SQRT

#ifdef HAVE_NEON
#if defined(__arm__)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very easily avoidable by just removing -DHAVE_NEON from ARMv8, this is extra code that we don't need. Although, I don't see any drawbacks from having this enabled on ARM64.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the "HAVE_NEON" from ARMv8 long ago, but that condition was still being fulfilled. That's why that line of code is there.

@jquesnelle
Copy link
Owner

I'll merge this in later today -- are there any other changes for 47?

@jquesnelle jquesnelle self-assigned this Aug 23, 2017
@tangalbert919
Copy link
Author

At the moment, no.

@NotTsunami
Copy link

There actually are a few other things I'd like to push - although personally I don't think this is ready yet (just my opinion though).

@tangalbert919
Copy link
Author

I made an APK for this.
One problem with it: It crashes on launch.
Been working on compilation errors. I'll be debugging it now.

@tangalbert919
Copy link
Author

Come to think of it, I might just use the v48 branch to add 64-bit support. I can't seem to get anywhere with runtime with it because Lightning JIT doesn't like ARM64.

@tangalbert919
Copy link
Author

I have managed to get nds4droid to operate on 64-bit devices without crashing.
To achieve this, follow these instructions (64-bit ARM devices only):

  1. Press the back button. Don't try running any ROMs or the app will crash.
  2. Go to the settings menu.
  3. For the Execution Engine, select the first option called "interpreter".
  4. You're done. You can now load a ROM without crashing and notice that performance is much better (although it still depends on what device you're using).
    I need to erase the key store from the build.gradle. This was to fix the whole "unsigned APK" error for the run configuration.

@tangalbert919
Copy link
Author

I'm done making pushes now. Looks like 64-bit devices are not friendly to the Threaded Interpreter or Lightning JIT (in other words, they crash).
By default, the CPU Mode has been set to the normal interpreter as a workaround.

@tangalbert919
Copy link
Author

Almost an entire month has passed since this pull request has been made.

@tangalbert919
Copy link
Author

It has been one year and 5 days since this pull request was opened, and it's still open today. This is really nice, when you think about it.

@ghost
Copy link

ghost commented Jul 21, 2021

Any news updates about this?
Any plan to update the app on google playstore???

@ffoxD
Copy link

ffoxD commented Aug 6, 2021

This PR will celebrate its 5th birthday this month! And guess what, it's still open! Nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants