The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"В драйвере R600g реализована поддержка GLSL 1.4, TBO и UBO. ..."
Отправлено Аноним, 15-Янв-13 06:53 
> Железки они до этого уже реверсили. И весьма успешно.

Смотря что понимать под "успешно". Вон у нвидий до сих пор проблемы даже с просто реклокингом. А у амд все-таки переключение частот и управление вольтажом - работает, что ни говори. И фич в нуво явно меньше реализовано. Потому что нвидия их лишний раз тормознула отсутствием спеков. И вместо того чтобы напрограммить фичу им приходится сперва методом проб и ошибок понимать как это вообще работает.

> Декодеров h264 на шейдерах не писал никто.

Просто потому что сам H.264 замороченный и это сложнее чем для mpeg2. Если вы не заметили, кодеки мпег2 для процессоров появились раньше чем мпег4, особенно в инкарнации H.264 (сначала были более простые мпеги 4, по типу divx/xvid).

> Вот декодеры мпегов на шейдерах уже давно есть, с начала двухтысячных.

Насчет двутысячных не в курсе. А H.264 - это тоже мпег. Правда уже 4-й. И с наворотами. Однако общие идеи в основе те же самые. Просто вокруг них реализовано больше наворотов, улучшающих соотношение битрейта к качеству путем усложнения кодирования и декодирования. Кстати аппаратные декодеры имеют привычку поддерживать только субсет фич H.264, зачастую не выше main профайла. По поводу чего попытка проиграть поток вылезающий за эти пределы может нарваться на былинный отказ. Потому что целиком H.264 - навороченный и сложный. И вообше все его фичи упихать в акселерированный железкой декодер - больно уж сложно.

>> Ну понятно, юзер нвидии в треде. Как обычно короче - каждый кулик свое болото.
> Претензии по существу будут?

Так это и есть по существу - от вас много левого бухтежа ни о чем.

>> - вот это да, та еще магия.
> Ды, реверсили же. И работали атишные дрова стабильней, чем проприетарные и ннаписанные по спекам.

Они работали стабильнее просто потому что мир был проще и фич в них и старых GPU было сильно меньше. Между GPU эпохи когда ати реверсили и GPU которые сецчас выпускают - разница как между паровозом Черепановых и TGV. Ясен фиг, первый паровоз пустить по рельсам проще чем скоростной поезд. Вот только он и 500 км/ч не выжмет. А ездить со скоростью 20 км/ч и постоянными доливками воды народу уже не нравится как-то.

> что уж о glsl, который для gp-вычислений не предназначен.

Вообще-то современная видеокарта являет собой большой массив simd-образных числокрушилок. И оному пофигу что именно и по какому поводу его заставят обсчитать. Более того, новая архитектура GCN от амд откровенно оптимизирована на GPGPU вычисления. АМД этого даже и не скрывает вообще. Собственно, основной проблемой VLIW было то что эффективно его программить очень сложно. Т.к. учет взаимозависимостей инструкций на предмет занимаемых ими блоков в случае VLIW - лютейший брейнфак. Что зачастую приводит к низкой эффективности использования VLIW-процессора. GCN в этом плане поудобнее для компилеров и программеров.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру