[x265] deblock.cpp, ipfilter.cpp review comments

[N Vijay Anand]

In order to do significant optimisations, following approach is proposed.

1. Perform C level simulation with frame buffer data
    rearranged at the initialise stage itself in picking 16x16 blocks in
raster
    scan order within CTU size 64x64 along entire CTU sized slices.
2. The savings are immense in terms of cached access to memory lines
    in ME module, filter modules, MC reconstruction module, and other low
    level modules (transforms, quant, etc.)
3. The overhead is code readability and logic to read a block of data.
4. The existing numbers on instructions to compute a module isn't affected
    much, but cycles to compute is reduced significantly.
5. We need to percolate the changes affected to assembly modules (load and
    and maybe store instructions only)

-Vijay


> It might be more prudent to start from a profile showing the top functions
> that are limiting performance instead of a blind list of functions to
> optimize. You can use gprof (on linux), or vtune to extract this profile.
> Just make sure to compile with RelWithDebInfo to get debug symbols for the
> profiler to use. If you are using vtune, you can enable ENABLE_VTUNE in
> cmake.
>
> Pradeep.
>
> On Tue, Aug 23, 2016 at 11:22 AM, N Vijay Anand <
> nvijay.anand at trispacetech.com> wrote:
>
> > I was under impression typecasting does sign extension
> > irrespective of unsigned/signed type of data.
> >
> > BTW, I was trying to vectorise deblock filter.
> > Seems not much gain in this function. It would be useful
> > to have a list of function yet to be vector optimised.
> >
> >
> >
> > _______________________________________________
> > x265-devel mailing list
> > x265-devel at videolan.org
> > https://mailman.videolan.org/listinfo/x265-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20161126/183ee76a/attachment-0001.html>