1. 23 Feb, 2011 1 commit
    • Tero Rintaluoma's avatar
      ARMv6 optimized half pixel variance calculations · 8ae92aef
      Tero Rintaluoma authored
      Adds following ARMv6 optimized functions to the encoder:
       - vp8_variance_halfpixvar16x16_h_armv6
       - vp8_variance_halfpixvar16x16_v_armv6
       - vp8_variance_halfpixvar16x16_hv_armv6
      
      Change-Id: I1e9c2af7acd2a51b72b3845beecd990db4bebd29
      8ae92aef
  2. 11 Feb, 2011 1 commit
    • Tero Rintaluoma's avatar
      ARMv6 optimized sad16x16 · 1ef86980
      Tero Rintaluoma authored
      Adds a new ARMv6 optimized function vp8_sad16x16_armv6 to encoder.
      
      Change-Id: Ibbd7edb8b25cb7a5b522d391b1e9a690fe150e57
      1ef86980
  3. 10 Feb, 2011 1 commit
    • John Koleszar's avatar
      Fix relative include paths · 02321de0
      John Koleszar authored
      Allow compiling without adding vp8/{common,encoder,decoder} to the
      include paths.
      
      Change-Id: Ifeb5dac351cdfadcd659736f5158b315a0030b6c
      02321de0
  4. 09 Feb, 2011 1 commit
    • Tero Rintaluoma's avatar
      Adds armv6 optimized variance calculation · cb14764f
      Tero Rintaluoma authored
      Adds vp8_sub_pixel_variance16x16_armv6 function to encoder. Integrates
      ARMv6 optimized bilinear interpolations from vp8/common/arm/armv6
      and adds new assembly file for variance16x16 calculation.
       - vp8_filter_block2d_bil_first_pass_armv6   (integrated)
       - vp8_filter_block2d_bil_second_pass_armv6  (integrated)
       - vp8_variance16x16_armv6 (new)
       - bilinearfilter_arm.h (new)
      Change-Id: I18a8331ce7d031ceedd6cd415ecacb0c8f3392db
      cb14764f
  5. 25 Jan, 2011 1 commit
    • Johann's avatar
      move new neon subpixel function · 2168a944
      Johann authored
      previously wasn't guarded with ifdef ARMV7, causing a link error with
      ARMV6
      
      Change-Id: I0526858be0b5f49b2bf11e9090180b2a6c48926d
      2168a944
  6. 18 Jan, 2011 1 commit
    • Yunqing Wang's avatar
      Modify calling of NEON code in sub-pixel search · ce6c954d
      Yunqing Wang authored
      In vp8_find_best_sub_pixel_step_iteratively(), many times xoffset
      and yoffset are specific values - (4,0) (0,4) and (4,4). Modified
      code to call simplified NEON version at these specific offsets to
      help with the performance.
      
      Change-Id: Iaf896a0f7aae4697bd36a49e182525dd1ef1ab4d
      ce6c954d
  7. 27 Oct, 2010 1 commit
    • John Koleszar's avatar
      Fix half-pixel variance RTCD functions · a0ae3682
      John Koleszar authored
      This patch fixes the system dependent entries for the half-pixel
      variance functions in both the RTCD and non-RTCD cases:
      
        - The generic C versions of these functions are now correct.
          Before all three cases called the hv code.
      
        - Wire up the ARM functions in RTCD mode
      
        - Created stubs for x86 to call the optimized subpixel functions
          with the correct parameters, rather than falling back to C
          code.
      
      Change-Id: I1d937d074d929e0eb93aacb1232cc5e0ad1c6184
      a0ae3682
  8. 25 Oct, 2010 1 commit
    • Timothy B. Terriberry's avatar
      Add runtime CPU detection support for ARM. · b71962fd
      Timothy B. Terriberry authored
      The primary goal is to allow a binary to be built which supports
       NEON, but can fall back to non-NEON routines, since some Android
       devices do not have NEON, even if they are otherwise ARMv7 (e.g.,
       Tegra).
      The configure-generated flags HAVE_ARMV7, etc., are used to decide
       which versions of each function to build, and when
       CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen
       at run time.
      In order for this to work, the CFLAGS must be set to something
       appropriate (e.g., without -mfpu=neon for ARMv7, and with
       appropriate -march and -mcpu for even earlier configurations), or
       the native C code will not be able to run.
      The ASFLAGS must remain set for the most advanced instruction set
       required at build time, since the ARM assembler will refuse to emit
       them otherwise.
      I have not attempted to make any changes to configure to do this
       automatically.
      Doing so will probably require the addition of new configure options.
      
      Many of the hooks for RTCD on ARM were already there, but a lot of
       the code had bit-rotted, and a good deal of the ARM-specific code
       is not integrated into the RTCD structs at all.
      I did not try to resolve the latter, merely to add the minimal amount
       of protection around them to allow RTCD to work.
      Those functions that were called based on an ifdef at the calling
       site were expanded to check the RTCD flags at that site, but they
       should be added to an RTCD struct somewhere in the future.
      The functions invoked with global function pointers still are, but
       these should be moved into an RTCD struct for thread safety (I
       believe every platform currently supported has atomic pointer
       stores, but this is not guaranteed).
      
      The encoder's boolhuff functions did not even have _c and armv7
       suffixes, and the correct version was resolved at link time.
      The token packing functions did have appropriate suffixes, but the
       version was selected with a define, with no associated RTCD struct.
      However, for both of these, the only armv7 instruction they actually
       used was rbit, and this was completely superfluous, so I reworked
       them to avoid it.
      The only non-ARMv4 instruction remaining in them is clz, which is
       ARMv5 (not even ARMv5TE is required).
      Considering that there are no ARM-specific configs which are not at
       least ARMv5TE, I did not try to detect these at runtime, and simply
       enable them for ARMv5 and above.
      
      Finally, the NEON register saving code was completely non-reentrant,
       since it saved the registers to a global, static variable.
      I moved the storage for this onto the stack.
      A single binary built with this code was tested on an ARM11 (ARMv6)
       and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder,
       and produced identical output, while using the correct accelerated
       functions on each.
      I did not test on any earlier processors.
      
      Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa
      b71962fd