This introduces UBFX instruction generation abilities to the Pixelflinger JIT,
and also modifies the component extraction function to generate the
instruction.
The extract function contains defines to prevent generation of UBFX on pre-v7
cores. The JIT itself retains the ability to produce the instruction even on
v5/6.
This patch only generates UBFX when MOV, AND or BIC can't be used. Based on
the TRM, this appears to be faster on A9 than using UBFX in all cases.
On startup, Pixelflinger JITs three chunks of code. UBFX improves these as
follows:
00000077:03515104_00000000_00000000
(Blends a single colour into an RGB565 buffer.)
Before: 27 inst/pixel, After: 24 inst/pixel, Improvement: 12.5%
00000077:03545404_00000A01_00000000
(Blends RGBA8888 texture into an RGB565 buffer using alpha.)
Before: 30 inst/pixel, After: 27 inst/pixel, Improvement: 11.1%
00000077:03545404_00000A04_00000000
(Blends RGB565 texture into an RGB565 buffer using alpha.)
Before: 29 inst/pixel, After: 27 inst/pixel, Improvement: 7.4%
Instead of allocating memory from the (non executable) heap,
allocate memory using mspace and ensure that we use mprotect
to mark it as PROT_EXEC. This allows pixelflinger to
continue to work even when NX protections are enabled.
Testing: Using the ApiDemos market app, verify that
Apidemos -> Graphics -> OpenGL ES -> GLSurfaceView
works when "adb shell setprop debug.egl.hw 0" is set.
Change-Id: Ib569cd2543c6fa25688ee76325a712bc2347450b
The Pixelflinger disassembler does not handle LDM addressing modes correctly,
assuming that the P and U bits in the instruction mean the same in both LDM and
STM. This results in the disassembler producing sequences like:
stmfd r13!, {r4-r11, r14}
...
...
...
ldmea r13!, {r4-r11, r14}
This small patch fixes it by EORing the P and U bits with the Load/Store bit.
Change-Id: Ic7a1556642c4e29415fc3697019f1239b6c26fc2
* Add support for UXTB16 to the disassembler
* Add encoding of the UXTB16 instruction to the Pixelflinger JIT.
Introducing the UXTB16 instruction allows removal of some masking code, and is
beneficial from a pipeline point of view - lots of UXTB16 followed by MUL
sequences.
Also, further rescheduling and use of SMULWB brings extra performance
improvements.
* Use UXTB16 in bilinear filtered texturing
Uses UXTB16 to extract channels for SIMD operations, rather than creating and
ANDing with masks. Saves a register and is faster on A8, as UXTB16 result can
feed into first stage of multiply, unlike AND.
Also, used SMULWB rather than SMULBB, which allows removal of MOVs used to
rescale results.
Code has been scheduled for A8 pipeline, specifically aiming to allow
multiplies to issue in pipeline 0, for efficient dual issue operation.
Testing on SpriteMethodTest (http://code.google.com/p/apps-for-android/) gives
8% improvement (12.7 vs. 13.7 fps.)
SMULBB to SMULWB trick could be used in <v6 code path, but this hasn't been
implemented.
The Android Open Source Project