Recherche avancée

Sur d’autres sites (6812)

• arm : vp9 : Add NEON loop filters

  10 octobre 2016, par Martin Storsjö

  arm : vp9 : Add NEON loop filters
  This work is sponsored by, and copyright, Google.
  The implementation tries to have smart handling of cases
  
  where no pixels need the full filtering for the 8/16 width
  
  filters, skipping both calculation and writeback of the
  
  unmodified pixels in those cases. The actual effect of this
  
  is hard to test with checkasm though, since it tests the
  
  full filtering, and the benefit depends on how many filtered
  
  blocks use the shortcut.
  Examples of relative speedup compared to the C version, from checkasm :
  
                            Cortex       A7     A8     A9    A53
  
  vp9_loop_filter_h_4_8_neon :          2.72   2.68   1.78   3.15
  
  vp9_loop_filter_h_8_8_neon :          2.36   2.38   1.70   2.91
  
  vp9_loop_filter_h_16_8_neon :         1.80   1.89   1.45   2.01
  
  vp9_loop_filter_h_16_16_neon :        2.81   2.78   2.18   3.16
  
  vp9_loop_filter_mix2_h_44_16_neon :   2.65   2.67   1.93   3.05
  
  vp9_loop_filter_mix2_h_48_16_neon :   2.46   2.38   1.81   2.85
  
  vp9_loop_filter_mix2_h_84_16_neon :   2.50   2.41   1.73   2.85
  
  vp9_loop_filter_mix2_h_88_16_neon :   2.77   2.66   1.96   3.23
  
  vp9_loop_filter_mix2_v_44_16_neon :   4.28   4.46   3.22   5.70
  
  vp9_loop_filter_mix2_v_48_16_neon :   3.92   4.00   3.03   5.19
  
  vp9_loop_filter_mix2_v_84_16_neon :   3.97   4.31   2.98   5.33
  
  vp9_loop_filter_mix2_v_88_16_neon :   3.91   4.19   3.06   5.18
  
  vp9_loop_filter_v_4_8_neon :          4.53   4.47   3.31   6.05
  
  vp9_loop_filter_v_8_8_neon :          3.58   3.99   2.92   5.17
  
  vp9_loop_filter_v_16_8_neon :         3.40   3.50   2.81   4.68
  
  vp9_loop_filter_v_16_16_neon :        4.66   4.41   3.74   6.02
  The speedup vs C code is around 2-6x. The numbers are quite
  
  inconclusive though, since the checkasm test runs multiple filterings
  
  on top of each other, so later rounds might end up with different
  
  codepaths (different decisions on which filter to apply, based
  
  on input pixel differences). Disabling the early-exit in the asm
  
  doesn’t give a fair comparison either though, since the C code
  
  only does the necessary calcuations for each row.
  Based on START_TIMER/STOP_TIMER wrapping around a few individual
  
  functions, the speedup vs C code is around 4-9x.
  This is pretty similar in runtime to the corresponding routines
  
  in libvpx. (This is comparing vpx_lpf_vertical_16_neon,
  
  vpx_lpf_horizontal_edge_8_neon and vpx_lpf_horizontal_edge_16_neon
  
  to vp9_loop_filter_h_16_8_neon, vp9_loop_filter_v_16_8_neon
  
  and vp9_loop_filter_v_16_16_neon - note that the naming of horizonal
  
  and vertical is flipped between the libraries.)
  In order to have stable, comparable numbers, the early exits in both
  
  asm versions were disabled, forcing the full filtering codepath.
                             Cortex           A7      A8      A9     A53
  
  vp9_loop_filter_h_16_8_neon :             597.2   472.0   482.4   415.0
  
  libvpx vpx_lpf_vertical_16_neon :         626.0   464.5   470.7   445.0
  
  vp9_loop_filter_v_16_8_neon :             500.2   422.5   429.7   295.0
  
  libvpx vpx_lpf_horizontal_edge_8_neon :   586.5   414.5   415.6   383.2
  
  vp9_loop_filter_v_16_16_neon :            905.0   784.7   791.5   546.0
  
  libvpx vpx_lpf_horizontal_edge_16_neon : 1060.2   751.7   743.5   685.2
  Our version is consistently faster on on A7 and A53, marginally slower on
  
  A8, and sometimes faster, sometimes slower on A9 (marginally slower in all
  
  three tests in this particular test run).
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavcodec/arm/Makefile
  • [DBH] libavcodec/arm/vp9dsp_init_arm.c
  • [DBH] libavcodec/arm/vp9lpf_neon.S

• arm : vp9 : Add NEON loop filters

  14 novembre 2016, par Martin Storsjö

  arm : vp9 : Add NEON loop filters
  This work is sponsored by, and copyright, Google.
  The implementation tries to have smart handling of cases
  
  where no pixels need the full filtering for the 8/16 width
  
  filters, skipping both calculation and writeback of the
  
  unmodified pixels in those cases. The actual effect of this
  
  is hard to test with checkasm though, since it tests the
  
  full filtering, and the benefit depends on how many filtered
  
  blocks use the shortcut.
  Examples of relative speedup compared to the C version, from checkasm :
  
                            Cortex       A7     A8     A9    A53
  
  vp9_loop_filter_h_4_8_neon :          2.72   2.68   1.78   3.15
  
  vp9_loop_filter_h_8_8_neon :          2.36   2.38   1.70   2.91
  
  vp9_loop_filter_h_16_8_neon :         1.80   1.89   1.45   2.01
  
  vp9_loop_filter_h_16_16_neon :        2.81   2.78   2.18   3.16
  
  vp9_loop_filter_mix2_h_44_16_neon :   2.65   2.67   1.93   3.05
  
  vp9_loop_filter_mix2_h_48_16_neon :   2.46   2.38   1.81   2.85
  
  vp9_loop_filter_mix2_h_84_16_neon :   2.50   2.41   1.73   2.85
  
  vp9_loop_filter_mix2_h_88_16_neon :   2.77   2.66   1.96   3.23
  
  vp9_loop_filter_mix2_v_44_16_neon :   4.28   4.46   3.22   5.70
  
  vp9_loop_filter_mix2_v_48_16_neon :   3.92   4.00   3.03   5.19
  
  vp9_loop_filter_mix2_v_84_16_neon :   3.97   4.31   2.98   5.33
  
  vp9_loop_filter_mix2_v_88_16_neon :   3.91   4.19   3.06   5.18
  
  vp9_loop_filter_v_4_8_neon :          4.53   4.47   3.31   6.05
  
  vp9_loop_filter_v_8_8_neon :          3.58   3.99   2.92   5.17
  
  vp9_loop_filter_v_16_8_neon :         3.40   3.50   2.81   4.68
  
  vp9_loop_filter_v_16_16_neon :        4.66   4.41   3.74   6.02
  The speedup vs C code is around 2-6x. The numbers are quite
  
  inconclusive though, since the checkasm test runs multiple filterings
  
  on top of each other, so later rounds might end up with different
  
  codepaths (different decisions on which filter to apply, based
  
  on input pixel differences). Disabling the early-exit in the asm
  
  doesn’t give a fair comparison either though, since the C code
  
  only does the necessary calcuations for each row.
  Based on START_TIMER/STOP_TIMER wrapping around a few individual
  
  functions, the speedup vs C code is around 4-9x.
  This is pretty similar in runtime to the corresponding routines
  
  in libvpx. (This is comparing vpx_lpf_vertical_16_neon,
  
  vpx_lpf_horizontal_edge_8_neon and vpx_lpf_horizontal_edge_16_neon
  
  to vp9_loop_filter_h_16_8_neon, vp9_loop_filter_v_16_8_neon
  
  and vp9_loop_filter_v_16_16_neon - note that the naming of horizonal
  
  and vertical is flipped between the libraries.)
  In order to have stable, comparable numbers, the early exits in both
  
  asm versions were disabled, forcing the full filtering codepath.
                             Cortex           A7      A8      A9     A53
  
  vp9_loop_filter_h_16_8_neon :             597.2   472.0   482.4   415.0
  
  libvpx vpx_lpf_vertical_16_neon :         626.0   464.5   470.7   445.0
  
  vp9_loop_filter_v_16_8_neon :             500.2   422.5   429.7   295.0
  
  libvpx vpx_lpf_horizontal_edge_8_neon :   586.5   414.5   415.6   383.2
  
  vp9_loop_filter_v_16_16_neon :            905.0   784.7   791.5   546.0
  
  libvpx vpx_lpf_horizontal_edge_16_neon : 1060.2   751.7   743.5   685.2
  Our version is consistently faster on on A7 and A53, marginally slower on
  
  A8, and sometimes faster, sometimes slower on A9 (marginally slower in all
  
  three tests in this particular test run).
  This is an adapted cherry-pick from libav commit
  
  dd299a2d6d4d1af9528ed35a8131c35946be5973.
  Signed-off-by : Ronald S. Bultje <rsbultje@gmail.com>
  

  • [DH] libavcodec/arm/Makefile
  • [DH] libavcodec/arm/vp9dsp_init_arm.c
  • [DH] libavcodec/arm/vp9lpf_neon.S

• Approaches To Modifying Game Resource Files

  16 août 2016, par Multimedia Mike — Game Hacking

  I have been assisting The Translator in the translation of another mid-1990s adventure game. This one isn’t quite as multimedia-heavy as the last title, and the challenges are a bit different. I wanted to compose this post in order to describe my thought process and mental model in approaching this problem. Hopefully, this will help some others understand my approach since what I’m doing here often appears as magic to some of my correspondents.

  High Level Model
  At the highest level, it is valuable to understand the code and the data at play. The code is the game’s engine and the data refers to the collection of resources that comprise the game’s graphics, sound, text, and other assets.

  
  
  Simplistic high-level game engine model
  

  Ideally, we want to change the data in such a way that the original game engine adopts it as its own because it has the same format as the original data. It is very undesirable to have to modify the binary engine executable in any way.

  Modifying The Game Data Directly
  How to modify the data ? If we modify the text strings for the sake of language translation, one approach might be to search for strings within the game data files and change them directly. This model assumes that the text strings are stored in a plain, uncompressed format. Some games might store these strings in a text format which can be easily edited with any text editor. Other games will store them as binary data.
  

  In the latter situation, a game hacker can scan through data files with utilities like Unix ‘strings’ to find the resources with the desired strings. Then, use a hex editor to edit the strings directly. For example, change “Original String”…

  0098F800   00 00 00 00  00 00 00 4F  72 69 67 69  6E 61 6C 20  .......Original 
  0098F810   53 74 72 69  6E 67 00 00  00 00 00 00  00 00 00 00  String..........
  

  …to “Short String” and pad the difference in string lengths using spaces (0x20) :

  0098F800   00 00 00 00  00 00 00 53  68 6F 72 74  20 53 74 72  .......Short Str
  0098F810   69 6E 67 20  20 20 00 00  00 00 00 00  00 00 00 00  ing   ..........
  

  This has some obvious problems. First, translated strings need to be of equal our smaller length compared to the original. What if we want to encode “Much Longer String” ?

  0098F800   00 00 00 00  00 00 00 4D  75 63 68 20  4C 6F 6E 67  .......Much Long
  0098F810   65 72 20 53  74 72 00 00  00 00 00 00  00 00 00 00  er Str..........
  

  It won’t fit. The second problem pertains to character set limitations. If the font in use was only designed for ASCII, it’s going to be inadequate for expressing nearly any other language.

  So a better approach is needed.

  Understanding The Data Structures
  An alternative to the approach outlined above is to understand the game’s resources so they can be modified at a deeper level. Here’s a model to motivate this investigation :

  
  
  Model of the game resource archive format
  

  This is a very common layout for such formats : there is a file header, a sequence of resource blocks, and a trailing index which describes the locations and types of the foregoing blocks.

  What use is understanding the data structures ? In doing so, it becomes possible to write new utilities that disassemble the data into individual pieces, modify the necessary pieces, and then reassemble them into a form that the original game engine likes.

  It’s important to take a careful, experimental approach to this since mistakes can be ruthlessly difficult to debug (unless you relish the thought of debugging the control flow through an opaque DOS executable). Thus, the very first goal in all of this is to create a program that can disassemble and reassemble the resource, thus creating an identical resource file. This diagram illustrates this complex initial process :

  
  
  Rewriting the game resource file
  

  So, yeah, this is one of the most complicated “copy file” operations that I can possibly code. But it forms an important basis, since the next step is to carefully replace one piece at a time.

  
  
  Modifying a specific game resource
  

  This diagram shows a simplistic model of a resource block that contains a series of message strings. The header contains pointers to each of the strings within the block. Instead of copying this particular resource block directly to the new file, a proposed modification utility will intercept it and rewrite the entire thing, writing new strings of arbitrary length and creating an adjusted header which will correctly point to the start of each new string. Thus, translated strings can be longer than the original strings.

  Further Work
  Exploiting this same approach, we can intercept and modify other game resources including fonts, images, and anything else that might need to be translated. I will explore specific examples in a later blog post.

  Followup

  • Translating Return to Ringworld, in which I apply the ideas expressed in this post.

  The post Approaches To Modifying Game Resource Files first appeared on Breaking Eggs And Making Omelettes.