Issue with Starling and SDK 51 on mac ?

[lamselli]

Issue with Starling and SDK 51 on mac ?

[ajwfrost]

Android patch (overlay for 51.0.1.x):
https://transfer.harman.com/link/34zoMorGsyFRVBj0Rf1Y3i

@lamselli / @bobaoapae if you're able to use this and/or the MacOS.zip package from earlier, and verify that your issues are resolved, it would be great..
Plus @JoseEstevesPt please see these links for you to validate re. #3274

thanks

[PrimaryFeather]

Just a quick shout-out for the speedy fix of this issue! Happy to see that Starling was useful to point out some edge cases of the updated JIT assembly code. 😁

[ajwfrost]

Great - thanks for confirming. We've had one issue with the current release candidate for our next version but it's not something I'd consider a blocking problem so we'll get that out the door, hopefully it will be available first thing tomorrow.

thanks

[ajwfrost]

We had a report yesterday with that same output, which was running on Android. Am I right in thinking that your mac is using Apple silicon? Wondering if you're able to strip out the arm64 part of it via 'lipo' and run it via the Rosetta system ...?

We believe there's a problem in the ARM64 JIT assembler that was introduced with the support of the 'float' type, which is causing a problem with some mathematical functions... we have a fix for this coming out within the next couple of days, 51.0.1.2, but if you can verify it works when run as an x86_64 app, it would help to confirm my assumption here..

@PrimaryFeather just flagging you here in case you get asked about this too -> expectation currently is that this is AIR returning a miniscule value when we're doing some floating point maths on an ARM64 processor...

thanks

[lamselli]

I just tested with AIR 50.2.4.4. I also have no issue...

[lamselli]

You are right! I'm using a mac M1.
This is the evening in Paris, I'll try to launch it with Rosetta tomorrow and let you know if it works!

[lamselli]

Just tried to remove arm64 arch from adl and run it with rosetta : you were right, I dont have any issue when using x86_64 architecture !

[lamselli]

Hey ! Just tried with 51.0.1.2. I don't have a black screen anymore, but I still have some issue with some textures that are not correctly displayed and still have the message "[Starling] Warning: frames inside the texture's region are unsupported."

Again, removing arm64 arch from adl and running it with rosetta "solves" the problem.

[ajwfrost]

Okay that's not so good ... sounds like we do still have a further issue in the JIT, but one that we're not actually aware of in the code (as well as implementing the fix, we also added a catch-all handler that should mean any other known-unknown scenario results in a fallback to interpreted mode for that function...)

Is this something we could try to reproduce here on a suitable mac? Ideally we'd hope for a really simple test case that reproduces the issue consistently .. but whatever you've got, we may be able to work backwards from, if we could get your app bundle..?

If so -> please could you upload the binary package using the below link?
https://transfer.harman.com/requests/ORavQA2UvnDOnRIScpAUqR

thanks

[sjabberwocky]

I just tested AIR 51.0.1.2 on a Mac mini with M1. Same problem here.

[lamselli]

Hey ! I just dropped the files !I hope this will help !

[ajwfrost]

Thanks - so although I don't actually see anything on-screen when I run it in interpreted mode, I don't get the Starling warning - whereas when I run it in JIT mode, I get the Starling warning.

Nothing obvious is thrown from the JIT code so we'll need to start breaking this down to find the culprit...

thanks

[ajwfrost]

@lamselli thanks for your test case, that hit the issue which appears to be where we're converting a negative "intptr" type into a floating point value.. so e.g. if you used parseFloat("-25") and store this in a Number, internally we still use an integer type (because we can!) but when we then come across a floating point operation (e.g. divide it by 2.5) then the conversion from -25 into the floating point register was going wrong.

Running a patched version with your test case, we no longer get those warnings from Starling. I'll get a test build created and uploaded here for you to check it with on your full app...

[bobaoapae]

Hey, i think i found a issue related for this again here, on my last tests as wee talked via e-mail I can't find, but now testing I have some Starling assets display at wrong positions, some of those full invisible. When you send that new build I will test to check if this fix the issue here too.

[bobaoapae]

This print show the issue i think i'm having on my application. It's a problem on the same code path as i can see

[ajwfrost]

Hi

That's the same line that we see the problem with, and yes a negative value is being misinterpreted to a very large positive value when it's moved from general purpose register to floating point register...

There's a fix in for this, below is a link to download a patch for the macOS platform (unzip this over the top of a 51.0.1.x release on macOS). I should be able to get an Android patch uploaded later today to check on the ARMv8 platform there too.
https://transfer.harman.com/link/INd5ZS5IsL0rKVtzGj639z

thanks

[lamselli]

I tried with the MacOs package, it seems to solve the issues on mac !
Could not try on Android, but I'll be interested to know if it works as well !

[bobaoapae]

Yes, this fixed the issue on android. Thanks.