Оптимизации avisynth

В том то все и дело: я не на уровне протокола обмена в GoogleDoc оптимизировал, а вносил реальные улучшения в код avisynth (mvtools2 пока не трогал, т.к. на CPU+GPU самым тяжким является SAD16x16, которая оптимизирована для текущих процессоров. Вот для процессоров с AVX2 ее можно ускорить - к сожалению AVX инструкции (1-е поколение) не дают никакого прироста, даже наоборот).

Вы одновременно и правы, и не правы: с одной стороны - да - это тест совтовой части, которая должна быть идентичной для всех платформ, с другой стороны вы произвели оптимизации в самом svpflow, создав разницу в исполнении между mvtools2_svpmark.dll и svpflow1.dll. На разных платформах разница может варьироваться. Таким образом имеем марк, который не отражает реальной производительности svpflow.
Я извиняюсь за свое поведение и удалю (если вы еще не успели) данные о моих замерах. Я их использовал для сохранения данных о тестировании на разных машинах (у меня две рабочие лошадки - дома и на работе) и выбора оптимального решения. Извините если ввел в заблуждение остальных пользователей SVP.

yartat
В том то все и дело: я не на уровне протокола обмена в GoogleDoc оптимизировал, а вносил реальные улучшения в код avisynth (mvtools2 пока не трогал, т.к. на CPU+GPU самым тяжким является SAD16x16, которая оптимизирована для текущих процессоров.

Оптимизации ....
Chainik некогда , смотрит 3 телевизора и проектор   
Может вам все же посмотреть mvtools2 ?
Дело в том , что при построении кадра используется матрица векторов вполне определенного размера . Матрица целочисленная .
Сегодня свп умеет :
1 Построить пирамиду . Где имеет место быть уровень построения=реальному кадру (0 уровень).
2 Используются все возможные уровни для поиска векторов , т.е. уровень построения деленный на 2 (1 уровень) . Деленный на четыре (2 уровень) и т.д.
3 СВП имеет механизм полу-четверть пиксельного поиска . Что интересно - Chainik уверяет , вычисления всегда целочисленные .

Таким образом можно получить пиксельную точность матрицы векторов , используя полупиксельную точность поиска по вдвое меньшему изображению (1 уровень пирамиды) .
Можно получить пиксельную точность , используя вчетверо меньшее изображение и четвертьпиксельную точность поиска (2 уровень) .
По тому же вчетверо меньшему изображению можно уточнить до полупиксела и получить двухпиксельную точность .

Теперь вывод :

Можно вполне избавиться от построения 1 уровня пирамиды (вдвое меньшие линейные размеры основного изображения)
Тем самым уменьшить нагрузку от поиска в 2-3-4 раза .
И возможно , будет хватать скорости обмена математика-данные . Ибо затраты на поиск векторов на 1  уровне больше затрат на все остальные меньшие уровни вместе взятые .

1080р при наличии совместимой видяйки для построения ....Короче говоря , в магазин бежать не нужно .

Если что-то непонятно - попробую разъяснить . Но в программировании я уже ничего не смыслю 

Chainik
Мне иногда , вернее всё чаще , кажется ...что тебе доплачивают амд и интел . И почему-то совсем не смешно 

Если уже самому не интересно поэкспериментировать , например, с поиском движения в двух последовательных кадрах , поискать зумм или вращение , добавить штраф САД от контраста ....да мало ли чего ещё ...
Не отбивай желание людям . Уверяю , логику происходящую внутри свп , объяснить смогу .

%username%
вот и справку бы сделал, полную, исчерпывающую.
Справку к чему ?
Для тех настроек , что выведены в профиль , справка ненужна .
Те настройки , что есть в override нужно менять комплексно .

Даже те , кто числится в бета-тестерах ...не имеют такого кол-ва времени ...чтобы предложить свои настройки . Увы .
Сегодняшнии настройки - это плод железобетонного терпения MAG79 .

Вот и бьюсь , чтобы расширить круг пользователей свп до сотен тысяч , а не сотни пользователей - как сейчас . Тогда появятся лишние глаза и можно будет наконец перейти от железа к качеству ...Ну а пока - свп слишком нишевый продукт .

LordMerlin
Почему нельзя делать собственную сборку Ависинта

наверное потому что нельзя иметь в системе два разных ависинта
Уже были претензии по поводу версии, а если она будет еще и твикнутая - совсем нехорошо будет.

%username%
Уже были претензии по поводу версии, а если она будет еще и твикнутая - совсем нехорошо будет.

Все будет прекрасно . Твикать ничего не придется , ибо здесь чистая логика .
В свп поиск векторов и построение разделены . Ничего не мешает применить механизмы масштабирования векторов .
Существенные отличия в поиске 3.0 и 3.1 ...Далеко не факт , что все нововведения приносят реальную пользу .
Именно огромная нагрузка от поиска тормозит развитие свп . Шутка что ли , топовые камни едва справляются . Неговоря уже о проблемах с рендерами , дропами .

Про шаг поиска рассказываю , для тебя лично :
1 Все , что больше шага 16 пикселей - зло для поиска . Невозможно обеспечить нормальную подвижность пирамиды (механизм поиска векторов). В результате невозможно получить максимальную подвижность векторов .
2 Шаг 8 пикселей и меньше - наоборот , имеют излишнюю подвижность . Практически нереально удержать такую картинку "в рамках приличия"
3 Использовать следует блоки (шаг) 16 пикселей . Можно с минимальным перекрытием (14) . С перекрытием (12) - не всегда лучше , ибо само перекрытие блоков вносит ограничения на взаимную подвижность векторов .

Таким образом следует использовать шаг 16,14,12 пикселей . Но для мелких ПАЛ разрешений результирующая картинка , увеличенная до размеров монитора рендером, при таких блоках будет выглядеть недоуплавненной . Решение есть - это кратное увеличение картинки (в 2-3 раза) , или кратное физическому размеру монитора (ресайз до 1080р очень тяжелая нагрузка) .

По радиусу - отдельная песня , в большинстве случаев - на вкус и цвет товарища нет . Сейчас из интерфейса недоступно , но 3 пиксела будет оптимально для блоков 12-14 , 4 пиксела для 16 .

Вопросы у тебя есть ?

%username%
Видишь как интересно 
Меня MAG79 не один год учил , и вместе учились 
Конечно , если собрать в кучу картинки , которые сделал MAG79 , и раскоментировать как следует , то может дойдет за пару дней . А может совсем не дойдет - здесь Chainik прав .

Можешь просто принять на веру .
шаг поиска :
1 Входящее изображение режется на кусочки - расстояние между этими кусочками (блоками) и есть ШАГ поиска .
2 На сегодня движение можно искать лишь блоками - никаких шестиугольников , окружностей и т.д. недоступно .
3 Из интерфейса 3.1 доступны блоки (квадратные кусочки) - 8*8  , 16*16 , 32*32 . Размер указан в пикселах изображения .
4 Шаг поиска на сегодня - размер блока и перекрытие этих блоков . Т.е. вовсе не обязательно резать изображение ровно по границам этих блоков (кусочков) , изображение можно порезать с перекрытием этих блоков . Перекрытие - кусочки наползают друг на друга , края этих кусочков общие для соседних блоков (кусочков)
Пример :
шаг 16*16 - это порезанное изображение на блоки 16*16 без перекрытия .
шаг 14*14 - это порезанное изображение на блоки 16*16 с перекрытием 2 пиксела по краям этих блоков .
шаг 12*12 - это порезанное изображение на блоки 16*16 с перекрытием 4 пиксела по краям этих блоков .

И т.д.

Из входящего изображения строится пирамида , которая представляет собой :
1 Основание пирамиды = реальное изображение
2 Каждый следующий этаж(уровень) меньше предыдущего в 2 раза . Т.е. линейные размеры меньше в два раза . По площади высота*ширина=2*2=4 т.е. в каждом следующем этаже пикселей в 4 раза меньше .
3 Основание пирамиды принято за 0 уровень
соответственно уровень выше (меньше) будет 1 уровнем .

Каждый из этих этажей делится на кусочки - блоки .

Поиск движения начинается с самого верхнего этажа , постепенно опускаясь вниз - к уровню построения (0 уровень) .

Дальше нужна наглядность , с этим у меня туго .