Search options (Page 189 of 234)

komandors
Примерно такой же, как у x264 при переходе с 32 бит на 64 бита. Но главное преимущество 64 бит не скорость, а возможность использовать больше 2 ГБ оперативной памяти.

river
Yeah.. It is simple. Only avisynth 2.5.8 MT SVP edition has memory optimizations for SVP use.

Sorry, I didn't notice it before.

airport
I increased refresh rate from 60Hz to 80Hz
It is non standard. Does your hardware supports this?
What is your configuration (CPU, GPU, monitor)?

disabled Vsync on GPU and MPC-HC
Are you sure it is good? I don't think so.

And one more question.
Your tearing with Ctrl-T (Ctrl-Win-T) looks like this (tearing vertical line of tearing test)?

If yes then you can find option Vertical sync in driver of your video adapter and turn it on (Force on).

airport
Oh! Yes. I didn't notice double ffdShow at the first screen (Thanks to Chainik). It is wrong. You need to leave one ffdShow.
Additional info is text-file from SVP menu - Information - Additional information.
Upload any fragment with tearing trouble. Source video without any transcoding.

Why you use decrease frame size to 75% of original size for 640x480 video?

Из шести под-тестов три показали полезность встроенной графики, а оставшиеся три показали как будто бы полную (и не очень) бесполезность.

Начну с под-теста simple1. Это стандартное удвоение кадров, в котором эффективнее всего работает построение кадров. Для требуемых 48 к/сек необходимо рассчитать для 24 исходных кадров ровно 24 промежуточных.

Но почему же дискретная графика дает прирост результатов, а встроенная графика не дает? Ответ кроется в цифрах. Если взглянуть на результаты расчета только процессором, то видно, что они лежат в районе 126-133 к/сек. Это в 2,5 раза больше требуемой скорости 48 к/сек. При реальном проигрывании видео с плавностью скорость будет в 2,5 раза ниже, соответственно процессор будет загружен на 100/2,5 = 40%. GPU-ускорение должно еще освободить процессор, что в реальности даст меньшую частоту его работы, меньший нагрев, и как результат, меньший шум от системы охлаждения. Правда этот вывод касается горячих процессоров (Core i7 920, например), а IvyBribge - процессор достаточно холодный.
Но я не ответил на вопрос, почему встроенная графика не дала прироста? Если посмотреть показатель расчета кадров (GPU-calc), то можно увидеть там цифру 130. Это означает, что она способна рассчитывать 130 вакуумо-кадров на среднестатистических настройках плавности. Кроме этого имеются издержки на передачу данных процессор > видеокарта > процессор, что создает ограничение для применения видеокарты. В данном случае ограничение находится в районе 150 к/сек.

Под-тест fastest. Это еще более легкие настройки повышения плавности.

Подтверждается предположение об ограничении скорости встроенного графического ядра в районе 150 К/сек. Теперь даже от использования дискретной видеокарты не наблюдается  прироста. Вся мощь карты (GPU-calc = 935 вакуумо-кадров) съедаются издержками передачи данных. Но опять же причина вполне объяснима: завышенная в 6 раз скорость кадров. В реальных задачах при проигрывании видео таких частот кадров просто не бывает. Да и при обработке и перекодировании скорости куда скромней. А на низких скоростях GPU-ускорение покажет себя уже в более выгодном свете.

Под-тест simple2. Это соответствует легким настройкам при утроении кадров. Анализ векторов движения процессором выполняется с такими же затратами, как в под-тесте simple1, но при этом построение требует вдвое больших затрат от применяемого ускорителя.

В сравнении с графиком simple1 процессор показал увеличение результата со 131 до 175 к/сек, что говорит о том, что поиск векторов движения с пересчетом на один исходный кадр - это задача более трудоемкая, чем построить один новый кадр.

По грубым подсчетам для этого алгоритма у меня вышло, что построить 1 кадр для процессора в 7 раз легче, чем найти вектора. Странно. Откуда тогда приросты от GPU-ускорения 70%, если освобождается только 2/7 = 29%?
Второй вопрос: почему ограничение частоты кадров для iGPU снизилось со 150 до 120 к/сек? Затраты на расчет одного нового кадра идентичны под-тесту simple1, процессор трудится в 2 раза меньше. Парадокс.

Дискретная видеокарта снова показала наличие ограничения для нее в районе 250-300 к/сек. Не так уже далеко ушла от встроенной графики: всего в два раза.
Но опять же повторю, Снижение результатов при использовании встроенной видеокарты наблюдается только из-за высокой скорости подачи исходных кадров. На нормальной скорости встроенное графическое ядро успешно справляется с построением даже на более тяжелых настройках.

Общие выводы
- Встроенное графическое ядро Intel HD Graphics 4000 справляется с повышением плавности вплоть до настроек под-теста high.  Для highest нехватило производтельности процессора, чтобы проверить;
- Несмотря на разницу производительности по синтетическим тестам в 7 раз, разница максимально доступной скорости построения кадров отличается всего в 2 раза и находится в районе 150 к/сек для Intel HD Graphics 4000 и 300 к/сек для GTX 260;
- Работа оперативной памяти на высокой частоте (1866, 2133 и 2400 МГц) может дать прирост скорости на процессоре на 4-11%%, на iGPU - на 6-9%, на dGPU - на 7-23%;
- Применение встроенного графического ядра для ускорения расчетов дает ускорение максимум на 71%, а применение дискретной видеокарты - на 97%.

Выводы касаются результатов теста SVPmark, показывающего OpenCL-расчетные возможности. Для оценки возможностей использования встроенного графического ядра Ivy Bridge не только для расчетов, но еще и для пост-обработки и для отрисовки требуются дополнительные проверки.

Xant1k
в MPC
Хорошо. Теперь с используемым плеером ясно.

Дрожание 0 из-за ReClock'а - это тоже хорошо. Но раз есть окно статистики, значит полноэкранный D3D режим не использовался? Без него выпавшие кадры - не редкость даже на самых производительных системах. Другое дело, что из полноэкранного режима такую статистику не посмотришь и не скажешь чему стала равна цифра. Нулю или также набегает до нескольких сотен за фильм.

Разве что в мультимониторной системе

Предлагается:
1. Использовать отрисовшики, наиболее стойкие к выпавшим кадрам. Это madVR Exclusive и EVR Custom с полноэкранным D3D.
2. Статистику выпавших кадров смотреть в madVR по Ctrl-J, я считаю его показания ниболее честными.

airport
Thank you. All is good there.
1. Maybe you can upload a little sample?
2. And show additional info from SVP menu please. There should be the answer.

Xant1k
EVR CP
Так отрисвщик в PotPlayer'e называется, и представляет собой сильно перекроенный EVR. В MPC-HC более правильный отрисовщик и называется он EVR Custom Pres.Xant1k

многова-то дропов
Разве этой статистике можно доверять? Я не думаю.
Я вообще вижу что эта статистика не предназначена для оценки плавности. Т.к. нужно две цифры: пропущено кадров / повторено кадров. Кроме этого не хватает точной частоты обновления экрана.
И на последок, я не понимаю, как может быть дрожание кадров = 0 при наличии дропов?
Кривая статистика?!

airport
Can you show properties of these "some of your movies"?

Вчера предварительно проверил разгонный потенциал HD Graphics 4000.
Графическое ядро работает на частоте 350 (в простое), 650 (в нагрузке), 1150 (в максимальной нагрузке). Судя по показаниям GPU-Z, ядро достаточно быстро переключается между частотами.
Так вот в BIOS имеется возможность задать максимальную частоту, на которую будет переключаться видеокарта. Частота задается с шагом 50 МГц. Без поднятия напряжения на графическом ядре у меня оно заработало и прошло тест SVPmark на частоте 1500 МГц. Разгон составил (1500-1150)/1225 = 30%. При этом показатель GPU-calc вырос с 130 до 162, что составило 25%. Это показатель синтетического теста. Влияние на результат реальных тестов проверю позже.