> Hi, > On 16/12/14 19:13, Tom Hacohen wrote: > > On 16/12/14 13:26, Cedric BAIL wrote: > > > Hello, > >> > >> On Tue, Dec 16, 2014 at 1:56 PM, Rajeev Ranjan wrote: > >>> There is an open source library called libyuv (Reference: > >>> <http://code.google.com/p/libyuv/> http://code.google.com/p/libyuv/ as part of chromium project released > >>> under BSD license) which provides scaling among other operations like > >>> color conversion and rotation for buffers in ARGB and various yuv > >>> formats. It has been optimized for SSE2/SSSE3/AVX2 on x86/x64 and Neon on > >>> Arm. Current acceleration for Smooth scaling in software backend is using > >>> Neon for Arm and using mmx on x86. After doing a little bit of > >>> experimentation, we found that the smooth scaling using libyuv is a bit > >>> faster on ARM as well as X86 platforms(checked with EFL 1.7) when > >>> compared with current implementation. Result of Below mentioned Expedite > >>> test cases with xlib engine were found to be better on ARM and Even MMX > >>> on X86 platforms. Image Blend Smooth Scaled, Image Blend Smooth Solid > >>> Scaled, Image Blend Border, Image Blend Solid Middle Border, Image Blend > >>> Solid Border, Image Blend Border Recolor, Image Quality Scale > >>> > >>> I would like to contribute this optimization for EFL latest release. > >>> Please share your comments. > >> > >> So basically their is room to improve our assembly code for various > >> target. How do you plan to proceed ? Add a dependency or move the > >> useful code inside of Evas ? Also did you do any comparison on why our > >> assembly and their assembly have different profile. I am wondering if > >> we need to use all of libyuv code or if only a part of it is > >> interesting to us by complementing our current assemblty code. > I was referring to make libyuv as optional build time dependency. So far no > analysis has been done to figure out as why profiling data with libyuv is > better compare to current neon code. The output of smooth scaling seems to be > similar though when dumped in raw format. The relevant code in libyuv for > which we found performance improvement is related to smooth scaling. In case > of nearest, it does not give any noticeable performance benefit. > >> > > > > Also, what about a comparison with latest EFL and not just 1.7? > Will share the comparison data after making relevant changes in latest evas > smooth scaling integration, expecting this to be on the similar line. Here is the comparison data of evas(1.12 upstream) with libyuv on an intel i3 2nd generation Expedite was run with software_x11 for 1000 mainloop runs with 720x420 These results are from expedite-cmp where right-side numbers are for evas with libyuv Image Blend Smooth Scaled: 18.64 107.59 (+477.2%) Image Blend Smooth Solid Scaled: 343.55 746.72 (+117.4%) Image Blend Border: 24.64 116.07 (+371.1%) Image Blend Solid Middle Border: 291.96 483.58 ( +65.6%) Image Blend Solid Border: 399.99 590.20 ( +47.6%) Image Blend Border Recolor: 24.53 98.09 (+299.9%) Image Quality Scale: 305.47 2086.82 (+583.2%) Image Blend Many Smooth Down Scaled: 8.13 18.30 (+125.1%) EVAS SPEED (WEIGHTED): 442.41 523.75 ( +18.4%) > > > > Anyhow, the major problem is that: "pacman -Ss libyuv" returns nothing. > > That is, it's not even packaged by arch... If anything, we should make > > it an internal dependency, and not an external one. Dependency hell is > > an important factor too. > The current version of libyuv is not having packaging based on pkg-config. > For testing purpose, we had created pc files locally so that pkg-config can > work. We can think of setting environment variables like LIBYUV_LIBS, > LIBYUV_CFLAGS etc if user wants to enable libyuv dependency in evas build > time. Yes, probably it won't be packaged by any distro because it's used only in chromium browser & lollipop as of now. The current cmakefile compiles it to a static library. If we statically link libyuv to evas, runtime dependencies can be avoided. The size of libevas.so(after stripping) increased by 0.3 MB in this case > this makes it a bit of a problem to add as a dep - even an optional dep. "no > one has it". it's "rare". is it worth adding a dep, that will be rarely > used/tested (and thus likely eventually break), for a "little" speedup. is it > perfhaps not better to look at the same algorithm and see what speeds it up > asm-wise and then "duplicate"? Currently the library maintains different asm for SSE2, SSE3, AVX2, NEON & NEON64 Also it has different asms when row width is multiple of 4,8,16 based on architecture Is it worth maintaining these asms in evas(along with bug fixes) or leave it to the library? Thanks, Krishnaraj
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
