summaryrefslogtreecommitdiffstats
path: root/libpixelflinger/codeflinger/ARMAssemblerInterface.h
Commit message (Collapse)AuthorAgeFilesLines
* system/core: rename aarch64 target to arm64Colin Cross2014-01-231-1/+1
| | | | | | | Rename aarch64 build targets to arm64. The gcc toolchain is still aarch64. Change-Id: Ia92d8a50824e5329cf00fd6f4f92eae112b7f3a3
* Pixelflinger: Add AArch64 support to pixelflinger JIT.Ashok Bhat2013-12-121-1/+1
| | | | | | | | | | | | | | | | | See the comment-block at the top of Aarch64Assembler.cpp for overview on how AArch64 support has been implemented In addition, this commit contains [x] AArch64 inline asm versions of gglmul series of functions and a new unit test bench to test the functions [x] Assembly implementations of scanline_col32cb16blend and scanline_t32cb16blend for AArch64, with unit test bench Change-Id: I915cded9e1d39d9a2a70bf8a0394b8a0064d1eb4 Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
* Pixelflinger: Support for handling 64-bit addresses in GGL AssemblerAshok Bhat2013-12-121-0/+10
| | | | | | | | | | | | | | | | | | | | | | GGLAssembler assumes addresses to be 32-bit and uses ARM 32-bit instructions to load/store/manipulate addresses. To support, 64-bit architectures, following changes has been done 1. ARMAssemblerInterface has been extended to support four new operations ADDR_LDR, ADDR_STR, ADDR_SUB, ADDR_ADD. Base class implements these virtual functions to use 32bit equivalent function. This avoids existing 32-bit Assembler backend implementations like ARMAssembler and MIPSAssembler from mapping the new functions to existing equivalent routines. This also allows 64-bit Architectures like AArch64 to override the function in their assembler backend implementations. 2. GGLAssembler code (spread over GGLAssembler.cpp, GGLAssembler.h and texturing.cpp) has been changed to use the new operations for address operations. Change-Id: I3d7eace4691e3e47cef737d97ac67ce6ef4fb18d Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
* Add MIPS support to pixelflinger.Paul Lind2012-08-131-23/+31
| | | | | | | See the comment-block at the top of MIPSAssembler.cpp for implementation overview. Change-Id: Id492c10610574af8c89c38d19e12fafc3652c28a
* Adds support for UBFX to JIT and DisassemblerMartyn Capewell2010-05-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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%
* Adds UXTB16 support to PixelflingerMartyn Capewell2009-12-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.
* Initial ContributionThe Android Open Source Project2008-10-211-0/+324