Recherche avancée

Sur d’autres sites (5656)

• Announcing Long Term Support in Piwik 2 – The analytics platform for your mission critical projects

  11 janvier 2016, par Matthieu Aubry — About, Development

  We are proud to announce our Long Term Support (LTS) for Piwik 2.X !

  Why Long Term Support (LTS) ?

  Part of our mission is to ready Piwik for the enterprise — and ready the enterprise for Piwik. Our fast release cycle and our ability to quickly innovate has served us well for the past seven years and has lead Piwik to being one of the most popular open source projects, used by over one million websites worldwide. But Piwik’s success today has also shown us that this fast release cycle is not suited for all users and customers. Like most large open source projects (such as Ubuntu, Firefox, Debian, Symfony, Node.js, etc.) at Piwik we now also offer a Long Term Support release which gives users the confidence that Piwik can be used for mission critical projects for months to come.

  What does LTS mean for Piwik ?

  For the duration of the LTS period, Piwik 2.X will continue to receive the following fixes :

  • Critical bugs causing data loss or data corruption.
  • Major and Critical security issues.

  Our goal is to offer you a Piwik LTS release that you can trust for all your mission critical projects.

  How long will Piwik 2.X be supported ?

  Piwik 2.X will be supported for at least 12 months after the initial release of Piwik 3.0.0.
  Piwik 3.0.0 is expected to be released in the second half of 2016.
  This means that Piwik 2.X will be supported at least until the second half of 2017.

  Which Piwik version is LTS ?

  The latest Piwik 2.16.X release is our Long Term Support version.

  How do I benefit from the LTS version ?

  To get the full benefits of Piwik LTS, please make sure you are using the latest LTS version. First, update to the latest Piwik 2.X version, then Configure Piwik to use the LTS release channel and then update to the latest LTS version.

  How do I configure Piwik to use the LTS version ?

  By default, Piwik will not use the LTS version. When you use the one-click update your Piwik instance will be updated to the very latest release : when Piwik 3.0.0 will be released, the one click update will update your instance to 3.0.0. It is however possible to configure your Piwik so that you will stay on Piwik 2.X and keep using the LTS Long Term Support version :

  • Login Piwik as the Super User,
  • Go to Settings > General > Update settings,
  • Under “Release channel” click “Latest stable 2.X Long Term Support version”, and click “Save”.
    

  How do I get professional Piwik Support ?

  If you need professional support for your Piwik service get in touch with the Piwik experts.

  ---

  For other questions, feedback or discussion, feel free to join our forums and comment on this LTS forum post.

  We wish you all a fantastic year 2016 !

• 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

• 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