Search options (Page 3 of 4)

При том же коде - да. Но самые тяжелые операции SAD16x16 и SAD8x8 на AVX2 будут обсчитывать в 2 раза больше (256 vs 128 - сейчас). Теоретически это даст прирост в 60% на функции SAD. Есть еще один нюанс: компания Intel без всякого шума и фанфар подтягивает производительность некоторых "старых" операций. В Core 2 например подтянули скорость rep movsd. Причем так, что использование SSE2 не дает никакого доп. преимущества.

Протестировал Catalyst 12.10. Рост 2-2.5% (2692 vs 2634) по сравнению с 12.8. Версия с доработанным avisynth так же дала рост 3% (2784 vs 2695). В общем рекомендую 12.10 для HD7xxx

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

Siluyanov_M
Выбрал 3770K на основании предварительных результатов замеров от MAG79. Кроме того SVP хорошо реагирует на включение технологии HT.
в итоге собрал HTPC:

• Процессор 3770K разогнанный до 4.2 GHz

• Мать ASrock Z77 Extreme4 - без лишних навесов, но с быстрой перезагрузкой (Ultra fast reboot <=1 сек) с поддержкой S5 и достаточным околосокетным пространством для кулеров (нарезаны дырки для 775 и 1155)

• Память - не помню - какая-то 1866

• Видео Geforce 640 - как показали тесты в указанной связке обеспечивает 60 fps в режиме highest, и при этом тихая и практически не греется. Видяху не гнал.

Youtube в очередной раз поменяли форматирование. Сам неделю назад правил в своих продуктах regex-пы.

Ув. Chainik,
видимо со стороны мои посты выглядят как вызов. Поверьте, это не так: я активно использую SVP с 3.0 при просмотре на HTPC и очень ею (программой) доволен (спасибо вам за труд). До недавнего времени я использовал довольно слабый Феном 2 и не имел никаких проблем, но недавно поменял систему на иву и захотелось большего качества. Сразу после этого вылезли проблемы с памятью. Собственно говоря с этого момента я и заинтересовался что там внутри.
Я мог бы помочь разработчикам именно с этой проблемой (если она имеет решение) благо это совпадает с моей основной специализацией (оптимизация использования памяти, оптимизация исполнения, повышение эффективности в многопоточном коде). Еще раз хочу подчеркнуть: я ни в коем случае не желаю быть разработчиком SVP, я лишь могу помочь в решении определенной проблемы. Если разработчики не хотят сотрудничать или не считают данную проблему существенной - я откланяюсь.

Chainik

А-я-я-й     Зачем вводить в заблуждение?
Итак исходный файл Мстители (H264, 15831 Kbps, 1080p, контейнер MKV):
1. Выделено 3,110,400 байт 21 раз.

ntdll!RtlAllocateHeap( HANDLE, DWORD, SIZE_T )
msvcrt!malloc() + 0x57 
svpflow_gpu!flowLib_Calculate() + 0x7093f 

2. Выделено 15,523,264 байт 16 раз.

MSVCR90!malloc( size_t )
MSVCR90!operator new( unsigned int ) + 0x1f
...
svpflow1!_AvisynthPluginInit2@4() + 0x4aca
avisynth!avs_delete_script_environment() + 0x3f37
svpflow1!_AvisynthPluginInit2@4() + 0x32c1
avisynth!avs_delete_script_environment() + 0x5e21
avisynth!avs_delete_script_environment() + 0x3f37 

3. Выделено 1,827,376 байт 16 раз.

MSVCR90!malloc( size_t )
MSVCR90!operator new( unsigned int ) + 0x1f 
...
svpflow1!_AvisynthPluginInit2@4() + 0x31b5 
avisynth!avs_delete_script_environment() + 0x5e21 
avisynth!avs_delete_script_environment() + 0x3f37 

Я привел только самые крупные блоки. К сожалению понять что там происходит не могу: нет даже pdb.

Проект jsoncpp.
Файл json_reader.cpp строки 588-589

      bool badTokenType = ( token.type_ == tokenArraySeparator  &&
                            token.type_ == tokenArrayEnd );

Скорее всего нужно заменить на

      bool badTokenType = ( token.type_ == tokenArraySeparator  ||
                            token.type_ == tokenArrayEnd );

Проект svpflow1.
Файл MVSuper.cpp стока 76

    if(yRatioUV==2 && vi.height&1) vi.height++; // even

yRatioUV всегда будет 2

Обратите внимание на возможное переполнение в PlaneOfBlocks::SearchMVs_common файл PlaneOfBlocks.cpp строки 274

    if(mode) lambda = int(min(lambda/pow(plevel,levelsCount-nLevel-1)/(nPel*nPel),INT_MAX/100.0));

PS:  в первом посте я анализировал MVTools2 2.5.11.9 SVP edition, исходники брал с страницы загрузки на wiki. Насколько я вижу mvtools2 используется в SVPMark

Chainik
Никак не могу добраться до профайлеров - пока на работе завал.

• Если говорить о FAQ, то следует добавить следующее: для 32-х битный осей кроме активизации опции LARGEADDRESSAWARE необходимо включить поддержку 3GB. Тут подробная инструкция как ее включить. Есть нюанс с Windows XP: далеко не все драйверы могут корректно работать с этой опцией.

• В программах с большим числом куч от разных менеджеров OOM приходит значительно раньше лимитных 2GB. Для .NET приложения без использования unmanaged resource это значение колеблется в районе 1.6-1.7GB. Для приложений, работающих с DShow графом предел значительно ниже 1.6GB.

Я буду еще тестировать с 3GB на своей системе рекомендацию из FAQ, но вместе с тем прогоню через профайлер использование памяти.
PS: я так понимаю, вы компилируете gcc. Будет интересно сравнить итоговую скорость с IC.

Chainik, спасибо за ответ. Прежде чем написать о проблеме я посмотрел FAQ: предложенный мною временный вариант практически то же самое решение, что и в FAQ. Вопрос в другом: 600MB - это не мало памяти, особенно для x32. Можно ли подумать о фиче по уменьшению использования памяти? Выделение памяти в зависимости от кол-ва потоков (и как я понимаю копирование фреймов для каждого потока) является особенностью оптимизации по производительности или можно использовать иные способы?

Эти результаты я видел, но я рассматривал обновление системы до состояния, когда она бы без проблем тянула все режимы (в том числе и самый тяжелый). Благодаря постам MAG79 и результатам из таблицы (в том числе и вашим) я сделал выбор в пользу Ivy (не смотря на то, что Ivy хуже гонится, чем Sandy: мой Ivy разогнался до 4.6, а на другой системе Sandy гнался до 4.8). Однако окончательного ответа на вопрос какая видяха будет достаточна для всех режимов так и не было. Взял наобум GT 640, т.к.  по цене она была равной GT 450, а по игровой производительности быстрее на 10-40%. Оказалось что для HTPC вполне достаточно Ivy + видяха GT 640 для самых тяжелых режимов SVP + шейдеры.
Кроме того, я замерил температуру процессора при моем разгоне (4.2GHz) и кулере Noctua C12P в момент проигрывания видео. Взял Мстителей (H264, 15831 Kbps, 1080p) и 300 (H264, 9222 kbps, 1080p). В итоге вышло средняя температура 60-64, пик - 67.