Дрова сырые, не горят

Вот значит сменил видяху, на 2080 Ti. Быстрая, где-то раза в два быстрее чем 1080 (по Furmark), явный для моих целей оверкилл (FRV, без всяких оптимизаций под очень много ядер - кажет 40Mpix/Sony uncompressed со скоростью 24fps, при этом видяха не удосуживается даже частоту поднять хотя бы до базовой, не говоря о boost).

Брал из идеи попрограммировать Tensor cores когда дойдут руки, ну прям очень интересно.

Но я не об этом.

Чудовищные, чудовищно сырые дрова драйвера. В двухмониторной конфигурации стандартно частота в idle не падает ниже 1065Mhz и ~60 ватт потребления. Проблема известная, частота минимальная у всех разная, но большая, есть гипотеза что она зависит от частоты обновления мониторов (на 120/144 Hz у народа бывает и больше мегагерцев в idle).

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

Решение - частичное - тоже известно, NVidia Inspector, там есть аж специальный режим для Multimonitor Power saver. У меня сбивает частоту до 645, потребление до 20 с небольшим ватт.

В одномониторном режиме такого нет, без всякого инспектора - частота падает до 300-330Mhz сама.

Ну я даже смирился уже.

Но вот оставил компьютер на ночь в режиме sleep. Утром - разбудил, а у меня мониторинг видяхи (пока) выведен. Ну и проснулась она и у нее все хорошо - 300Mhz в idle. Второй монитор - вот он.

То ли выспаться ей было надо, то ли еще чего.

Уверен на 100% - перезагружусь и опять будет 645. Вот пошел пробовать....

UPD: перезагрузился, конечно 645. Дал поспать минутку, разбудил, после просыпания - 645, но пока я это пишу - упало до 300. Правда на потребление переход с 645 на 300 влияет мало, пара ватт.

P.S. Ну и в firefox  - flicker при прокрутке на оба монитора. Нужно hw acceleration выключать.

Comments

О, спасибо — теперь я буду говорить что не покупаю ее из за сырых дров.

Надо сказать что без дров - там тоже не грустно

Я когда тестовую винду ставил, в некоторый момент оставил надолго (может час) просто в BIOS, отвлекся на что-то.
Так она разогрелась, на ощупь, градусов до 70 просто сама по себе (так то, с драйверами и/или в обычном режиме - начиная с 50C включаются вентиляторы, а в BIOS-режиме - они стояли)

Ну и вообще, она не холодная даже в простое, т.е. 20-28 ватт со всеми плясками с засыпанием-просыпанием.

У меня предыдущий компьютер в простое весь столько жрал, если не меньше

Так может, нужно ждать правок в BIOS видяхи? Не самая безболезненная процедура, конечно, но в случае чего гарантия никуда не денется.

Ну и это тоже да, будут - поправим

вот опять же спрошу - есть много всяких разных тестов для GPU на "разных сайтах" - какой тест навскидку наиболее точно может отражать скорость в каких-нибудь "в попугаях" работы FRV при использовании разных GPU (для простоты предположим что все raw файлы лежат на ram диске чтобы дисковый I/O исключит как фактор по максимуму) ?

N/A

У FRV паттерн работы непохожий ни на какую из "игр" и соответственно "бенчмарок" - показ нового файла (в режиме process raw data on GPU)(*) - это однократная загрузка большого количества данных и сравнительно дешевая обработка этих данных на видеокарте с генерацией (на видеокарте же) финального представления. Дальше, когда вы делаете zoom/поворот - это очень дешево, когда делаете пересчет (бб, экспокоррекция, контраст) - ну тоже недорого.
Что-то близкое по смыслу делают программы видеомонтажа, вроде daVinci, вот на их бенчмарки надо смотреть. Но, IMHO, карты класса 1050Ti (со своей видеопамятью) должно быть достаточно для того, чтобы ограничивала не она.

В реальной жизни, если вы используете FRV со всеми пищалками (EXIF-панель, гистограмма, Exposure stats panel, нижняя строчка) - ограничивает в первую очередь (однопоточный) GUI, а в нем - судя по всему, отрисовка шрифтов. Я уже подумывал попробовать моноширинные шрифты, но пока отложил.
Т.е. все эти 20...60fps, которыми я тут хвастался - это весь гуй выключен, с ним - падает до ~10-12 независимо от размера файла, видеокарты и т.п.

(*) Fuji X-Trans - много процессинга на CPU независимо от process RAW on GPU, в рамках OpenGL 2.1 решить проблему кажется нельзя, повышать градус (требуемую версию) OpenGL в рамках FRV 1.x тоже не хочется.

"выключен гуй" это:
Preferences - GPU processing - Refresh window after... : None
Preferences - Interface - Panels:
* Hide menu bar - checked
* Hide bottom - checked
* Dim Histogram/Stats... - unchecked

Ну и дальше жмем Tab, все панели прячутся, остается только картинка. Вот тогда 24fps на 40mpix sony, 60 fps на мелких нежатых DNG.

> отрисовка шрифтов

просто чудесно... т.е. в реальной жизни GUI же никто не выключает и спрашивается зачем (кроме проф. интереса конечно) тратить силы на перенос кода на GPU ?

N/A

Если не перенести на GPU, будет еще медленнее, потому что вместо шрифтов будем рендерить raw на том же CPU

Реально обновление 1.4.6 или какое там было первое с RAW on GPU processing - увеличило видимую пользователем скорость смены изображения - раза в два, а скорость смены параметров (WB, etc) "на порядок", то есть смысл то был огромный.

Просто без гуя это не "раза в два" а "раз в пять".

На самом деле, есть еще несложный путь "увеличить скорость листания пробелом": отложить обновление гуя миллисекунд на 100 при начале каждой отрисовки (наверное, кроме имени файла, иначе совсем странно будет). Тоже стоит в планах.

Тогда быстрые листания, "три раза пробел" - будут, я надеюсь, еще в разы быстрее, если декодирование in-advance, успевает.

Технически это сделать не очень сложно должно быть.

Прошу простить мне мою "начитанность".

А зачем пересчитывать шрифты?
Весь ГУЙ, при просмотре/листании, остаётся ведь неизменным...
... меняется лишь картинка в "фрейме" с отображением следующего/предыдущего кадра.

ВСЁ пересчитать нужно (один раз) когда меняется размер окна.
А даже в случае "добавить/убрать" какую-то инфо панель, верхнее "главное меню" остаётся неизменным.
Его можно не пересчитывать.

Подозреваю, правда, что программная составляющая "отображения" станет не сильно проще "расчётной".

Ну как это "остается неизменным"?
EXIF-данные, индикация ББ, гистограмма, статистика экспозиции, XMP - все меняется.

Add new comment