Nvidia

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

lexa - 03/Янв/2019 11:08

Вот значит сменил видяху, на 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 выключать.

Sale: видеокарты для вычислений (но годятся и для игр)

lexa - 19/Сен/2016 11:46

По всей видимости, мои упражнения с (научными) вычислениями на видеокартах закончены, занимаюсь уже совсем другим. В связи с этим - распродаю остатки:

NVidia Geforce Titan: продано

AMD Radeon 7970HD (3GB, Tahiti XT): продано

Приветы из прошлого

lexa - 04/Дек/2015 15:24

С помощью Winqual отловил редкую (на сегодня) багу в старых драйверах Nvidia, которая била и по FastRawViewer:

  • Драйвера серии 2xx (я тестировал на 296.17, но в дампах видны и другие) для старых карт (с 8800 по GTX560) декларируют OpenGL extension GL_OES_get_program_binary, но при попытке порезолвить это расширение - оно не резолвится.
    Я вот даже не знаю, ошибка это, или спецификации OpenGL это разрешают, но декларировать расширение, которого нет на самом деле - это беспредел.
    В современных драйверах (Windows ставит 340.52 через апдейты, на geforce.com предлагают 341.92) этой проблемы нет, то есть простая установка рекомендованных апдейтов проблему решает (потому и бага редкая).
  • FRV это даже пытается обработать (на всякий случай), но, как выяснилось, неправильно (написано на всякий случай, потестировать не было случая, получилась ошибка в условии if).

Ну, полечил, в 1.2.2 будет, там всей правки на пару строк.

Одновременно повеяло прошлым из другого места:

  • Вынимаю боевую видеокарточку, вставляю заботливо заначенную 8600GS
  • Загружаюсь (Win8.1 x64), windows начинает мучительно искать драйвера.
  • Параллельно ставлю драйвера сам, перезагрузка не требуется.
  • Запускаю отладчик, чиню багу, начинаю тестировать.
  • В какой-то момент FRV мне говорит "милок, а у тебя OpenGL стал 1.1"

Это значит виндовый поиск драйверов ничего не нашел - и временно поставленные (без перезагрузки) видеодрайвера куда-то дел, вернул родной Windows OpenGL 1.1 (софтверный, еще от Win95).

После перезагрузки все, понятное дело, встало на место. Мораль же в том, что "драйвера без перезагрузки" в варианте 3-летней давности - это кривой механизм. Его, похоже, улучшили, с драйверами 3xx я таких засад не помню, но место - кусается.

 

Tegra Note?

lexa - 02/Ноя/2013 13:42

А я что-то недогоняю. 18 сентября объявили Tegra Note, обещая поставки в "следующем месяце" т.е. в октябре.

И, я извиняюсь, где? Даже в русском пресс-релизе обещали в октябре.

О журналистике? Об ошибках на сайтах вендоров?

lexa - 01/Июн/2013 12:28

В IXBT-шном обзоре GTX770 пишут:

Берется чип GTX 680 Перемычки, отвечающие за Device ID, ставятся иначе, и, оба-на получается GTX 770. Однако чтобы хоть как-то улучшить производительность в высоких разрешениях, а также в целом внести какое-нибудь отличие от вышеупомянутого GTX 680

С другой стороны, открываем список NVidia GPU по Compute Capability и читаем:

  • GeForce GTX 680 3.0
  • GeForce GTX 770 3.5
А 3.5, заметим, это Dynamic Parallelism, и прочие плюшки, связанные именно с одновременным исполнением разных kernels на одном чипе. Т.е. простой сменой Device ID тут не обойтись, нужна поддержка от чипа.

Хотелось бы понять, кто ошибся: обозреватель IXBT (и всех прочих изданий, написавших что GTX770 - это relabeled GTX680; и я не видел, чтобы NVidia кинулась их поправлять), или NVidia на своем сайте?

Про OpenCL-бенчмарки (опять, да!)

lexa - 21/Апр/2013 13:10

Злоба на эту тему у меня копится и периодически выплескивается.

История первая

В Mac OS X 10.8.3 поапгрейдили драйвера NVidia и у NVidia 6xx в LuxMark стало в полтора раза меньше попугаев.

Предполагая, что бенчмарка - нормальная (т.е. меряет время выполнения, никак его не нормализуя на конфигурацию железа), давайте попробуем разобраться что случилось:

  • Было (драйвер репортил): 28 юнитов
  • Стало: 7 юнитов (более широких, но не суть)
Само железо не изменилось. Мог, конечно, измениться (ухудшиться) OpenCL-компилятор, но у меня предположение другое: само приложение, увидев меньше юнитов, задает размеры грида (количество одновременно исполняемых Workgroups) поменьше. От этого происходит худшая утилизация железа (ну там латентность памяти не прячется) и уменьшаются попугаи. Проверить нетрудно, но лень читать исходники.

История вторая

Про NVidia и OpenCL

lexa - 01/Апр/2013 17:13
А вот в спеках у анонсированной сегодня Geforce 740M (и всех прочих анонсированных сегодня мобильных GPU написано

OpenCL: 1.2

Обновил драйвера до текущих, нет GPU Caps (да и вообще все) говорят что у моей GTX480 все еще OpenCL 1.1

Кто знает, что у NVidia будет с OpenCL 1.2, когда, как, почему, зачем и на каких картах что?

Про OpenCL-бенчмарки

lexa - 24/Фев/2013 11:55
Давно копил в себе злобу желание про это написать, а тут вот появился повод.

Вот есть такая ViennaCL, пакет линейной алгебры для "вычислительных ускорителей" (приходится писать так потому что Xeon Phi). На днях вышла версия 1.4.1 и про нее написано:

...and features a GEMM kernel reaching more than 1.3 TFLOPs on an AMD HD7970.
Я призадумался, как такое может быть, ведь HD7970 - это чуть меньше терафлопса на стандартных клоках, ну гигагерц-edition, но 1.3TFLOPs означает, что разогнали на ~35% (верю с трудом) и использовали на 100% (вовсе не верю).

Начал разбираться. Нашел вот это:

Our sample HD7970 reaches over 1.3 TFLOPs in single precision and 200 GFLOPs in double precision.
Теперь другое странно: на двух HD6990 (т.е. 4 чипа предыдущего поколения) лично добивался 1.72 терафлопса на HPL (но там основное - тот же DGEMM), т.е. по 430 GFLOPs на чип, а потом ту же систему довели до 2.053 TFLOPs т.е. по 500 на чип. При теоретической (прямо по AMD-шному сайту) 2x1.37=2.74. То есть эффективность была 75% от теоретической, а ViennaCL гордится 200/947=21%.

Да, то что я мучал полтора года назад - это было написано бодрыми немцами на CAL/IL, ViennaCL - OpenCL, но не должно же быть ТАКОЙ разницы, больше чем в три раза по эффективности?

Если посмотреть на Anandtech-овские тесты Titan GTX, то там для DGEMM приведена цифирка: HD7970 - 689 GFLOP/s и референс на 'Matsumoto et al'. Я поискал и нашел вот эту вот статью (и только потом увидел ссылку на нее прямо у Ананда), из которой получается что 689 GFLOPs - это производительность APPML, а этот самый Мацумото получил over 800 (т.е. вполне разумные ~80% от теоретической, что для одночиповой системы похоже на правду для GEMM).

Анандтеху - незачет (потому что из всех возможных цифирок конкурента - взяли самую маленькую), но про ViennaCL остаюсь в еще более тягостном недоумении, если библиотека от вендора (APPML) дает результаты вдвое выше, чем у Vienna, то чем они там гордятся то?

Еще большая катастрофа происходит с OpenCL-бенчмарками на сильно разной архитектуре (AMD/NVidia).

Вот, к примеру, Luxmark Database.

Про Geforce Titan GTX

lexa - 19/Фев/2013 11:21

Интересная история происходит с Geforce Titan GTX. Все ожидали вчера анонса и 3dnews его даже выпустил в 21:00 т.е. все было готово. А потом - спрятал (ссылка - из гуглокэша, скоро протухнет). ixbt опубликовал тот же текст но как последние слухи. Аналогичная история приключилась c expertreviews.co.uk - они дернулись аж в 14:00 (по своему UK-ному времени, насколько я могу судить, по времени появления ссылок на них в твиттере).

Короче, что-то с анонсом пошло не так, на прошлой неделе было точно всем известно, что анонс будет 18-го, но его не случилось, на сайте NVidia - тишина.

Маловероятно, что продукт уберут в последнюю секунду и не будут аносировать, хочется его обсудить в предположении что он (уже почти) есть:

Про Nvidia

lexa - 19/Ноя/2012 12:39

Если кто вдруг не видел. На Supercomputers 2012 у Nvidia был свой уголок, NVidia Technology Theater. Где выступали всякие интересные люди со всякими интересными презентациями.

Если кто не видел, рекомендую пойти на архив записей и повтыкать. Там дурацкий интерфейс, надо в правом блоке (где "чат") ткнуть в закладку "видео" и пораскрывать ее. Скажем, про CARMA мне было весьма интересно.

Чтобы два раза не вставать: утро понедельника - время для общефилософских рассуждений

Мне ужасно не нравится, то что сейчас происходит в GPGPU-мире:

  • Есть Nvidia с CUDA и с аккуратно спрятанным под ковер OpenCL. То есть OpenCL 1.1 в драйверах есть, но компания делает вид, что никакого OpenCL в природе не существует. Где, к примеру, OpenCL 1.2? При этом, в HPC-области NVidia очевидный лидер, если кто-то делает HPC-софт, то делает он его в первую очередь под CUDA (ну, насколько я вижу).
  • Есть OpenCL, в который кинулся весь остальной мир. И на CPU и на GPU и на x86 и на ARM и на прочих архитектурах. Если писать что-то для более-менее массового юзера, то очевидно что на OpenCL, ибо рынок куда шире.
Душераздирающее зрелище.

Не все йогурты одинаково полезны

lexa - 07/Май/2011 21:23

OpenCL люб нам за то, что его вкус можно ощутить и без подходящей видеокарты, уже есть реализации для CPU.

Более того, реализаций для CPU уже две на виндах: AMD-шная входит в состав ATI Catalyst (драйверов для видеокарты) и даже при отсутствии подходящей видеокарты эта часть драйверов поставится. Кроме того, Intel-овский OpenCL на днях перешел из стадии альфа в бету. На Linux, кстати, есть еще IBM-овский OpenCL для CPU, все руки не доходят его ощупать.

Берем AMD-шный пример BitonicSort из APP SDK 2.4 (это AMD-шный SDK для GPGPU) и запускаем, без перекомпиляции, прямо на всех имеющихся в машине девайсах и реализациях. Сортируем 16 млн. элементов. В порядке падения быстродействия:

  1. Intel OpenCL (процессор i7-2600k @4.5Ghz): 10.6 сек.
  2. NVidia OpenCL (GTX480, драйвер 270.61): 16.4 сек.
  3. AMD OpenCL (Radeon 5870, драйвер 11.4): 29.3 cек.
  4. AMD OpenCL на CPU (тот же самый): 415 сек.
Я подозреваю, что AMD-шный OpenCL в случае CPU просто процессор не опознал и сгенерировал код для 8086 или что-то вроде этого. Для CPU AMD Kernel Analyzer показывает нам невекторизованый код, т.е. процессор не опознался и что под него генерировать AMD не знает. На предыдущем процессоре (i7-920) такой разницы с интеловским OpenCL (тогда он был в первой альфе) не было. При этом, при исполнении на AMD-OpenCL процессор загружен где-то на четверть, а "под интелом" - на 100%

Прикол тут в другом: по формальному быстродействию горшки ранжируются в обратном порядке: у AMD бешеные 2 терафлопса на float (по пресс-релизу AMD: 2.7 TFLOP/s), у NVidia - раза в два поменьше (в районе 1.35 TFLOP/s если формально считать), у CPU же, даже если AVX посчитать как 16 операций на такт (две AVX-операции на такт) получается 16 x 4 ядра x 4.5 гигагерца = 288 GFLOP/s.

Понятно, что сортировка - дело такое, для потоков плохо предназначенное.

Чтобы два раза не вставать: большинство AMD-шных примеров на GTX480 работает быстрее (и лишь некоторые - незначительно медленнее), чем на HD5870. Несмотря на формальные попугаи, говорящие об обратном. Обратного, чтобы OpenCL-примеры NVidia работали бы быстрее на AMD, - не наблюдается.

Update: Помучал тот же пример на машине с i7-920 и GTX280. AMD OpenCL/CPU никуда не годится и там, увы. Может быть надо kernel как-то иначе писать. Что же касается реализаций Intel (CPU) и NVidia (GPU), то на этой паре железок и BitonicSort они работают практически одинаково по скорости.

640 килобайт таки мало

lexa - 27/Мар/2010 12:04
Капитан Очевидность Я в свое время почти угадал.

В том смысле, что я предсказывал 64-битную адресацию, она физически стала 40-битной. Хотя размер индекса в одном массиве остается 32-битным (собственно длинных int нету).

А так - забавно наблюдать, как оно эволюционирует. Нет, вполне разумно, но видно что первоначальная идея много очень простого железа оказалась слишком идеалистичной. Вот кэши на глобальную память добавили, притом сразу два уровня (был текстурный кэш L2, впрочем).

Сама же G200 GF100 (представленная вчера в виде GTX470/480) выглядит черезвычайно вкусно. Всяких текстов в сети навалом, сам я отпишусь когда куплю, жевать чужие тексты довольно бессмысленно.

Коня и трепетную лань

lexa - 20/Дек/2009 19:40

opencl.jpg Мучал ATI Radeon HD5870 и NVidia GTX280 в одной машине на предмет взаимной поддержки OpenCL. Поддерживают. С оговорками, но жить можно. Написал на эту тему небольшой текст:

OpenCL, NVidia, ATI и все все все....

В процессе читал AMD-шные форумы, вычитал страшного, много думал:

OpenCL performance issues
There are known performance issues for HD4XXX series of cards on OpenCL and there is currently no plan to focus exclusively on improving performance for that family. The HD4XXX series was not designed for OpenCL whereas the HD5XXX series was. There will be performance improvements on this series because of improvements in the HD5XXX series, so it will get better, but it is not our focus.

For example, if you are using local memory, they are all currently emulated in global memory. So it is possible you are going out to main memory twice as often as you do on NVidia. This can cause a fairly large performance hit if the application is memory bound. On the HD5XXX series, local memory is mapped to hardware local and thus is many times faster than the HD4XXX series.

Короче, слушайте вашу группу валенки. Формально OpenCL на HD4xxx поддержан, а фактически нужно совершенно другой kernel писать, который локальную память не использует.

А 48xx - важный кусок рынка, их много навыпускали и формально они совсем неплохие. Теперь и в этом сорте не скажу чего придется разбираться. Хорошо хоть про 2xxx/3xxx просто рекомендовано забыть.

P.S. Сравнивая два SDK, видно что ATI в области GPGPU очень заметно отстает (disclaimer: это лично мое мнение по результатам одного дня изучения :). Речь именно о качестве SDK: документации, примерах и тому подобных вещах.

CUDA vs OpenCL

lexa - 04/Июн/2009 11:39

Во-первых, сравнение производительности в предыдущем посте неверное. Действительно nBody/CUDA показывает 320+ GFLOP/s (на 280GTX), но это при количестве частиц в 32к. А при 8к - вдвое меньше, около 159 GFLOP/s.

Во-вторых, в свежих бетах (вчера вышла Beta 1.2) NVidia OpenCL производительность или самого примера или компилятора или обоих - тоже подтянули и сейчас на 8к частиц oclNBody показывает 129 GFLOP/s. Что уже вполне объясняется тем, что картинку для показа приходится гонять между OpenCL и OpenGL буферами.

Мораль: под OpenCL уже вполне можно девелопить, с тем чтобы когда все это счастье появится публично - уже быть готовым.

NVidia: CUDA и OpenCL

lexa - 24/Май/2009 11:02

После появления первой доступной реализации OpenCL (доступна для зарегестрированных NVidia-девелоперов с девелоперского сайта) все кинулись смотреть (и я тоже).

Накопали всякого интересного:

  • Бинарное представление OpenCL-кода - это практически CUDA PTX (ссылки: PDF-текст про это, ветка форума к которой этот текст относится).
  • Возможно подсовывание PTX-кода от CUDA в OpenCL (ссылки те же), смысл может быть в использовании тех CUDA extenstions, которых нет в OpenCL. Правда, при этом можно использовать просто CUDA т.е. смысла не очень много.

Кроме того, многих фишек CUDA просто нет в текущей реализации OpenCL, что огорчительно:

  • Нет работы с mapped pinned memory (что появилось в CUDA 2.2). Т.е. требуются пересылки в память видеокарты даже там, где эта память - на самом деле системная память (ноутбучные видеокарты), да и вообще без пересылок удобнее.
  • В CUDA есть взаимодействие с OpenGL, в OpenCL - нету (в спецификации есть, но пока не поддержано). В результате, пример nbody в OpenCL-реализации работает вчетверо медленнее на GTX280 (80GFLOP/s вместо 320), ибо весь пар уходит в пересылку результата на хост, а с хоста - на отрисовку.

Вообще, со всеми этими extensions все выглядит пока весьма огорчительно. Даже если они появятся в условном OpenCL 1.1+, придется писать по варианту программы под каждую видео-архитектуру. И на текущем разнообразии железа не видно выхода, слишком оно разное, чтобы из одной программы компиляцией получались эффективные решения под ATI и NVidia одновременно.

Простые юнит-тесты еще не делал, руки не дошли, пока только смотрел код из SDK.

Update Похоже, про nbody товарищи не правы. Т.п. в oclNBody какая-то работа с OpenGL objects есть. Либо недоделано, либо просто NBody нужно под OpenCL делать как-то иначе.

Update2 Предыдущий апдейт неверен, ибо (согласно Release Notes): 2. OpenCL - OpenGL Interop is not supported.

Угадал, блин

lexa - 13/Май/2009 11:59

Довелось оказаться пророком.

В комментариях к записи про анонс NVidia работающего OpenCL я предположил, что

Конечно, сейчас начнется, они вполне могут начать с драйверов для Линукса (или для 32-битной XP, что от меня столь же далеко)
И угадал, блин. Именно XP-32 и Linux-32. XP-шные бинарники на Висте не работают, несмотря на драйвер нужной версии, ругаются что не могут создать OpenCL context

А у меня Vista (32/64) и MacOS. Ну в Маке, ладно, обещали в заснеженном леопарде, а с вистой что? Руки же чешутся....

На закуску: согласно спекам OpenCL, его можно/нужно кормить исходником прямо на этом самом OpenCL (а это практически C). То бишь компилятор этого самого C сидит прямо в драйвере....

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

Subscribe to Nvidia