what git branch and angle build args are used to built swiftshader for android emulator?

[Łukasz Indyk]

i would like to try some angle changes to fix some rendering crashes in apps running on android emulators on x64 linux servers in my company's continues integration environment.

i've found that i can replace libEGL.so and libGLESv2.so in emulator's swiftshader linux64 prebuilts directory (https://android.googlesource.com/platform/external/qemu/+/emu-master-dev/android/docs/PREBUILT-BINARIES.TXT#176) and was able to built angle on google cloud compute linux instance to generate those *.so files so all good. i am not sure about a couple of things though:

1. i setup my angle development environment as described in https://chromium.googlesource.com/angle/angle.git/+/HEAD/doc/DevSetup.md, but i wonder how do i know from what specific commit  or branch angle / swiftshader was built for each emulator version distributed by google?

2. to make this work on x64 linux in release mode i used the gn args below, i wonder if they match what was used when building actual prebuilts distributed by google:

is_component_build = false
target_cpu = "x64"
is_debug = false
angle_assert_always_on = true
is_clang = true

3. should binaries compiled this way work on every version of linux that i try run emulator on assuming that this is x64 architecture, or if i run it on linux version that is different from linux versions listed as supported by angle's "./build/install-build-deps.sh

" i can expect problems?

thanks,

lukasz.

[Shahbaz Youssefi]

Hi,

Glad you've been having success setting things up. To answer your questions:

1. Normally, if your print out `GL_VERSION` from ANGLE, it includes the git hash. You can see an example of this if you navigate to chrome://gpu on Chrome (on Linux). I'm not sure how the emulator builds ANGLE though; if it copies the files in the emulator repo before build, ANGLE's git hash information is lost. In that case, some detective work is necessary to go from the emulator hash to ANGLE's.

2. Those args are good for testing, but most likely not what is used to build the emulator. In particular, `angle_assert_always_on = true` turns assertions on, which I highly doubt is enabled. Otherwise some are redundant (like `is_clang = true`, which is default, and `target_cpu="x64"` similarly), but generally I'd say those are reasonable args.

3. I don't think you could expect the same binary to work absolutely everywhere, for example w.r.t old distributions. However, it'll probably work fine in most cases. The list of platforms mentioned in ./build/install-build-deps.sh is not so much what's supported by ANGLE but rather what's supported by that script. Like the script only knows `apt` and knows about repositories in those distributions. You could always install the same dependencies with other package managers on other distributions.

Cheers,

[Łukasz Indyk]

After copying libEGL.so, libGLESv2.so and libGLES_CM.so to emulator I ended up with the following error:

ERR: Display.cpp:1019 (initialize): ANGLE Display::initialize error 12289: Could not open the default X display.
ERR: Display.cpp:1019 (initialize): ANGLE Display::initialize error 12289: Could not open the default X display.
ERROR   | Could not find GLES 2.x config!
ERROR   | Failed to obtain GLES 2.x extensions string!
ERROR   | Could not initialize emulated framebuffer

Random search over the internet suggests that at some point Angle had a bug that it wasn't working in headless mode, which would explain since I am running stuff on android emulator on linux server, and later this error was fixed. A couple of questions:

1. I wonder if I integrated angle properly, if it is enough to copy those files or there is some extra work required, like some config files to be copied etc?

2. what is the branch i should use, and how to get most recent stable release of angle? On my local repo "git rev-parse HEAD" returns b24b5568edd3ea661b7e26f6675d83f5ea16f709 if it helps.

[Shahbaz Youssefi]

1. When `is_component_build = false`, copying `libEGL.so` and `libGLESv2.so` should be enough. I typically also update libvk_swiftshader.so but that's useful only if the emulator is doing software rendering. At least that's what's been working for me with Chrome. I'm sorry I don't have any experience with the Android emulator.

2. Tip-of-tree is supposed to be stable at all times. On the rare occasion that a bad change goes through, you'd typically see a revert in a day or two.

[Łukasz Indyk]

Thank you!

--
You received this message because you are subscribed to a topic in the Google Groups "angleproject" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angleproject/2GdclLWzDQ0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angleproject...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/83a46ede-da3d-4f5a-8620-f34ad338a837n%40googlegroups.com.