Created: Jammy Zhou
The opengl/es backend runtime selection of skia is scoped out of this spec, because of similar problems for qt and evas backend selection. This spec will focus on NEON runtime detection of skia, where compile time selection is still used for NEON optimization. With the runtime selection, one unified skia library can be used for all armel platforms, no matter NEON is supported or not, which is more flexible.
Some armv7 SOCs have NEON support (such as imx51, omap,...), but some armv7 SOCs don't support NEON instruction set (such as dove, tegra2). To utilize the power of NEON optimization, runtime detection of NEON support seems a good solution with one unified skia package/binary to make sure that the NEON optimization path of skia is used for SOCs with NEON and normal path is used for SOCs without NEON.
- skia is used for 2D operations in Android and Chromium OS, and it is also used by chromium browser.
- currently Ubuntu does not enable NEON for chromium browser because both NEON and non-NEON SOCs should be supported with the same package, in this case NEON optimization is not available for NEON enabled SOCs.
- if user want to benchmark the performance of skia with/without NEON, two separate skia libraries need to be used
- /proc/self/auxv is supported for armv7 architecture in the kernel
- check NEON support of toolchain by compile a small piece of NEON asm code, if the compilation succeeds, enable the NEON runtime detection code path, otherwise go to the normal path without NEON optimization.
- check /proc/self/auxv for NEON hardware capabilities, if NEON support is exposed by kernel, go with the NEON optimization path, otherwise go with the non-NEON path.
do the runtime check of NEON in hasNeonRegisters() function of skia/src/opts/opts_check_arm_neon.cpp file, and the "ARM_HAVE_NEON" macro definition can be removed accordingly
- download latest upstream skia and build skia library for investigation (with android or chromium-browser)
- discuss the proposal with skia upstream to avoid duplicate work
- after the proposal accepted by upstream, begin the implementation
- check NEON support of toolchain
- check NEON hwcaps at runtime
- verify the implementation on SOCs with/without NEON support
- upstream the changes
- package chromium browser with skia for runtime NEON detection in PPA
- verify the skia library for chromium browser (or Android) on SOCs with NEON (imx51, omap, ux500) to make sure that NEON optimization is used
- verify the skia library for chromium browser (or Android) on SOCs without NEON (dove, tegra2, or hide NEON support in /proc/self/auxv for SOCs with NEON) to make sure that it still works
- compare the performance of chromium browser with neon enabled/disabled (by change /proc/self/auxv)
BoF agenda and discussion
Notes from UDS session:
Agenda * GLES backend selection is out of scope of this spec
- this will be solved for all toolkits as part of another effort for any library; was discussed in the qt session etc.
- adding GLES backend is also out of scope; the GL backend code is old and stale as well ... so seems this was a dead end for now
* Runtime detection of NEON
/proc/self/auxv -> example code is available in pixman, evas, qt and others
currently ubuntu does not have NEON for chromium because they have to support non-NEON SoCs
- also profiling difference of NEON vs. non-NEON is not doable atm without rebuilding the software; with runtime detection you can enable/disable it on the kernle level to compare both options
- good examples available in the world: pixman
- Q: how much code refactoring needs to be done to do runtime detection
- two options:
- a) use linker to load NEON vs. non NEON lib b) refactor code to use NEON code paths if available on the system and otherwise use non-NEON code
- using linker to load a NEON lib vs. non NEON lib is a solution on distribution level and does not work for everyone; example: skia is statically linked into chromium-browser
agreed that hwcaps detection for selecting runtime code paths is the right way forward; for now its NEON vs. non-NEON; later other optimizations for SoCs that dont have NEON would be possible
- is there a place to do the runtime check; do we need refactoring?
- skia uses accessor functions like memset; seems doable with reasonable effort; however its not a one line change (otherwise upstream would have probably added it already)
is there a need to keep explicit configure flags around for disable NEON at all? not for runtime use, but maybe if compiler does not support it -> ask upstream what they want
* goal of linaro is to make upstream armel code base ready to get the best out of various ARMEL platform from a single binary -> get rid of compile time options.
- document proposal
- present to upstream
- implement and upstream
WorkingGroups/Middleware/Graphics/Specs/1105/SkiaBackend (last modified 2011-01-13 22:02:53)