IvyBridge и SVP (Page 3 of 7)

Не устанавливаются драйвера с офф.сайта:
- 15.26.12.64.2761 (win7 64)
- 15.28.0.64.2770 beta (win8 64)

При запуске инсталлера вылазит окошко, что система не соответствует минимальным требованиям

Не могу понять, что за грабли?

MAG79 в посте от 23-05-2012 16:23:15 в первой табличке недоработка: у cpu ишна 128 бит, поскольку 2 канала памяти, и скорость в зависимости от частоты выходит 20-35 гб/с

если определяющее значение имеет скорость памяти, то ivy-ep, выходящие осенью, дадут нехилый прирост. да и ядер там будет 8, я надеюсь

%username%
Installer Master'ы накосячили
Так и есть. Скачал вместо архива инсталлятор одним файлом и, о чудо, драйвер установился
В базе результатов SVPmark'а теперь есть померянный последний драйвер для Win8. Ошибка пиксельного сдвига осталась, скорость не выросла. Т.е. с точки зрения SVP - эти драйвера все еще плохи.

Булат Зиганшин
cpu ишна 128 бит, поскольку 2 канала памяти
Да. Кстати. Спасибо за поправку. Надо внести правки в таблицу.

если определяющее значение имеет скорость памяти
Не самое определяющее, но ощутимый вклад от скорости памяти имеется. Особенно это видно на медленной (одноканальной) памяти.

MAG79

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

Интересный график.
Уважаю Красных.

Тут еще много таких

Исходя из результатов моего вчерашнего тестирования, для 3770K с посредственным разгоном вполне подходит даже видеокарты класса nVidia GT 640. При этом система обеспечивает уплавнение даже в самом тяжелом варианте на уровне 60 fps.

Эти результаты я видел, но я рассматривал обновление системы до состояния, когда она бы без проблем тянула все режимы (в том числе и самый тяжелый). Благодаря постам MAG79 и результатам из таблицы (в том числе и вашим) я сделал выбор в пользу Ivy (не смотря на то, что Ivy хуже гонится, чем Sandy: мой Ivy разогнался до 4.6, а на другой системе Sandy гнался до 4.8). Однако окончательного ответа на вопрос какая видяха будет достаточна для всех режимов так и не было. Взял наобум GT 640, т.к.  по цене она была равной GT 450, а по игровой производительности быстрее на 10-40%. Оказалось что для HTPC вполне достаточно Ivy + видяха GT 640 для самых тяжелых режимов SVP + шейдеры.
Кроме того, я замерил температуру процессора при моем разгоне (4.2GHz) и кулере Noctua C12P в момент проигрывания видео. Взял Мстителей (H264, 15831 Kbps, 1080p) и 300 (H264, 9222 kbps, 1080p). В итоге вышло средняя температура 60-64, пик - 67.

Смена матери что-нибудь дала ? Зачем было менять её ?

Понятно, значит это непреднамеренная замена. Я был бы удивлён если бы замена была именно преднамеренная

Точно! Ты прав. Пора провести тесты и обновить шапку темы.
Сегодня займусь

Итак, провел вчера серию замеров. Первые результаты и первые выводы.

1. Выбрал заведомо самую простую DirectShow-цепочку для видеоядра HD4000. По сути загрузил его только расчетами SVP.
Декодер: CUVID - работает блок аппаратного декодирования дискретной видеокарты GTX 660 Ti.
Отрисовщик: Overlay Mixer - отрисовка кадра идет из плеера напрямую в видеопамять, а видеокарта HD4000 масштабирует ее с применением билинейной интерполяции.

Заодно и проверка повторяемости результатов теста. Цифры в колонках должны быть одинаковыми, т.к. отличаются они только масштабом. Масштабирование полностью аппаратное без задействования вычислительных блоков HD4000. Видно, что точность определения загрузки процессора 1%, видеоядра HD4000 - 4%. Вполне достаточная точность.
Overlay Mixer показывает самое посредственное качество картинки (резкость хуже других отрисовщиков). Еще в минусы к нему можно записать неверное цветовое пространство (0..255, вместо 16-235) из-за чего черный цвет выглядит серым, а белый цвет недостаточно белым. А также отключает Aero в Windows 7. Для кого-то это тоже минус.

2. На самом тяжелом тестовом ролике разрешения 1080p сравнил между собой четыре пригодных для SVP декодера в составе LAV Filters.

Видно, что CUVID самый честный аппаратный декодер, т.к. использует процессор меньше всех.
QuickSync и copy-back выполняются аппаратно на HD4000 и грузят процессор на 2% больше.
Полностью программное декодирование (None) отнимает у процессора еще 4%.
Видно, что использование аппаратного декодирования на HD4000 не нагружает основные блоки расчета видеоядра, значит используется отдельный блок аппаратного декодирования. Степень загрузки блока декодирования недоступна из GPU-Z.

3. Замерял типичную для Core i5-3570K DirectShow-цепочку. Видеоядро HD4000 выполняет три задачи одновременно:
- аппаратное декодирование QuickSync,
- аппаратное ускорение расчетов SVP,
- аппаратное масштабирование в отрисовщике EVR (сustom presenter) с применением пиксельного шейдера по-умолчанию Bicubic A=-1.00.

Плавное воспроизведение с любым масштабированием получил только на тестовом ролике SD разрешения. На тестовых роликах 720p и 1080p без применения полноэкранного Direct 3D непобедимые подергивания, а временами еще и рассинхрон. Включение галки полноэкранного Direct 3D исправляет ситуацию. Видео становится плавным без подергиваний.

Выводы:
1. Аппаратное декодирование на HD4000 экономит до 4% загрузки процессора.
2. При обычных настройках плеера одновременно декодировать, ускорять повышение плавности и выводить картинку видеоядро HD4000 способно только для SD разрешения. 720p и 1080p требуют настройки плеера.

...продолжение следует.

MAG79

Спасибо
Как обычно исчерпывающе

При обычных настройках плеера одновременно декодировать, ускорять повышение плавности и выводить картинку видеоядро HD4000 способно только для SD разрешения. 720p и 1080p требуют настройки плеера.
которое в XBMC, WMC, mediaPortal'e не сделаешь

Можно еще проверить на рендере VMR9r? его поддерживают две означенных оболочки (кроме WMC)

и еще сделать 4 - тоже что и 3) но декодер софтовый
короче реализовать холодную