Search options (Page 190 of 236)

deanox
You need to pass SVPmark test and show your results here.
Then we can compare it to normal results and say is it hardware problem or not.

If you want you can do it yourself.

nemoW
Никак. Шейдеры в madVR не работают.

tormozit
что будет, если алгоритм оценил кривоту и решил строить кадр, но не успел достроить и уже вывелся следующий?
Такого не бывает. Алгоритм не может не успеть (разговор про аппаратные повышатели плавности в ТВ).

Думаю производительность процессора все таки должна влиять на вероятность успешного расчета за ограниченное время.
Повторю: телек - не компьютер. Какую логику в аппаратный чип заложили, так и будет работать. Там не нужны Гигагерцы и Гигабайты. Там все выполнено в железе и работает намного эффективней центрального процессора персонального компьютера.

совсем избавиться от разброса наверное тяжело?
Готов поспорить, что там нет разброса. Вычисление каждого кадра идет одинаковое очень короткое время.

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

да

sergioleon
Как это понимать?
Любое наложние на видео (статистика, OSD, субтитры) требует ресурсов как процессора, чтобы картинку подготовить, так и видеокарты, чтобы наложить. Видимо, -11 мс - это компенсация. Картинка начинает рисоваться чуть раньше, чтобы на экране отрисовалась вовремя. Даже если она на самом деле опережает звук на 11 мс, то на слух такую рассинхронизацию видео со звуком не услышать.

И опять же повторю свои опасения насчет статистики в свойствах EVR: ей вообще можно доверять?

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 не только для расчетов, но еще и для пост-обработки и для отрисовки требуются дополнительные проверки.