FlipVertical and New BitBlt

[jmac698]

flipvfaster, avisynth+ (and all were win8.1 x64)
Frames processed: 5000 (0 - 4999)
FPS (min | max | average): 18.00 | 48.78 | 40.75
Memory usage (phys | virt): 22 | 23 MB
Thread count: 3
CPU usage (average): 49%

Time (elapsed): 00:02:02.707

so, guess TheFluff is wrong, and this new bitblit is far superior to anything existing

also I'm getting a bug in flipvfaster, the V channel is always 0.

[ARDA]

@jmac698
Thanks for your contribution, it is very important, mainly after this litlle storm that
has unfocus me from the task we have here, that is, for now to fix the bypass cache values for
any different architecture and configuration. But we must consider that these are tests that
sometimes measure some fvertical codes that work in place, against internal flipvertical that in
all cases uses bitblt-memcpy, and in the majority of cases by using backward block copy techniques
and finished with non temporal store, why all that? cause steady-Sh0dan bitblt-memcpy were written
in a time when most of cpus had a L2 of 256kb or 512kb(maximum) and the bypasses value were fixed for that
largest cache sizes, which made non temporal store the best option almost always and the hardware
predictors were not as good as are in nowadays machines, and by doing backward, bitblt avoided that
destination buffer were loaded in cache and the correspondant penalizations, cause caches lines
continous flushing.
For all that I ask you a little more effort by doing the following test, you can use this
script in which please post back your results, those frame sizes chosen are just examples
you can do any others if you want, but it is probably I will be asking you for two or three
more tests after analyzing your results:rolleyes:


# Insert here
# Vendor ,Family ,Model ,instruction set ,Largest cache

#test320x256yv12
#colorbars(width = 320, height = 256, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 99999)
#flipvertical() #..... fps
#fvertical() #..... fps

#test448x320yv12
#colorbars(width = 448, height = 320, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 99999)
#flipvertical() #..... fps
#fvertical() #..... fps

#test640x480yv12
#colorbars(width = 640, height = 480, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 99999)
#flipvertical() #..... fps
#fvertical() #..... fps

#test720x576yv12
#colorbars(width = 720, height = 576, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 99999)
#flipvertical() #..... fps
#fvertical() #..... fps

#test1392x992yv12
#colorbars(width = 1392, height = 992, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 99999)
#flipvertical() #..... fps
#fvertical() #..... fps

#test1392x1024yv12
#colorbars(width = 1392, height = 1024, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 99999)
#flipvertical() #..... fps
#fvertical() #..... fps

#test1920x1080yv12
#colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 99999)
#flipvertical() #..... fps
#fvertical() #..... fps

#test5000x3000RGB32
#colorbars(width = 5000, height = 3000, pixel_type = "rgb32").killaudio().assumefps(25, 1).trim(0, 9999)
#flipvertical() #..... fps
#fvertical() #..... fps

Thanks in advance ARDA:thanks:

[Myrsloik]

Did I really manage to put a bug in that simple code?

Here's an updated FlipVFaster (https://dl.dropboxusercontent.com/u/73468194/FlipVFaster2.7z). Don't get scared when you see the speed. Any previous speed tests done on subsampled planar formats were wrong in the previous version. So only HolyWu's tests show the objective truth.

[ARDA]

I simply pick 720p, 1080p and 4K resolution for common use cases. As FlipVFaster doesn't process
V plane correctly, I use a Y8 clip for benchmark.

#ColorBars(width=1280, height=720, pixel_type="YV12").ConvertToY8().KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#FlipVertical() # your cpu 10693 fps #my cpu 6456
#FVertical() # your cpu 15782 fps #my cpu 9108
#FlipVFaster(newbitblt=true) # your cpu 18281 fps #my cpu 8645

#ColorBars(width=1920, height=1080, pixel_type="YV12").ConvertToY8().KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#FlipVertical() # your cpu 4624 fps #my cpu 2726
#FVertical() # your cpu 7384 fps #my cpu 3484
#FlipVFaster(newbitblt=true) # your cpu 8619 fps #my cpu 3107

#ColorBars(width=3840, height=2160, pixel_type="YV12").ConvertToY8().KillAudio().AssumeFPS(25, 1).Trim(0, 49999)
#FlipVertical() # your cpu 768.9 fps #my cpu 520.4
#FVertical() # your cpu 727.6 fps #my cpu 597.4
#FlipVFaster(newbitblt=true) # your cpu 681.9 fps #my cpu 536.3
Your results are surprising for me and not fully coherents, that is why I will
prepared a special release taking into account your machine, if you agree I will
send you by pm. It seems to me that is the same problem I had with Groucho2004 cpu
around the bypass cache value.
And in the meanwhile I ask you please, to do the tests again
according to next post

Thanks ARDA;)

[ARDA]

In post http://forum.doom9.org/showthread.php?p=1735823#post1735823 there is a proposal of
a method to do benchmarks without the influence of other parts of the script.

Here is the script I use

MPEG2Source("xxxxxx.d2v")#720,576 or any other form of real clip source
crop(8,72,700,432,align=false)
ConvertToY8()
#LanczosResize(1920,1080)
#LanczosResize(1280,720)
#LanczosResize(3840,2160)
AvsTimer(frames=1000, name="ANYONE",type=3, frequency=1700, total=false, quiet=true)
#fvertical()
#FlipVFaster(newbitblt=true)
#flipvertical()
AvsTimer(frames=1500 ,name="ANYONE",type=3, frequency=1700, difference=1, total=false)

An here the results in my cpu with the same sizes

1280,720
VirtualDub.exe [91471] FlipVFaster = 4591 fps
VirtualDub.exe [94471] FlipVFaster = 5761 fps
VirtualDub.exe [95971] FlipVFaster = 5858 fps
VirtualDub.exe [97471] FlipVFaster = 5887 fps
VirtualDub.exe [98971] FlipVFaster = 5837 fps

VirtualDub.exe [91498] fvertical = 12431 fps
VirtualDub.exe [92998] fvertical = 12927 fps
VirtualDub.exe [94498] fvertical = 12818 fps
VirtualDub.exe [95998] fvertical = 12800 fps
VirtualDub.exe [97498] fvertical = 12823 fps
VirtualDub.exe [98998] fvertical = 12749 fps

VirtualDub.exe [91498] flipvertical = 5546 fps
VirtualDub.exe [92998] flipvertical = 5691 fps
VirtualDub.exe [94498] flipvertical = 5751 fps
VirtualDub.exe [95998] flipvertical = 5756 fps
VirtualDub.exe [97498] flipvertical = 5693 fps
VirtualDub.exe [98998] flipvertical = 5672 fps

1920,1080
VirtualDub.exe [91498] FlipVFaster = 2188 fps
VirtualDub.exe [92998] FlipVFaster = 2241 fps
VirtualDub.exe [94498] FlipVFaster = 2229 fps
VirtualDub.exe [95998] FlipVFaster = 2232 fps
VirtualDub.exe [97498] FlipVFaster = 2258 fps
VirtualDub.exe [98998] FlipVFaster = 2237 fps

VirtualDub.exe [91498] fvertical = 4702 fps
VirtualDub.exe [92998] fvertical = 4778 fps
VirtualDub.exe [94498] fvertical = 4740 fps
VirtualDub.exe [95998] fvertical = 4765 fps
VirtualDub.exe [97498] fvertical = 4849 fps
VirtualDub.exe [98998] fvertical = 4783 fps

VirtualDub.exe [91498] flipvertical = 2213 fps
VirtualDub.exe [92998] flipvertical = 2298 fps
VirtualDub.exe [94498] flipvertical = 2283 fps
VirtualDub.exe [95998] flipvertical = 2286 fps
VirtualDub.exe [97498] flipvertical = 2298 fps
VirtualDub.exe [98998] flipvertical = 2254 fps

3840,2160
VirtualDub.exe [91499] FlipVFaster = 498 fps
VirtualDub.exe [92999] FlipVFaster = 511 fps
VirtualDub.exe [94499] FlipVFaster = 512 fps
VirtualDub.exe [95999] FlipVFaster = 513 fps
VirtualDub.exe [97499] FlipVFaster = 512 fps
VirtualDub.exe [98999] FlipVFaster = 508 fps

VirtualDub.exe [91499] fvertical = 552 fps
VirtualDub.exe [92999] fvertical = 558 fps
VirtualDub.exe [94499] fvertical = 568 fps
VirtualDub.exe [95999] fvertical = 568 fps
VirtualDub.exe [97499] fvertical = 567 fps
VirtualDub.exe [98999] fvertical = 568 fps

VirtualDub.exe [91499] flipvertical = 468 fps
VirtualDub.exe [92999] flipvertical = 478 fps
VirtualDub.exe [94499] flipvertical = 480 fps
VirtualDub.exe [95999] flipvertical = 478 fps
VirtualDub.exe [97499] flipvertical = 479 fps
VirtualDub.exe [98999] flipvertical = 478 fps

As you can see, the results differ a lot from one kind of benchmar to another
I don't want to open a new polemic about benchmark methods, but just to confirm if you
also have differents results in your cpu:eek:

Thanks ARDA

[Reel.Deel]

Here's my results using AviSynth+ r1576, FVertical v1.003, and the updated FlipVFaster:

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#FlipVertical() # 4601 fps
#FVertical() # 9359 fps
#FlipVFaster(newbitblt=true) # 10160 fps

ColorBars(width=1920, height=1080, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#FlipVertical() # 1938 fps
#FVertical() # 4305 fps
#FlipVFaster(newbitblt=true) # 4756 fps

ColorBars(width=3840, height=2160, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 49999)
#FlipVertical() # 468.3 fps
#FVertical() # 627.3 fps
#FlipVFaster(newbitblt=true) # 577.3 fps


http://s13.postimg.org/h5nnelwyv/i7_4930k.png

[ARDA]

Here's my results using AviSynth+ r1576, FVertical v1.003, and the updated FlipVFaster
It seems the same situation in holywu cpu, luckily now I have data to fix bypass cache values. In the meantime if you have time, can you please do the benchmarks I asked holywu in the post previous yours.http://forum.doom9.org/showthread.php?p=1736973#post1736973


thanks in advance ARDA:rolleyes:

[ARDA]

@all

As I mentioned before, this bitblt-memcpy is still under heavy development, till I can fix all values in the TableByPass (at the end of BitBlt_SSE2_avs) benchmarks value must be considered provisory and as a reference for analysis; That is why I invite more users to join us as volunteers so we shall finish this quickly.:eek:

Thanks ARDA;)

[jmac698]

I had trouble getting avstimer to work. Here's how to do it:
http://www.avstimer.de.tf/ doesn't load for me. I got a version from
http://www.avisynth.nl/users/warpenterprises/
which needs
http://www.avsrecursion.de.tf/
which needs
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71

(the latter two need to be put in C:\Windows\SysWOW64 for windows 8.1 x64)
otherwise, you get this error:
Platform return code 126: The specified module could not found

Then I tried to open the benchmark script in virtualdub, but got "avi import error:(Unknown) (80040154)"
I had to reinstall avisynth. I think the problem was that uninstalling avisynth+ didn't return my system to using avisynth.

Now I'll try to get some benchmarks.

[ARDA]

@jmac698

sorry you you've gone into so many troubles, if you continue having problems with avstimer I think
i have statically compiled version that needs nothing to be used.

Thanks a lot for you effort, waiting results ARDA

[jmac698]

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999)
#FlipVertical() # 1243 fps
#FVertical() # 3201 fps
#FlipVFaster(newbitblt=true) # 1210 fps

Arda wins still.

I'm not getting very accurate timing, for example:
[9180] [1499] ANYONE = 1115.2 fps
[9180] [2999] ANYONE = 1208.7 fps
[9180] [4499] ANYONE = 1218.0 fps
[9180] [5999] ANYONE = 1204.1 fps
[9180] [7499] ANYONE = 1216.1 fps
[9180] [8999] ANYONE = 1210.7 fps


AviSynth 2.60, build:Mar 31 2015
win8.1 x64
T7300@2GHz
sse,sse2,sse3,ssse3
L1 32k
L2 4M

[jmac698]

ColorBars(width=1920, height=1080, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999)
#FlipVertical() # 474 fps
#FVertical() # 500 fps
#FlipVFaster(newbitblt=true) # 471 fps
avisynth 2.6
2ghz
l2 4M

[ARDA]

I'm not getting very accurate timing, for example:
[9180] [1499] ANYONE = 1115.2 fps
[9180] [2999] ANYONE = 1208.7 fps
[9180] [4499] ANYONE = 1218.0 fps
[9180] [5999] ANYONE = 1204.1 fps
[9180] [7499] ANYONE = 1216.1 fps
[9180] [8999] ANYONE = 1210.7 fps
If you are using blanclip as source, try to change it with a real clip
source , somthing like this


MPEG2Source("anyone.d2v") # or any other real clip source
#LanczosResize(1920,1080)#use the sizes you used in test with #avsmeter
#LanczosResize(1280,720)
#LanczosResize(3840,2160)
AvsTimer(frames=1000, name="ANYONE",type=3, frequency=???, total=false, quiet=true)
#fvertical()
#flipvertical()
AvsTimer(frames=1500 ,name="ANYONE",type=3, frequency=????, difference=1, total=false)

Be carefull with the frequency value, it is a divisor in avstimer math

Thank you again and keep on ARDA:rolleyes:

[jmac698]

ColorBars(width=3840, height=2160, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 49999)
#FlipVertical() # 126 fps
#FVertical() # 204 fps
#FlipVFaster(newbitblt=true) # 112 fps
interesting, 1080p wasn't much speedup but the others were.

[Groucho2004]

I'm not getting very accurate timing
If you really have to use AVSTimer, read the documentation carefully, otherwise you'll likely to get completely wrong results.

ColorBars() is a perfectly good substitute for a "real" clip, especially since it's very fast and therefore does not influence the result when using AVSMeter. Try just running ColorBars() without any filters, you'll see what I mean. Even on my ancient laptop (Core 2 Duo, 2.5 GHz) 1 frame takes about 1 microsecond (1000000 fps).

[ARDA]

@Grocuho2004

I beg you please, donnot misunderstand my request from jmac698 as if I don't trust on your
tool, nothing more far than my intention, but colorbars and blankclip always return a non
writable src which forces the use of bitblt, temporal or non temporal, and the results that
jmac698 has provided with avsmeter and colorbars always show that my code is fastest always,
I don't need anymore tests like that, it seems that the bypasses for a machine with L2 4Mb and
S_sse3 in biltblt are correct. With my request to do sometest with avstimer, I am trying to test
the other part of this plugin when eventually it can work in place, thing that is not too frequent,
but the work is already done, and I need of some more bypasses are in the project are working ok.
I hope my explanation is good enough for you:rolleyes:

Thanks ARDA

[Groucho2004]

@Grocuho2004

I beg you please, donnot misunderstand my request from jmac698 as if I don't trust on your
tool, nothing more far than my intention, but colorbars and blankclip always return a non
writable src which forces the use of bitblt, temporal or non temporal, and the results that
jmac698 has provided with avsmeter and colorbars always show that my code is fastest always,
I don't need anymore tests like that, it seems that the bypasses for a machine with L2 4Mb and
S_sse3 in biltblt are correct. With my request to do sometest with avstimer, I am trying to test
the other part of this plugin when eventually it can work in place, thing that is not too frequent,
but the work is already done, and I need of some more bypasses are in the project are working ok.
I hope my explanation is good enough for you:rolleyes:

Thanks ARDA
OK, 'nuff said.:D

[TheFluff]

So, thus far we've proven that the new bitblt probably isn't faster (or if it is, insignificantly so) and that you're trying to optimize a filter that even in the case where it has to copy the frame runs at around 10,000 fps (correct to an order of magnitude). Do you really use flipvertical() hundreds of times in a script? Because if you don't, this optimization is rather meaningless despite that impressive-sounding claim that you've doubled the performance. Is that really worth several thousand lines of assembler when it can be done with two dozen lines of C++? There's clarity, maintainability and correctness to consider as well.

Thus spake Donald Knuth (peace be upon him):
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
He said this in 1974 and it's just as true today, if not more so. Get with the times, already.

[jmac698]

I've used a lot of blits in scripts before, such as this one http://forum.doom9.org/showthread.php?t=158230
It needs several bitblts per frame

[Myrsloik]

I'm back with another updated FlipVFaster (https://dl.dropboxusercontent.com/u/73468194/FlipVFaster3.7z).

I've added a new function called FlipVFastest in addition to FlipVFaster. It will knock your socks off.

[TheFluff]

I'm back with another updated FlipVFaster (https://dl.dropboxusercontent.com/u/73468194/FlipVFaster3.7z).

I've added a new function called FlipVFastest in addition to FlipVFaster. It will knock your socks off.

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#flipvertical() # 7085 fps
#fvertical() # 10922 fps
#flipvfaster(newbitblt=true) # 11517 fps
#flipvfastest() # 1517663 fps


http://i.imgur.com/dHoYhsv.png

Measured with AVSMeter. No, that isn't a troll or a typo, flipvfastest really is two orders of magnitude faster.

[jmac698]

flip fastest is giving me 130,000fps - but I don't believe it, obviously. In reality it's twice as slow as flip faster. I'm going back to avsmeter.

[TheFluff]

In reality it's twice as slow as flip faster.

How did you measure this?

[jmac698]

@fluff
fps in virtualdub was much worse, but that test was invalid.

avsmeter

fvertical: 52.28
flipvertical: 42.94
flipvfastest: 52.71

avstimer
fvertical: 653
flipvertical: 314
flipvfastest: 25212

I changed the script a bit:
#Create a red square that moves
red_yuv=$4164D4#in REC 601
#Make a moving red square
global square=blankclip(length=1,width=50,height=50,pixel_type="YUY2",fps=24000, fps_denominator=1001, color_yuv=red_yuv,sixteen_bit=true)
background=ColorBars(width=1920, height=1080, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999)
ScriptClip(background,"""
overlay(square,x=103-25+(current_frame%160)*8,y=240-25)
""")
AvsTimer(frames=1000, name="ANYONE",type=3, frequency=2000, total=false, quiet=true)
fvertical()
#FlipVFastest()
#flipvertical()
AvsTimer(frames=1500 ,name="ANYONE",type=3, frequency=2000, difference=1, total=false)
avsmeter ran instantly with just colorbars

[TheFluff]

I changed the script a bit:
#Create a red square that moves
red_yuv=$4164D4#in REC 601
#Make a moving red square
global square=blankclip(length=1,width=50,height=50,pixel_type="YUY2",fps=24000, fps_denominator=1001, color_yuv=red_yuv,sixteen_bit=true)
background=ColorBars(width=1920, height=1080, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999)
ScriptClip(background,"""
overlay(square,x=103-25+(current_frame%160)*8,y=240-25)
""")
AvsTimer(frames=1000, name="ANYONE",type=3, frequency=2000, total=false, quiet=true)
fvertical()
#FlipVFastest()
#flipvertical()
AvsTimer(frames=1500 ,name="ANYONE",type=3, frequency=2000, difference=1, total=false)
avsmeter ran instantly with just colorbars
with that kind of script+avsmeter you're basically benchmarking the avisynth script interpreter, not flipping the image

avsmeter ran instantly with just colorbars
well yes that will kinda happen when your only "filtering" is something capable of running at literally a million fps

e: just use a longer clip, tack on .loop() to the end of the source line:
AVSMeter 2.1.1 (x86)
AviSynth+ 0.1 (r1576, x86) (2.6.0.5)

Number of frames: 10000000
Length (hh:mm:ss.ms): 111:06:40.000
Frame width: 1280
Frame height: 720
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 10000000 (0 - 9999999)
FPS (min | max | average): 567002 | 1544474 | 1454652
Memory usage (phys | virt): 16 | 13 MB
Thread count: 1
CPU usage (average): 24%

Time (elapsed): 00:00:06.874

[jmac698]

now with 4k frames:

avstimer
fvertical: 89.1
flipvertical: 88.4
flipvfastest: 75078

ok at this point I'm suspicious, maybe it's only doing the calculation if something after it is actually using the data, for example I got this to run faster if I followed it with pointresize(960,540) (113,000fps). This is why I made the moving square, just to make sure it wasn't "cheating". Now if I start with 1920 and resize to 3840, it slows down to 90,000fps.

I'm not really sure what's going on.

[jmac698]

@fluff:

yes you're right about avsmeter, however I kept adding to the length until it exceeded the maximum possible value and it was still instant, so I didn't pursue it. I'll see if I can recreate your example.

[jmac698]

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999999)
#fvertical()
FlipVFastest()
#flipvertical()
loop(100)
326,000fps with avsmeter

but being able to measure an essentially null function isn't really the problem, I think it's just being smart about not doing anything to parts of the frame that aren't being used further.

If that's the case, the benchmarking has to be improved. If it's not the case, my apologies and congrats for making an amazingly fast filter :)

[jmac698]

compare

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999)
#fvertical()
FlipVFastest()
flipvertical()

loop(10)

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999)
#fvertical()
#FlipVFastest()
flipvertical()

loop(10)


1: 1650fps
2: 1423fps

so it is taking a measurable amount of time

[AzraelNewtype]

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999999)
#fvertical()
FlipVFastest()
#flipvertical()
loop(100)
326,000fps with avsmeter

but being able to measure an essentially null function isn't really the problem, I think it's just being smart about not doing anything to parts of the frame that aren't being used further.

If that's the case, the benchmarking has to be improved. If it's not the case, my apologies and congrats for making an amazingly fast filter :)

Why exactly are you putting loop() after the flipping is already done?

[jmac698]

Nothing to worry about, just leftover code from when I was trying to measure something that was too fast. All it does is multiply the frame count.

[AzraelNewtype]

Nothing to worry about, just leftover code from when I was trying to measure something that was too fast. All it does is multiply the frame count.

It multiplies the frame count, but not the calls to the functions you're benchmarking. At least, it doesn't if you put it there. TheFluff suggested appending it to the source for a reason.

[jmac698]

duhhh yes of course

[Groucho2004]

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 9999999)
#fvertical()
FlipVFastest()
#flipvertical()
loop(100)
326,000fps with avsmeter

but being able to measure an essentially null function isn't really the problem, I think it's just being smart about not doing anything to parts of the frame that aren't being used further.
I have a hunch that the plugin is cheating somehow and Myrsloik is having some fun but without seeing the source code...

By the way, colorbars() creates a clip with ~107000 frames, your ".Trim(0, 9999999)" is ignored.

[Myrsloik]

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

By the way, colorbars() creates a clip with ~107000 frames, your ".Trim(0, 9999999)" is ignored.

I'm definitely having fun, yes. But you can't prove the output is wrong. I win, you lose!

Hint: The code is even shorter now

[jpsdr]

If flipvertical swaps top/bottom, the fastest way is just to change the pointer adress to the bottom of picture, and reverse the value of the pitch. It works like this in VDub if you're using old/original interface : src is guarantee to be the top of the picture, but never said it's the top of the data, and never assume that pitch is always positive.
If Myrsloik is using a trick like this, it's possible that if you put after his pluggin another pluggin that assume that pitch is always positive, you may create a crash. Now, if in avisynth it's a rule that pitch is always positive, and Myrsloik is doing something like this, finaly ouput is wrong (if it's the case, i win... :D).
To check it, you should create a pluggin which does nothing, but test if pitch is negative

[Myrsloik]

That's an interesting thought. But I invoke the universal law of API usage.

"If the API doesn't block it it's fine"

[jpsdr]

I think i'll check and probaby update nnedi to not assume that pitch is always positive. I'm always doing that i VDub filters, but i don't know when or where, in doom9 i was told that for avisynth pitch is always positive, so, i assumed it was an avisynth rule/standard. If finaly it's not the case, i personnaly don't mind (in fact, from my point of view it's more logical), and check and update my avisynth pluggins to not think that pitch is always positive.

About VDub, in the old times when only RGB32 was supported, data was stored in bmp format, so the top of data was the bottom of picture, and also src was. In the last VDub API, for me it's more logical, src is always the top of picture, whatever how data are stored, so pitch can be either positive or negative. That's why pitch always have been a ptrdiff_t.

So finaly, pluggin is not cheating, it just being smart and "worrying about efficiency in the right places and at the right times"

[wonkey_monkey]

If flipvertical swaps top/bottom, the fastest way is just to change the pointer adress to the bottom of picture, and reverse the value of the pitch. It works like this in VDub if you're using old/original interface : src is guarantee to be the top of the picture, but never said it's the top of the data, and never assume that pitch is always positive.

Interesting idea, but isn't GetReadPtr defined as returning the start of the entire frame in memory, i.e. its first (lowest address) byte? Not as the first byte of the "first" line...

Anyone who was expecting to use memcpy, for example, to copy a few lines at a time would find their plugin broken.

The API docs go as far as to suggest this:

int buffer_size = src->GetPitch() * src->GetHeight(); //YUY2, interleaved

to calculate frame size in bytes, so it seems a positive pitch is at least expected to be safe to assume.

[Myrsloik]

Interesting idea, but isn't GetReadPtr defined as returning the start of the entire frame in memory, i.e. its first (lowest address) byte? Not as the first byte of the "first" line...

Anyone who was expecting to use memcpy, for example, to copy a few lines at a time would find their plugin broken.

The API docs go as far as to suggest this:



to calculate frame size in bytes, so it seems a positive pitch is at least expected to be safe to assume.

There's very little real reference documentation for Avisynth and the original intentions are most likely lost. In most other frameworks negative pitch is totally a thing and there's no reason to think otherwise here. I believe all internal functions handle negative pitch at least.

Avisynth also actively discourages memcpy since it provides BitBlt which does handle it properly. Besides, if you do a proper check before memcpy you'd find that src_pitch != dst_pitch so you'll have to go line by line anyway. (this happens if your filter is after cropping so you have to support that properly anyway)

Anyway, if it's not allowed YOU MUST MAKE THE API REJECT IT. Simple rule. If it's accepted and passed on you'll simply get someone else's plugin blamed for crashes.

[jpsdr]

For fun and personnal usage, i've created a kind of "pitcure/image" class. I provide several informations : The start/top of picture, the start/top of the whole picture (in case subframe/cropping was created) and the start of the frame in memory. The last one can be different of previous, if it's a BMP memory data which is created.


void * AddrStartCurrentImage(void) const {return(ImageAddr);}
void * AddrStartFullImage(void) const {return(ImageAddr0);}
void * AddrStartFullData(void) const {return(DataAddr);}


So, i personnaly totaly agree with Myrsloik point of view.

[Myrsloik]

I think there's one test missing in this flip comparison. Force line by line copy.

For example:
ColorBars().Crop(a bit to the left and right).Flip()

Then you can't simply copy one huge region anymore. I suspect it will result in similar results but you never know...

Obviously I mean memcpy comparison.

[mawen1250]

E3-1230v2
Windows7 x64
AviSynth+ r1576

ColorBars(1920, 1080, "YV12") #7097595fps

#FlipVertical() # 3109fps
#FVertical() # 4000fps
#FlipVFaster() # 4600fps
#FlipVFastest() # 2830798fps
Every zero-copy filter will reduce the speed to about half, and here's the case of minimal function calls.

[ARDA]

With the help of Ree.Deel we'got to fix the performance of the new bitblt in a range
of values (sizeframe) when temporal store is chosen, this should be better for any cpu with 8 mb
of L3 cache (HollyWu's one) or larger with avx. I need more volunteers please, but nowadays
I would like to see any result in AMD machines, nobody has posted one if I am not wrong. Those who has
old cpus but are SSE2 capable can also post results. This project is intended to have
backward compatibility for all. It is not a competition between machines. It is an
open source project to be shared.
Link to download here or in the first post
Version 1.004 Fvertcal.dll (https://mega.nz/#!hVtShDAY!305YLuXYMoL_pkbiXRSvudnh30i2KKuEBK8knhC68ug)
I hope you find it usefull ARDA

[ARDA]

Here's my results using AviSynth+ r1576, FVertical v1.003, and the updated FlipVFaster:

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#FlipVertical() # 4601 fps
#FVertical() # 9359 fps
#FlipVFaster(newbitblt=true) # 10160 fps

ColorBars(width=1920, height=1080, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#FlipVertical() # 1938 fps
#FVertical() # 4305 fps
#FlipVFaster(newbitblt=true) # 4756 fps

ColorBars(width=3840, height=2160, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 49999)
#FlipVertical() # 468.3 fps
#FVertical() # 627.3 fps
#FlipVFaster(newbitblt=true) # 577.3 fps

And now a comparation between Fvertical versions 1.003 and 1.004(both in first post)


Here you go:

#size frame 1382400, bypass 5033168, tpa store in 12mb L3 cache
#ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#FVertical() # 9359 fps version 1.003 # 10956 fps version 1.004

#size frame 3110400, bypass 5033168, tpa store in 12mb L3 cache
#ColorBars(width=1920, height=1080, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#FVertical() # 4305 fps version 1.003 # 4996 version 1.004

Nice improvement :)

If anyone has had bad results with fvertical with these same resolutions, I beg you please repeat with
version 1.004 (see first post) and post here. Soon version 1.005
Thanks in advance ARDA

[ARDA]

Small changes, some improvemnt when non temporal row loops in avx machines or up
Still need volnteers to benchmark some AMD machines
Enjoy
Version 1005 Fvertical.dll (https://mega.nz/#!RFdRHaKI!qa15JjN58CuiPlIAu2m6H-sJFDwkfphAXq5ghNg-Qh8)

Thanks ARDA

[ARDA]

With the colaboration of many members of this forum, I dared to do important changes
Most of cache bypass values have been adjusted, some controls had been avoided, I hope not to have
introduced many bugs.
Still need volnteers to benchmark some AMD machines
Enjoy
Version 1006 Fvertical.dll (https://mega.nz/#!8ItFARgY!lvb8Vv5qjJurghNQ8JLaLrTb4K29m-5FeASHKVaShbY)

If you want to test more options about the new bitblit, follow this link with a new toy to
play with
NewTool ( http://forum.doom9.org/showthread.php?p=1740869#post1740869)

Thanks ARDA

[jmac698]

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#fvertical()# 1523 fps
flipvertical()# 1740
oops some probs here


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

avisynth 2.606

[ARDA]

ColorBars(width=1280, height=720, pixel_type="YV12").KillAudio().AssumeFPS(25, 1).Trim(0, 99999)
#fvertical()# 1523 fps
flipvertical()# 1740
oops some probs here

Most of cache bypass values have been adjusted, some controls had been avoided, I hope not to have
introduced many bugs.

Yes I have introduced some bug, please test version 1.003 and 1.004
from the first post.
Thanks ARDA;)

[jmac698]

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