Androidx86 Discussion Thread

[VIRGIN KLM]

Hey everyone!

I just wanted everybody from the development team to know that I got recently a Galaxy Tab 3 10.1 which is an Androidx86 device and I would like to offer my help into anything that would involve testing and feedback!

Also it would be a great opportunity to start a thread that Androidx86 device owners can discuss about their issues.

As a start here are some random screenshots:

Kingdom Hearts Birth By Sleep Final Mix+
http://oi58.tinypic.com/2iuawk3.jpg
Monster Hunter 3rd HD ver.
http://oi61.tinypic.com/33ud1fa.jpg
Crisis Core: Final Fantasy VII
http://oi60.tinypic.com/ncywq1.jpg
Digimon World Re:Digitize
http://oi62.tinypic.com/2a4p9hs.jpg
Sword Art Online: Infinity Moment
http://oi60.tinypic.com/wlrmsj.jpg
Shining Ark
http://oi57.tinypic.com/2nkthc.jpg
The 3rd Birthday
http://oi61.tinypic.com/wbt6r4.jpg
Final Fantasy Type-0
http://oi59.tinypic.com/nv2kqu.jpg
Tekken 6
http://oi61.tinypic.com/2usfm81.jpg
Hatsune Miku: Project DIVA 2nd
http://oi58.tinypic.com/t5silh.jpg
Metal Gear Solid: Peace Walker
http://oi62.tinypic.com/29o3bes.jpg

Also here are my first questions.

1.Instead of disabling Alpha Tests in PowerVR could there be something like a lazy alpha test? There's too many stuff being affected by disabling alpha tests, I doubt there's even a single game that doesn't use them ALOT.

2.Do SSE2,SSE3,SSSE3 Instruction sets get used on Androidx86?

[solarmystic]

@VIRGIN KLM

On the desktop, PPSSPP uses only SSE and SSE2 instructions. SSE3, SSSE3, SSE4.1, 4.2 and AVX aren't used, although one could set the compiler to use AVX if necessary during compilation instead of SSE2.

I think it should be the same case for Android.

[VIRGIN KLM]

Why not use the rest instruction sets on Desktop builds on the auto-builds? All of the ones that support OGL2 support atleast SSE3 and SSSE3, and alot of them (like the 1/3rd of the userbase) support the rest aswell.
Also my question was basically for Android builds if they support SSE2, SSE3 and SSSE3 because even the oldest Intel based Android device support atleast those 3 which could mean some potential performance boost with zero effort.

[Henrik]

There's just not a whole lot to gain from SSE3+ etc as it is. FMA3 might help a little bit but it's not available on most mobile Intels yet. We could possibly leverage them to accelerate a fast software renderer in the future though, for example.

When Android x64 devices arrive, that will help speed too with no further modifications needed as we already have x64 support from the PC build.

[Trqrrhmn]

@VIRGIN KLM

What kind of FPS are you getting? I'm considering buying the Asus Zenfone 5 (Intel Atom Z2580, 2 GHz Dual Core, PowerVR SGX544MP2) which is very similar to your Galaxy Tab 3 10.1. It would be nice to know how well it runs PPSSPP before I make the decision. Which games have you tested? Are they playable?

[VIRGIN KLM]

(03-23-2014 11:56 AM)Trqrrhmn Wrote:  @VIRGIN KLM

What kind of FPS are you getting? I'm considering buying the Asus Zenfone 5 (Intel Atom Z2580, 2 GHz Dual Core, PowerVR SGX544MP2) which is very similar to your Galaxy Tab 3 10.1. It would be nice to know how well it runs PPSSPP before I make the decision. Which games have you tested? Are they playable?

Since v0.9.8-115 and this commit ( https://github.com/hrydgard/ppsspp/pull/5710 ) it actually gave a nice performance boost on quite alot of games and intrestingly, pretty like all of the games I play do alot of alpha tests so it's a real profit for me.
It's pretty good, maybe not the best, but for sure on the pretty good realm.
Even HD remasters seem to work on quite bearable FPS.
I hope there will be some optimizations/tricks/hacks on Androidx86.
I can't describe it but it feels like an ideal platform to show the capabilities of this emulator without it being a really expensive device.

[Trqrrhmn]

(03-26-2014 06:10 PM)VIRGIN KLM Wrote:  

(03-23-2014 11:56 AM)Trqrrhmn Wrote:  @VIRGIN KLM

What kind of FPS are you getting? I'm considering buying the Asus Zenfone 5 (Intel Atom Z2580, 2 GHz Dual Core, PowerVR SGX544MP2) which is very similar to your Galaxy Tab 3 10.1. It would be nice to know how well it runs PPSSPP before I make the decision. Which games have you tested? Are they playable?

Since v0.9.8-115 and this commit ( https://github.com/hrydgard/ppsspp/pull/5710 ) it actually gave a nice performance boost on quite alot of games and intrestingly, pretty like all of the games I play do alot of alpha tests so it's a real profit for me.
It's pretty good, maybe not the best, but for sure on the pretty good realm.
Even HD remasters seem to work on quite bearable FPS.
I hope there will be some optimizations/tricks/hacks on Androidx86.
I can't describe it but it feels like an ideal platform to show the capabilities of this emulator without it being a really expensive device.

Thanks for replying. I don't really mind a bit of lag if the games are comfortably playable. What kind of FPS are you currently getting on Kingdom Hearts/Crisis Core/Metal Gear Solid: Peace Walker?

[VIRGIN KLM]

Is there any measurement that PPSSPP takes to avoid Androidx86 devices using libhoudini by accident?
I have a feeling that some devices/software suffer from that issue.
Is it possible to make a build sans the ARM NDK binaries but only the x86 NDK binaries? (like google now for x86)

[[Unknown]]

I was under the vague impression that having an x86 binary would make it use it. But no, we don't do anything else AFAIK.

It is possible. Normally during development I make arm64-only builds just to reduce transfer and build time. I'm super impatient. However, putting them out there just means more work on the buildbot, more space consumed by builds, etc.

That being said, I personally think it'd be nice to make "thin binaries" for stable releases, just so they use slightly less space. Not that it's a huge savings. And I say that because I'm not the one doing the packaging so it's not more work for me, hahaha...

-[Unknown]

[VIRGIN KLM]

My problem is that I can't know if libhoudini is active while PPSSPP works, what you see on the system info is not enough to prove that the emulation layer is not active. There must be a way to block Android have access to ARM specific code on demand, like with a switch and the setting would work after a relaunch of the app. In an ARM device this will cause a FC (until you delete data) but in an x86 device should be the safest option to know that your device does not trigger an extra layer of emulation.

[[Unknown]]

Hmm, we could bake something into the system info for the binary architecture / ABI...

-[Unknown]