Релиз драйверов nVidia 173.14.05

есть ебилды?

> Ждать реализации мультипоточности в ffmpeg скоро не приходится, вот только недавно они начали че-то апдейтить в h264.c и сопутствующих модулях, но пока это ускорения не вызывает, mplayer показывает видео на исходе возможностей одного ядра.

Многопоточность тут мало чего значит. КоркаАВЦ пренебрегает кое-какой работой при декодировании, за счет чего и быстрее. На дум9 это уже обсасывалось.

> Многопоточность тут мало чего значит.

Конкретно на C2D.

> А то что в них можно успешно "гефорсы" 8/9 применять?

Пруфлинк? И понятное дело, не ту новость с лора )))

Странные какие-то дрова. На версии 169.12-r11 в glxgears 19215 фпс, а 173.14.05 показывают только 14 с копейками тыщ фпс. Откатился обратно на 169.12.

>>КоркаАВЦ пренебрегает кое-какой работой при декодировании, за счет чего и быстрее.

Да, читал я все это, вот только жалко что на глаз разницы пока не заметил... Да и разницы в скорости на одном ядре, между двумя декодерами, я пожалуй тоже не заметил(тестировал видео на Sempron 2800+(@2.4Ghz), где фреймдроп проявлялся в одних и тех же местах)

>>Многопоточность тут мало чего значит

Мда... ваш ник вас оправдывает :) По сути многопоточность и есть прирост в скорости до ~90%

>>Конкретно на C2D.

Пруфлинк что ли дайте? Ибо на не кошерных для некоторых Athlon64 X2, многопоточность даёт многое.

>Пруфлинк что ли дайте? Ибо на не кошерных для некоторых Athlon64 X2, многопоточность даёт многое.

При кодировании x264 на двух ядрах - до 180%, на четырёх - до 340%

>>При кодировании x264 на двух ядрах - до 180%, на четырёх - до 340%

Эммм, это тут причем? :) Я с LamerOk'ом про декодинг говорил )

>glxgears

Нашел чем мерять.

Метода тестирования:

Сразу же после загрузки открываем терминал, набираем glxgears и ждем секунд 30. Останавливаем. Делаем сие для разных драйверов. Понятно, что абсолютную производительность не померяешь, но относительную - вполне. Итак, простая пропорция: 14100/19200*100=74% - на 25% примерно разница в производимых фпс. Это как - мало?

>>При кодировании x264 на двух ядрах - до 180%, на четырёх - до 340%

>Эммм, это тут причем? :) Я с LamerOk'ом про декодинг говорил )

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

>>При том, что декодировании тоже значительный прирост получить, если разработчики декодера этим озадачаться.

Тогда надо было сей ответ LamerOk'у адресовать а не мне, я ведь сам в курсе что многопоточный декодинг приносит значительный прирост, посему все жду в ffmpeg реализации данного подхода к декодингу h264...

>Тогда надо было сей ответ LamerOk'у адресовать а не мне, я ведь сам в курсе что многопоточный декодинг приносит значительный прирост

Я с тобой и не спорил. Это был "+1" к твоему заявлению:)

>Это как - мало?

Помнится года четыре назад у меня была 5600XT. И показывала она порядка 7 тысяч. А потом вдруг после очередного релиза стала казать только 2 тысячи. А ftp в третьей кваке тем временем подросли.

Сейчас мои 7600 в SLI кажут пять с чем-то. И свою предшественницу порвут как тузик грелку.

Поэтому что там показывает данная утилита - большая загадка.

Не, а все-таки. Чего надо сделать чтобы 1080 не тормозил? Проц вроде нормальный C2D T7100 1.8ГГц. Не сильно, но иногда начинает проскакивать на динамичных сценах. Файл размером 4.4Гб, о 8 или 16 даже речи не идет :) mplayer кажет через xv. карточка и дрова нвидиевские.

>>Не, а все-таки. Чего надо сделать чтобы 1080 не тормозил?

Попробуй пошаманить с -lavdopts вот так:

mplayer file.avi -vo xv -double -lavdopts fast:skiploopfilter=nonref

Если не помогает, вместо "nonref" подставь "all". Возможно тебе повезёт и никаких артефактов не проявиться :) Если и это не поможет, тогда в случаи если не фанатег - можно присобачить CoreAVC к mplayer'у(ссылку давал выше). Если праведный, можешь разрабам еще и денег заплатить :)

спасибо, попробую.

> Пруфлинк что ли дайте? Ибо на не кошерных для некоторых Athlon64 X2, многопоточность даёт многое.

У C2D общий кэш второго уровня. Я предполагаю, что даже при разделении декодирования на кадры, при входящем потоке в мпег2, процессы будут "выпихивать" друг друга из кэша. Тесты на аналогичные задачи для C2D уже были (погуглите) и показывали прирост (если он был) процентов на 30% от силы. А у некошерных атлонов работа с памятью совсем иначе построена. Вот при кодировании это уже не будет играть такой роли.

> Проц вроде нормальный

Ты сначала -vo скажи и что за видеодрайвер, потом уже можно маркировку процессора перепечатывать. Оно хотя бы xv?

>>Ты сначала -vo скажи и что за видеодрайвер

А вы таки тормозите товарищ :) petrosha под конец указал что выводит через xv и драйвер nvidia, читайте внимательней: "mplayer кажет через xv. карточка и дрова нвидиевские."

>>У C2D общий кэш второго уровня. Я предполагаю, что даже при разделении декодирования на кадры, при входящем потоке в мпег2, процессы будут "выпихивать" друг друга из кэша

Вы вообще знаете зачем процессору кэш, и когда он начинает использоваться процессором? :) Если бы знали, не несли бы пургу ) От теории "выпихивания процессов друг-друга из кеша" я в восторге вообще, буду теперь всем фанатегам Intel'а доказывать насколько их процессоры плохи, и давать пруфлинк именно на ваш каммент 8)

подождите, разве в мплеере нет такого:

-lavdopts threads=2(4) ?

> А вы таки тормозите товарищ

Запросто ))

> Вы вообще знаете зачем процессору кэш, и когда он начинает использоваться процессором?

Ну расскажи, сделай милость. Сгодиться и линк. ))

>>подождите, разве в мплеере нет такого:

>>-lavdopts threads=2(4) ?

если вы читали man, то там четко указано насчет того что это только для mpeg/mpeg2. Для H264 "настоящей"(хз как назвать, ибо в одной из тем кидали линк на то, где говориться про slice-режим, иль как-то так, но толку от него мало) мультипоточности нет.

>>2LamerOk

http://ru.wikipedia.org/wiki/%D0%9A%D1%8D%D1%88

просветительской деятельностью я не занимаюсь, поэтому просветляйтесь сами :)

ман читал, там действительно говорится только об мпег2

>где говориться про slice-режим

писали, что данная опция работает для контента, пожатого в slice

>>писали, что данная опция работает для контента, пожатого в slice

вот в этом и загвоздка - большинство контента в него и не пожато(да и я даже сам не в курсе какая опция в кодере x264 отвечает за это, весь ман по mencoder'у перечитал - ничего не нашол, или чего-то пропустил)

> просветительской деятельностью я не занимаюсь

Тогда берите на себя труд аргументировать позицию )))

> не в курсе какая опция в кодере x264 отвечает за это

в том весь и подкол, что x264 вообще не умеет так кодировать (вроде обсуждалось в новости про mplayer)

>>Тогда берите на себя труд аргументировать позицию )))

аргументируют сложные моменты и спорные моменты, а не постулаты которые известны любому, кто считает ся хоть немного разбирающимся в комп. технологиях :)

>>в том весь и подкол, что x264 вообще не умеет так кодировать (вроде обсуждалось в новости про mplayer)

я разочарован :(

Из документации к x264:

Old threading method: slice-based

New threading method: frame-based

Penalties for slice-based threading:

Each slice adds some bitrate (or equivalently reduces quality), for a variety of reasons: the slice header costs some bits, In CBR mode, we have to allocate bits between slices before encoding them, which may lead to uneven quality. Some parts of the encoder are serial, so it doesn't scale well with lots of cpus.

Т.о. от slice-based метода в x264 отказались (уже довольно давно)

>Из документации к x264:

В общем, загляните в файл threads.txt

>Не сильно, но иногда начинает проскакивать на динамичных сценах.

Точно не IO тормозит? А если в mplayer кэш побольше поставить?

>>Из документации к x264: > > В общем, загляните в файл threads.txt

Действительно... теперь я разочарован, от разрабов mplayer поддержки frame-based я похоже не дождусь. Или использования CUDA для разгрузки процессора.

>Ты сначала -vo скажи и что за видеодрайвер, потом уже можно маркировку процессора перепечатывать

А ты сначала проснись, а потом уже на лор лезь:)

>Точно не IO тормозит?

Ну не знаю, диск конечно ноутбучный, но 40Мб/сек он по hdparm держит.

>А если в mplayer кэш побольше поставить?

>Точно не IO тормозит?

Ну не знаю, диск конечно ноутбучный, но 40Мб/сек он по hdparm держит.

>А если в mplayer кэш побольше поставить?

Сколько? 4Мб не помогает.

>Сколько? 4Мб не помогает.

Ну, скажем, 64М

>Ну не знаю, диск конечно ноутбучный, но 40Мб/сек он по hdparm держит.

Снять бы показатели загрузки CPU в моменты этих "затыков"...

>Снять бы показатели загрузки CPU в моменты этих "затыков"...

я еще грешу, что это скалирование частоты не совсем корректно отрабатывается...

Драйвер NVidia 173.14.05 доступен во FreeBSD в виде порта ports/x11/nvidia-driver.
Дистфайл NVIDIA-FreeBSD-x86-173.14.05.tar.gz ~15,1МБ