FlipVertical and New BitBlt

[ARDA]

ok

#ColorBars(width=1920, height=1080, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999)
#fvertical()# 589.6 fps 1.004
#fvertical()# 608.4 fps 1.006
#flipvertical()# 580

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 49999)
fvertical()# 4296 fps 1.004
#fvertical()# 1523 fps 1.006
#flipvertical()# 1740

fixing, fixing
Thank you ARDA

[jmac698]

Ever see the changelog for x265?
http://hg.videolan.org/x265
2 weeks ago Dnyaneshwar G asm: reduced 'vpermq' instructions, improved 1040c->800c, 22%
6 days ago Dnyaneshwar G asm: avx2 code for sad_x3_64xN, improved over 40% than SSE
6 days ago Dnyaneshwar G asm: avx2 code for sad_x3_32xN, improved over 40% than SSE
3 weeks ago Dnyaneshwar G asm: AVX2 code for pixel_var primitive, improved over 40% than SSE
2 weeks ago Rajesh Paulraj asm: avx2 8bpp code for chroma_p2s[16xN] for i420, i422, improved over 25% than SSE
2 weeks ago Rajesh Paulraj asm: avx2 8bpp code for convert_p2s[16xN],improved over 25% than SSE
2 weeks ago Rajesh Paulraj asm: avx2 code for sad_x4_48x64, improved over 25% than SSE
2 weeks ago Rajesh Paulraj asm: avx2 code for sad_x4_64xN, improved over 40% than SSE

This all adds up - if you look at http://www.compression.ru/video/codec_comparison/h264_2012/ you can see a comprhensive test of a previous codec, x264, as it progresses in both speed and quality over time, and with such a compute heavy task, the asm is a significant part. Things like motion search can't be cheated on without impacting quality, it just has to be optimized.

Also, on my machine, his version is 34% faster than the compilers, and this a fair comparison, even though he's using an old compiler, because I'm also using an old machine.

The many times faster version posted is using a trick to avoid memcpy in the first place, not an algorithmic speedup, that doesn't mean that there aren't times when a memcpy has to be used. Flipping vertical isn't the endgame here.

So what is a practical endgame? Perhaps replacing the virtualdub function,
BitBlt(g_hdcAboutDisplay, 0, 0, r.right, r.bottom, hdc, 0, 0, SRCCOPY);.
This would allow realtime screen capturing, and a 34% difference could make or break 30fps capture, for example.

ps h265 report is due any day now
http://www.compression.ru/video/codec_comparison/call_for_codecs_15.html

[foxyshadis]

Does shaving one or even ten seconds off of your 4-12 hour encode really add up in the end? Because that's what we're talking, a thousandth to a hundredth of a second difference per frame, even on your decade old Core 2 Duo. There's no way that anything else you could with each frame would make the savings worthwhile; encoding captured frames is still 99% of the time.

Back in the Pentium MMX and P2 days, gaming with a faster BitBlt was a big deal, but those days are long gone now.

[ARDA]

Does shaving one or even ten seconds off of your 4-12 hour encode really add up in the end?
Because that's what we're talking, a thousandth to a hundredth of a second difference per frame,
even on your decade old Core 2 Duo. There's no way that anything else you could with each
frame would make the savings worthwhile; encoding captured frames is still 99% of the time.

Back in the Pentium MMX and P2 days, gaming with a faster BitBlt was a big deal, but
those days are long gone now.
You will not find a line in my posts where I say that the optimitization of bitblt will
increase generall performance in fact I've said that it was very difficult to know
Anyway avisynth can create so complex and different chains that it is almost
imposible to preview and measure the use or not and/or the weight of bitblt-memcpy in general performance.

But also added that understimate the importance of assembly optimization was a tendency
That could lead to conclude, is it worth to do faster assembler implementations?
Maybe better to leave compilers do the job, or maybe everytime we jump to a new
higher resolution we buy a new and faster cpu. There are a lot of academic discussion
all over in the net about it , I wouldn't like this thread becomes a discussion about
this subject. Mainly because it is more related to commercial politics of corporations
and ideology of Universities about how to prepare new software engineers
and definitely this is not the place for such a polemic.

I've also pointed my doubts about the weight of bitblt-memcpy in general performance
Anyway it is quite obvious that bitblt-memcpy(weight??) is one of the steps that can influence in general
avisynth performance, but it is not the only one.

And maybe this is my approach to an opinion about what in my modest opinion should be the
spirit in avysinth development. Maybe this statement has offended anyone, my apologies
if that was the case.
Every filter or part of avisynth authors should take care of the performance of their
work
A minor precision, the implementation of Steady Bitblt was once ISSE and early SSE and had a relative
importance because it was made together with many other avisynth optimizations.
It was aperiod of great and enthusiastic development with many people contributing for that, and Sh0dan
leading the process.

This all adds up - if you look at http://www.compression.ru/video/code...son/h264_2012/
you can see a comprhensive test of a previous codec, x264, as it progresses in both speed
and quality over time, and with such a compute heavy task, the asm is a significant part.
Things like motion search can't be cheated on without impacting quality, it just has to
be optimized.
If this jmac698 post is taked out of context and simplified it to the point you will not gain nothing
cause the rest of process will take 90% of the time, we can conclude infinite things that
are not what jmac698 is saying; he is claiming that general assemabler optimizations are
important in many projects and enviroments, it was just an example.

Finally as I have said previously I didn't want this thread to become a battle of ideas
about the utility of optimizations or not, but I failed, this discussion entered by the window
with an intention that I still cannot manage to figure out.
Avisynth in an open source project and this process there will contributions more important
than others, my intention was to get help to finish a difficult part of the job, cause
many cpus are needed to check(bypass cahce values) and share this code with the community,
no more no less.
Allow me please without understimating anyone to end my participation in this discussion, and
I will focus to finish this work.
I hope you all can understand

Thanks to all ARDA

[jpsdr]

If you like working on this, learn things, and want to achieve a goal, so be it.

But, if you provide something only for x86 and nothing for x64, just to warn you that the part of the community interested risk to be greatly reduced.

[jmac698]

I finally ran my tests for version 1.007
https://www.sendspace.com/file/7nhf8z

[ARDA]

have a hunch that the plugin is cheating somehow
.......... is having some fun but without seeing the source code...

Finally I've had some free time and could work on flipvertical, and now we all can have
some fun and also we all win, nobody loses.And we also can satisfy our curiosity
of how to do a FlipVertical without using memcpy. I don't know if anyone has published
sonething similiar before, anyway I hope it can be usefull to clarify some points.
This is an open source version of the magic almost 0 cost version for flipvertical
by using subframe and subframeplanar. In fact this option needs only two lines of code.
You can see them in bold in the source below, most of the work is done with avisynth api
and internal avisynth frame managment.
This version of flip vertical has almost 0 cost, cause in fact it does nothing except a
reasignment of pointers and invert pitch.
It is a simple code without any optimization if there be any.

It was a bad idea to choose flipvertical to study bitblt/memcpy, cause the best
memcpy is that one is never done. But also because flipvertical only use the row memcpy
way, in fact the slowest form to do it. My mistake was to emulate the way flipvertical is
implemented in avisynth, without analyzing deeply this function,my apologies for that.
My intention was to use something familiar for everybody and simple to use as a benchmark tool.

This thread was intended to be a place to discuss, receive feedback and help for the development
of bitblit/memcpy, mainly to get the bypass caches values for different cpus. But this, the main purpose
of this thread was completely distorted, became a competition between different versions of
flipvertical, which in fact is not important itself.My apologies for that too.
If I get some more free time, perhaps in a near future I will resume the study of bitblt/memcpy in another thread.

Usage: NewFVertical()

Here's the code:

#include <windows.h>
#include "avisynth.h"
class NewFVertical : public GenericVideoFilter
{
public:
NewFVertical(PClip _child, IScriptEnvironment* env);
~NewFVertical();
PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);
};
NewFVertical::NewFVertical(PClip _child, IScriptEnvironment* env): GenericVideoFilter(_child){}
NewFVertical::~NewFVertical(){}
PVideoFrame __stdcall NewFVertical::GetFrame(int n,IScriptEnvironment* env)
{
PVideoFrame src = child->GetFrame(n, env);
const int src_pitch = src->GetPitch();
const int height = src->GetHeight();
const int yoffset = src_pitch*(height-1);
const int row_size = src->GetRowSize();

if (!src->GetPitch(PLANAR_U)){
return env->Subframe(src, yoffset, -src_pitch, row_size, height);
}
else{
return env->SubframePlanar
(src, yoffset, -src_pitch, row_size, height,
src->GetPitch(PLANAR_U)*(src->GetHeight(PLANAR_U)-1),
src->GetPitch(PLANAR_V)*(src->GetHeight(PLANAR_V)-1),-(src->GetPitch(PLANAR_U)));
}
};
AVSValue __cdecl Create_NewFVertical(AVSValue args, void*, IScriptEnvironment* env)
{
return new NewFVertical (args[0].AsClip(), env);
};
const AVS_Linkage *AVS_linkage = 0;
extern "C" __declspec(dllexport) const char* __stdcall
AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors)
{
AVS_linkage = vectors;
env->AddFunction("NewFVertical", "c", Create_NewFVertical, 0);
return "NewFVertical, Flip vertically a clip";
};
NewFVertical Source and dll (https://mega.nz/#!UZsHnIoA!yrE2Hm5bZoGyR1QxI_gI6aozttEvYL76P_9nNbcTNDo)

[Nevilne]

This thread is literally the essence of doom9 (bar ripping).

[colours]

Just going to leave this here. (https://i.imgur.com/VSR1pTB.png)

If your intention had been to analyse or improve memcpy, you could've posted your findings to a forum about that. Not the "Avisynth Development" forum for, you know, the development of AVS and AVS plugins.

Just so you know, minimising memcpy/blits was deemed to be so irrelevant to processing with AVS in this day and age that AVS+ developers decided to make Crop() default to blitting every time, and this has negatively affected basically nobody.

[Chikuzen]

Just so you know, minimising memcpy/blits was deemed to be so irrelevant to processing with AVS in this day and age that AVS+ developers decided to make Crop() default to blitting every time, and this has negatively affected basically nobody.

That's not AVS+ way but VapourSynth way.
Unless crop the left side, avs+ does not execute memcpy.
And AVS+ avoid memcpy if crop left value is mod32.

[colours]

That's not AVS+ way but VapourSynth way.

My bad; I must've confused the two.

Point still holds, though: https://github.com/AviSynth/AviSynthPlus/commit/4a03e061aad110dd9b9892f2011829d7f320215e