Компания NVIDIA представила (https://devtalk.nvidia.com/default/topic/804473/b/t/post/442...) новый выпуск проприетарного драйвера NVIDIA 346.35. Это первый стабильный релиз новой LTS-ветки с длительным сроком поддержки. Драйвер доступен (http://www.nvidia.com/Download/driverResults.aspx/81252/en-us) для Linux (ARM, x86, x86_64), FreeBSD (x86, x86_64) и Solaris (x86_64).Основные особенности (http://www.opennet.me/opennews/art.shtml?num=41060) ветки NVIDIA 346.x:
- Реализация расширений EGL_EXT_device_base, EGL_EXT_platform_device, EGL_EXT_output_base, которые приблизили драйвер к возможности использования с Wayland и Mir. В драйвере теперь доступны все необходимые для Wayland и Mir расширения EGL, но до полноценной поддержки данных систем остаётся реализовать KMS API и KMS ioctl, что планируется сделать через добавление в будущие выпуски модуля для управления видеорежимами на уровне ядра.
- Поддержка версий ядра Linux 3.17 и 3.18.
- Декодирование видеопотоков VP8 посредством NVCUVID API на GPU, поддерживающих аппаратное декодирование VP8 (семейство Maxwell).- Управление напряжением питания на GPU семейства GeForce GTX 400 и более новых.
- NVENC: аппаратное кодирование h264 на GPU семейств Kepler и Maxwell.
- В расширении RENDER реализовано ускорение для форматов r8g8b8a8, r8g8b8x8, b8g8r8a8 и b8g8r8x8.
- Возможность использования утилитой nvidia-settings библиотек GTK2 и GTK3 на выбор.
- Ускорение установки драйвера, благодаря многопоточной сборке модуля ядра.
- Для xorg-server 1.16 и более новых версиий, а также для ядер Linux 3.9+ с доступной опцией CONFIG_DRM установщик драйвера сам добавляет файл с необходимыми записями в каталог xorg.conf.d для автоматического использования драйвера nvidia.
- Установщик драйвера теперь получает информацию о путях необходимых библиотек из кэша ldconfig вместо использования жёстко заданных путей, специфичных для дистрибутивов.
- Радикально ускорена отрисовка объектов OpenGL-фреймбуфера, также устранено ограничение на количество таких объектов.
- Драйвер OpenGL теперь использует $XDG_CACHE_HOME вместо $HOME для хранения кэша шейдеров GL.
По сравнению с прошлой бета-версийей в NVIDIA 346.35 добавлена поддержка GPU GeForce 800A и GeForce 800M, реализовано игнорирование кадров для неподдерживаемых драйвером режимов HDMI 3D с межстрочной развёрткой, до версии 0.9 обновлена поставляемая в комплекте библиотека libvdpau, в которой добавлено (http://lists.freedesktop.org/archives/vdpau/2014-December/00...) несколько новых профилей декодирования H264, отключена по умолчанию опция EnableACPIHotkeys.
URL: https://devtalk.nvidia.com/default/topic/804473/b/t/post/442...
Новость: http://www.opennet.me/opennews/art.shtml?num=41476
А ведь говорили, что разрабы блобов не станут поддерживать всякие Вэйленды и Миры. Так что новость хорошая!
Говорили что будут. http://opennet.ru/opennews/art.shtml?num=40800
Я не про Нвидию.
Так блоб только один -- nVidia. У амд такой блоб, что лучше использовать опенсурсный.
Так ведь кто говорил-то: сами разрабы, или "аналитики"? ;)
Аналитики :)
Несколько лет назад это говорили сами разрабы, но потом планы изменились, и да, очевидно что решения принимают не разрабы, а менеджеры.
http://www.nvnews.net/vbulletin/showthread.php?s=e3bf9f78751...
> А ведь говорили, что разрабы блобов не станут поддерживать всякие Вэйленды и Миры.А вы больше слушайте местных форумных аналитиков. А тем временем народ причастный к разработке поскрипел мозгами да и пришли к EGL как некоему стандартному и-фейсу для стыковки чего попало с чем попало.
>А вы больше слушайте местных форумных аналитиков.Ты тролль-засланец и пытаешься оболгать пользователей Linux приписывая им то чего они не делали, но выше привели ссылку на слова разработчика NVidia: We have no plans to support Wayland. Так что NVidia официально заявляла это, но времена изменились и планы у них тоже изменились.
EGL - это не о Wayland. Это о поддержке действительно кроссплатформенной вариации OpenGL - в частности, единственной поддерживаемой на мобилах и планшетах.
А ты прочитай на что отвечал.
Я прекрасно знаю, на что я отвечал. Я поддерживаю вот это: "А вы больше слушайте местных форумных аналитиков. А тем временем народ причастный к разработке поскрипел мозгами да и пришли к EGL как некоему стандартному и-фейсу для стыковки чего попало с чем попало."Именно так и есть - общее производное, работающее как на десктопе, так и на мобилах, на что можно оринатироваться код хоть в игре, хоть в браузере, хоть где. Ну а так как и вейланд с миром на EGL с самого начала ориентировались - выхдоит, что и им это сгодится.
Для тех, кто не понял: поддержали не мир с вейландом (было бы что поддерживать - распространённости у них ноль целых ноль десятых). Поддержкали стандарт де-факто, которым пользуются и мир с вейландом.
Поддержка EGL добавлена в 2012 году в драйвере версии 310. Попроавьте заголовок.
Кстати о 346.xx. Аппаратный энкодинг уже работает. Мой ноутбук с 650M выдаёт 150 FPS при кодировании FullHD-файла с помощью ffmpeg + libnvenc. Причём не важно какая сила кодирования, ultrafast или veryslow - 150 FPS. На проце - только 18 FPS.
Поделить подробностями, как ты используешь аппаратный энкодинг.
> Причём не важно какая сила кодирования, ultrafast или veryslow - 150 FPSвид - банан, вкус - банан, всё банан. Походу, аппаратный кодировщик особо не смотрит на эти профили.
>> Причём не важно какая сила кодирования, ultrafast или veryslow - 150 FPS
> вид - банан, вкус - банан, всё банан. Походу, аппаратный кодировщик особо
> не смотрит на эти профили.нет не смотрит
у него свои профили, точнее пресеты:
-preset hp||hq||bd||llhq||что-то ещё
> у него свои профили, точнее пресеты:
> -preset hp||hq||bd||llhq||что-то ещёТо что он всегда все делает за одно время - наводит на подозрения что вас где-то на...ли. По логике вещей, чем выше качество при меньшем битрейте, тем больше усилий кодировщик убабахал на, допустим, поиск движения и попытки закодировать это как именно перемещение относительно прошлого кадра. Чем глубже поиск тем лучше соотношение битрейт-качество, но и медленнее сжатие. Потому что грубо поискать и забить если с наскока не получилось - быстрее.
А когда всегда 150FPS - это намекает на то что логика всегда одна и та же и на 150 FPS - это похоже на оптимизацию для реалтайм кодирования. Которая врядли обрадует в плане соотношения битрейта и качества. В том плане что качественный софтварный кодек обеспечит куда более скромный битрейт при равном качестве или более хорошее качество при таком же битрейте. Особенно актуально для двухпроходного кодирования, когда кодировщик заранее знает насколько сложно кодировать опосля, поэтому может раскинуть доступный бандвиз наиболее оптимально. Поэтому обычно то что не реалтаймное - кодируют в 2 прохода. Аппаратному кодировщику все это ясен пень не светит.
ну не знаю как у вас оно работает.
у меня взависимомти от пресета скорость энкодинга меняется.
ессно тоже меняется взависмоти от разрешения/битрэйта оригинала.
г-но ролики в мерзком качестве - я видел до 300FPS
fhd - падало до 60 fps
вот специально проверил
оригинал fhd 1080p:
-preset hp - 140fps
-preset hq - 60fps
> По логике вещей,Есть такая фигня, из простого, - определитель матрицы, ну так вот,
шоп его пащетать, всегда нужно выполнить одинаковое кол-во действий.Та же фигня с регистрами, операциями с битовыми масками, страничной памятью,....
1111111111101 ^ 1111111110
и
01 ^ 10монописуально по времени для любого проца.
---Жопа может начатся если они начнут считать не нулевые биты.
---
2. Например видюхи Gigabyte и Asus шустрее своих нищебродских братьев типа XFX, Zotac, MSI,...3. Остальная система тормозит. Ядро не тюнинговано, кеды/гной3 с композитом запущен.
таки да работает, причём качество вполне сносное.для тех кто в танке (посты ниже):
нужен свежий ffmpeg (я собираю из гита) собранный с --enable-nvenc,
чтоб собралось нужны заголовки из _ВАНТУЗНОГО_ nvenc sdk 4.0 (с 5.0 не собирается) и помойму заголовки CUDA (не факт, точно не помню)юзать легко:
ffmpeg -i input.file -c:v nvenc -preset hq -аудио_опции output.file
Про планы сделать поддержку Optimus для Linux как всегда нет ни слова, так что NVidia - fuck you, как сказал один известный человек из мира Linux.Традиционно поставил новости минус, пока не сделают Optimus для Linux минусую и пишу негативные отзывы об NVidia на всех интернет ресурсах.
Компания NVidia плюёт на меня, а я плюю на NVidia, да-да именно так, а нвидиевцы что думали что можно плюнуть в лицо линуксойдам, а они утрутся и молча пройдут мимо? Как бы не так, твари нвидиевские, я вам негативными отзывами в интернете с лихвой отплачу, с таким менеджментом как сейчас у компании NVidia нет будущего.
мб я что-то незнаю хм http://www.opennet.me/opennews/art.shtml?num=36848
А ты сам новость то читал? да и к тому же уже два года прошло, а подвижек в области Optimus как не было так нет.
А как насчёт подвижек таких проектов как Nvidia Prime и особенно интересует bumblebee. Bumblebee адаптировать под mir то будут?
Так суть в том, что его _не_нужно_ адаптировать, он с XMir нормально работает
а разве вы не в мире opensource ? если вам надо - давно бы уже накодили. Исходники есть :-)ломает ?
Подскажите. У меня mesa-10.4.0 vdpau-0.9 nouveau-1.0.11 и vdpauinfo выдаёт
# vdpauinfo
display: :0 screen: 0
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1
При том, что на этой системе блоб вообще никогда не стоял.
Симлиинк с libvdpau_nouveau.so на сабж тоже не помогает.
Соответственно mpv тоже не может выводить через vdpau.
Но если перед вызовом установить переменную среды VDPAU_DRIVER=nouveau.
VDPAU_DRIVER=nouveau vdpauinfo и VDPAU_DRIVER=nouveau mpv то определяет декодеры и распознаёт как нужно.
Я прописал в /etc/bash.bashrc, что бы не добавлять ко всем точкам запуска всего, что может использовать vdpau и оно, в принципе, работает.export VDPAU_DRIVER=nouveau
Но раньше, на более старых версиях, мне этого делать не приходилось.
Это глюк vdpau, что он не правильно распознаёт видео драйвер, или задавать для него переменную среды VDPAU_DRIVER=nouveau теперь обязательно?
Хорошо. Пойду обновлюсь и заодно ведро свежее накачу.А вот АМД по прежнему вперде, к сожалению.
Хочешь сравнить радеон с нуво?
Кстати, как там с аппаратным кодированием у радеона? Поддержку VCE 1.0 добавить еще планируют или уже забили? Научился ли популярный софт использовать аппаратное кодирование со свободным драйвером?
> Научился ли популярный софт использовать аппаратное кодирование со свободным драйвером?как можно об этом узнать, если процессорные затраты на софтварное декодирование настолько малы? :-)
и да, как там у Nvidia обстоят дела с поддержкой аппаратного декодирования новомодных видеокодеков?
процессорные затраты малы говорите? я именно про кодирование говорю (encoding), c декодированием (decoding) все более-менее хорошо.
Как там с 3D у нуво?
> Как там с 3D у нуво?Да нормально относительно. Зато с реклокингом - не очень. А без реклока когда GPU шпарит на частоте в 20% от номинала - ну и результато будет с понятно какой скоростью.
> кодирование со свободным драйвером?Учат, как ни странно. При том все по уму делают. Взяли апи OpenMAX, уже некоторое время использущееся в разных девайсах с линем и процом умеющим аппаратное кодирование.
Хочешь сравнить Catalist с Nvidia?
>Радикально ускорена отрисовка объектов OpenGL-фреймбуфера, также устранено ограничение на количество таких объектов.На практике кто-нибудь разницу заметил? Хоть в чём-нибудь?
"Установщик драйвера теперь получает информацию о путях необходимых библиотек из кэша ldconfig вместо использования жёстко заданных путей, специфичных для дистрибутивов. "Теперь нужно дождаться подобного в дровах >340.65 <342 or 341 точно не помню ;)
А то гентушникам не в радость эта бага ;)
> А то гентушникам не в радость эта бага ;)"Мыши кололись, плакали, но продолжали жpaть кактус".
Зачетная темка, мне нравиться.
Кстати всё хотел спросить - почему когда я нажимаю плюсик - он типа нажимается, но после обновления страницы не ставится. Это дискредитация по дистрибутивному признаку )))Нвидии вообще надо из видеокарт сложить перед входом слово OPTIMUS FOR LINUX.
И нагадить на коврик у заднего выхода, чтобы убегающий директор вляпался.
> типа нажимается, но после обновления страницы не ставится.
> Это дискредитация по дистрибутивному признаку )))Нет, по половой ориентации.
Плюсы-минусы считаются, и появляются, _потом, чтобы не нагружать сервер.
Заявление о поддержке версий ядра Linux 3.17 и 3.18 означает устранение проблемы, связанной с необходимостью использовать переменную ядра get_num_physpages(), о которой говорилось ранее http://www.opennet.me/opennews/art.shtml?num=38316?