You are not logged in. Please login or register.
SmoothVideo Project → Posts by Chainik
docent27
С каждым днем растет популярность свободных операционных систем
На этот счет есть разные мнения 
Многие, кто ими пользуеться, назад к винде как правило не хотят возвращаться
Я хочу 
работал с родными плеерами Linux
Я не вижу способа, как нативный плеер может работать с виндовым декодером. То есть один вижу, о чем писал на ixbt, но (как и все в линухе ) через задний этот самый.
nivp222
Сурово!
Но это уже совсем куда-то за край необходимости, только если BD3D уплавнять
Thank you for opening the English forum
there is no wiki in English yet
We're working on it, but we really need someone with native English
than just following instructions on dedicated threads that are out there
I hope that SVP is far better and more powerful than just another mvtools script.
And this is only a beginning 
На самом деле, вот табличка по бета-тестерам:
https://spreadsheets.google.com/ccc?key … y=CN2_rIsD
ALM52
Может я плохой пример выбрал.
С самым тяжелым построением (23-й шейдер) и достаточно простым поиском. В этой ситуации видяха снимает больше половины нагрузки, наверное ближе к 2/3.
От чего зависит этот показатель?
От всего. От платформы в целом. От частот шин, от имен чипсетов, от версии PCI-E, от погоды на Марсе.
Но конечно
- GPU: system -> GPU transfer: 137
- GPU: GPU -> system transfer: 97это перебор. Антирекорд 
Пробовал,разница в нагрузке настолько мизерна (на любом видео),что смысла в ней не вижу.
Если мало скорости, то можно:
1. "Изменение частоты кадров" - поставить "24->60 1m" - будет чуть менее плавно, зато меньше артефактов и быстрее
2. Если все еще мало, то поставить "размер расчетных кадров". Очень резко влияет на скорость, но только при 1m-режиме (см. п.1 ). Несколько замыливает промежуточные кадры, но исходные кадры не трогает.
То что вы делаете - уменьшаете все кадры вообще. Тоже способ, но надо понимать что при этом "мылится" всё.
lionessb
1. нет никакого конфликта
2. поставить "подавление площадных артефактов":"отсутствует"
3. подавления контурных нет при 13-м шейдере
FullHD 16x9 проц чють-чють не тянет
Даже при "простом" "SVP-шейдере"? Да и всегда можно "радиус поиска" в ноль загнать. Ну то есть, в один
приходится смотреть Splash-ем
дык тогда уравняйте конкурсантов - поставьте в SVP "уменьшение расчетных кадров" до 720p, как это делает сплэш
Надо как-то начать связывать это с реальностью.
Вот например, берем средние настройки, без экстремизма, но вполне приличные:
FullHD (1920*1040)
- До частоты экрана
- Продвинутое, 23-Усложненный
- Блоки 16*16, без перекрытия
- Поиск: 3 пикселя, шестиугольниками
При этом в режиме CPU загрузка моего процессора ~90%. Ну, то есть, впритык для беспроблемного просмотра.
Так же я знаю, что имею 1592 SVP-CPU попугаев.
Вывод: для приличного просмотра FullHD надо иметь >1500 SVP-MARK-ов.
YlangYlang
А если все то же самое, но без madVR?
MadVR сам по себе не кисло видяху жрет. Особенно + CoreAVC@CUDA. Да +SVP.
Попробуйте по отдельности.
Не надо усложнять
Факт в том, что одновременно madVR + coreavc + svp совершенно не обязаны работать. Обо что надо в факе написать, кстати...
У меня, например, на AMD 5670, и декодер+svp - уже под вопросом.
Что это доказывает???
То, что все операции с видяхой стоят в одной общей очереди (у Фермы, говорят, несколько очередей). И coreavc, и рендер, и SVP, и всякие шейдеры в рендере. Поэтому они вполне могут толкаться и мешать друг другу, особенно на слабых картах.
И если задержка на лишние миллисекунды в декодере - незаметна, то такая задержка в рендере сразу даст рывки.
Так какой рендерер и H.264 декодер рекомендуются для WinXP?
Начать с перехода с madVR на EVR.
Может собака порылась в распоследних версиях ffdshow и прочего?
Соответствие алгоритмов: http://www.svp-team.com/wiki/Сравнение_SVP_2.0_и_3.0
для каждого вопроса (на который негде найти ответ) создавать тему
Терпение надо воспитывать
"Качественный", mask=0 -> SVP-шейдер "21. Оригинальный"
"Качественный", mask=1 -> нету
"Качественный", mask=2 -> SVP-шейдер "23. Усложненный"
Предыдущие чемпионы:
Разогнанный i7-860 до 22*153=3366Mhz:
- CPU: compose (single-threaded): 464
- CPU: compose (multi-threaded): 2018
- CPU: search (single-threaded): 372
- CPU: search (multi-threaded): 1550
- GPU: system -> GPU transfer: 1039
- GPU: GPU -> system transfer: 1272
- GPU: calculation: 521
- GPU: total score: 3235Total SVP-MARKS: 3100
- SVP-CPU: 1753
- SVP-GPU: 3100
и
AMD X6 @3400
- CPU: compose (single-threaded): 313
- CPU: compose (multi-threaded): 1696
- CPU: search (single-threaded): 258
- CPU: search (multi-threaded): 1501
- GPU: system -> GPU transfer: 369
- GPU: GPU -> system transfer: 871
- GPU: calculation: 339
- GPU: total score: 1929Total SVP-MARKS: 3002
- SVP-CPU: 1592
- SVP-GPU: 3002
чтото не пойму что и КАК этот тест считает
Это НЕ 3DMark, баллы видяхи влияют на итоговый результат только если видяха дохлая.
Если она достаточная (а это почти всегда так), то скорость работы SVP ограничивается скоростью поиска векторов движения процессором. Т.е. итоговый балл "SVP-GPU" ограничен баллом за "search (multi-threaded)".
А вообще, поздравляю, у вас самый длинный! Это новый чемпион
Подтверждаю - точность прогнозирования совсем не бесплатна.
Ладно, поправлюсь:
1. совсем бесплатна по памяти (очень не-бесплатно в CPU-режиме)
2. полу-пиксель нагружает мало, процентов 10-15 от силы (в CPU-режиме - гораздо больше)
3. четверть-пиксель - пока что побольше...
16x16 то загрузка 74% если поставить до полупиксела то нагрузка возрастает до 87-90%, дальше - хуже. Если снять галку с GPU то на любых вышеперечисленных настройках загрузка 97-100%
Вот это уже похоже на правду для c2q & fullHD
Давай эксперименту для 16*16 выставим.
В принципе, в нормальной ситуации при использовании GPU это снижает нагрузку почти вдвое.
----
Короче, выводы:
- Совершенно не жизненные настройки (удвоение, построение блоками, 16*8 на FullHD), которые в принципе не могут показать разницы между CPU и GPU.
- "Жизненные" настройки - нормальное по-пиксельное построение (13-й или 23-й SVP-шейдер) и "до частоты экрана" (при использовании GPU скорость не упадет) + блоки 16*16, что даст ускорение вдвое. Лучше вместо этого перекрытие блоков включить. И вот тут уже, при отключении галки "OpenCL" будет сильная разница.
- Надо писать мануал
не знаю хорошо это или плохо...
Вроде все хорошо
Стало подергивать иногда, сразу отставание звука и 95-100% нагрузка
Вот. а теперь сними галку "OpenCL" и восхитись ускорением
На самом деле, даже не знаю, есть ли тут какая-то проблема. Может и нет?
И еще - из соседней ветки SVPMark запусти, самое показательное будет.
Просто если у 25-и человек все работает, а у одного - нет, то проблема явно у этого одного
А какой алгоритм мне выбрать
Не верная постановка вопроса.
Все алгоритмы на GPU работают с одинаковой скоростью. С выключенным режимом OpenCL они отличаются по скорости раза в 4.
У вас скорость ограничивает что-то другое. Например, декодер.
Дабы закрыть вопрос, поставь "повышение плавности" "Комплексное" (или как оно там зовется), и "SVP-шейдер" с номером 23. Как изменится загрузка / индекс SVP?
На сколько грузит проц это конкретное видео с выключенным СВП?
1. На сколько грузит проц это конкретное видео с выключенным СВП?
2. Блоки 16*8 - толку мало, 16*16 достаточно всегда, лучше радиус поиска увеличивать.
3. Зачем "уменьшение размера кадра" стоит? Это не снимает нагрузку, а увеличивает
Но, спасибо, на вашем примере очень рельефно проступает, чего надо в первую очередь в ФАКе описать Завтра займемся.
SmoothVideo Project → Posts by Chainik
Powered by PunBB, supported by Informer Technologies, Inc.