History log of /system/core/libpixelflinger/codeflinger/ARMAssemblerProxy.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
bfc6dc4ca8d5a1ee498e80a18350b91519a5412c 21-Feb-2013 Ashok Bhat <ashok.bhat@arm.com> Pixelflinger: Support for handling 64-bit addresses in GGL Assembler

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>
/system/core/libpixelflinger/codeflinger/ARMAssemblerProxy.cpp
9857d99eecc389389da261a72461322d5cfb8eeb 02-Apr-2013 Mathias Agopian <mathias@google.com> move tinyutils into its own namespace

I was fed-up with the constant conflicts in Eclipse
with the "libutils" version.

Also fix a few copyright notices.

Change-Id: I8ffcb845af4b5d0d178f5565f64dfcfbfa27fcd6
/system/core/libpixelflinger/codeflinger/ARMAssemblerProxy.cpp
2bc2b792782b304b15d8c48b54916a9b3fa3a7ac 01-Feb-2012 Paul Lind <plind@mips.com> Add MIPS support to pixelflinger.

See the comment-block at the top of MIPSAssembler.cpp for
implementation overview.

Change-Id: Id492c10610574af8c89c38d19e12fafc3652c28a
/system/core/libpixelflinger/codeflinger/ARMAssemblerProxy.cpp
4dc1fa8e8d1f14868ab8bba93a8cbb87f847c4e3 04-Dec-2009 Martyn Capewell <martyn.capewell@arm.com> Adds support for UBFX to JIT and Disassembler

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%
/system/core/libpixelflinger/codeflinger/ARMAssemblerProxy.cpp
96dbb4fc58fe2dcf4390e073dbb42cc77ef2f0b5 07-Dec-2009 Martyn Capewell <martyn.capewell@arm.com> Adds UXTB16 support to Pixelflinger

* 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.
/system/core/libpixelflinger/codeflinger/ARMAssemblerProxy.cpp
4f6e8d7a00cbeda1e70cc15be9c4af1018bdad53 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution
/system/core/libpixelflinger/codeflinger/ARMAssemblerProxy.cpp