On Tue, 16 Dec 2014 14:25:31 +0000 (GMT) Rajeev Ranjan <rajee...@samsung.com> said:
> 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/ 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. > > > > 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. 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"? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
