Гонка графических титанов продолжается

[Vorob]

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

[MoroseTroll]

RX 580 это, по сути, слегка разогнанный по ядру (на 5-12%) RX 480, всё остальное абсолютно одинаковое, кроме выросшего тепловыделения. RX 580 вышел ровно год назад, RX 480 - в июне 2016-го, на месяц раньше GTX 1060/6 ГБ.
Насчёт других игр: см. всё ту же ссылку. В зависимости от игры (Rise of the Tomb Raider, Ghost Recon: Wildlands, Assassin's Creed: Origins, Battlefield 1, The Division, Deus Ex: Mankind Divided, Far Cry: Primal), RX 580 может опережать GTX 1060/6 ГБ, а RX 480 - немного отставать.

Думаю, многие знают и помнят, что давней ахиллесовой пятой Radeon-ов всегда являлся OpenGL-драйвер. Поначалу, как и у nVidia в своё время, он был вообще никакой (конец 90-х), но nVidia ухитрилась скупить команду разработчиков OpenGL у SGI, а ATI либо не успела, либо не смогла. С тех пор (начало 2000-х), OpenGL-драйвер nVidia стал "золотым стандартом", по выражению Джона Кармака. В конце концов, ATI всё-таки наладила свой OpenGL-драйвер, но чудеса скорости он так и не показал. Полагаю, именно поэтому AMD решила сначала выкатить Mantle, а обкатав его и поняв, что дело стоящее, отдала все свои наработки по нему общественности, в лице Khronos. Последние и создали Vulkan.

[MoroseTroll]

Похоже, nVidia отменила свою довольно сомнительную программу GPP, практически заставлявшую в "добровольно-принудительном" порядке сборщиков видеокарт отказываться от сотрудничества с AMD ради своевременных поставок графических процессоров GeForce в нужном количестве.

[MoroseTroll]

Выбираем лучшую видеокарту, май 2018-го. Рекомендую этот материал тем, кто начал задумываться над покупкой (пусть даже б/у) новой видюхи. Конечно, рубль и гривна сейчас не те, что были 4 года назад, но если определённый момент наступает, то хочешь не хочешь, а денежку копишь.

P.S. Если кто не в курсе, то AMD выпустила не так давно новые гибридные процессоры Ryzen 2200G (99$) и 2400G (169$). Оба четырёхядерные, причём 2400G ещё и восьмипоточный. Встроенная графика 2400G приблизительно равна по скорости nVidia GeForce 1030, 2200G слабее где-то на 10-20%. Обзоров в Сети полно, так что ссылок приводить не буду. Данные процессоры хороши тем, что их встроенная графика позволяет худо-бедно играть в FullHD-разрешении даже в современные игры, но, разумеется, на низких настройках. Т.е. их можно использовать в качестве временного решения, если вы, допустим, пока не готовы купить себе мощную видеокарту.

[MoroseTroll]

Сравнение быстродействия видеокарт в DirectX 11, DirectX 12 и Vulkan. Очень подробный материал - рекомендую тем, кому интересно закулисье упомянутых библиотек.

[Force]

Откуда следует однозначный вывод, что все кроме программистов, писавших DOOM, просто заменили вызовы процедур directX11 на аналоги из DX-12/вулкан, без какой-либо работы по оптимизации именно под эти API.

Очень похоже на правду. Сейчас царит маркетинг, главное - это заявить поддержку, а как ты ее сделаешь - неважно. Кстати, чувак, который участвовал в разработке движка для любимого тобой Талоса, где-то писал, что добавил поддержку вулкана в движок чуть ли не за 30 минут или пять... Да, их контора входит в кронос групп, но блин... Это говорит лишь о том, что в движке есть поддержка, но он не заточен под это апи. А о каком приросте тогда может идти речь, если архитектура приложения не поменялась?

[MoroseTroll]

А о каком приросте тогда может идти речь, если архитектура приложения не поменялась?

В моём случае - о небольшом, в районе 10%. Но нужно помнить, что программисты Croteam вряд ли всё это время сидели без дела - многие уже знают, что в этом году выходит Serious Sam 4: Planet Badass. Так что поддержку Vulkan в The Talos Principle, думаю, можно считать простой тренировкой.

[Призрак Boris'а3000]

Никто не пробовал XP-шные дрова для HD7850 / R7 265 запинать c R7 370, учитывая что эти карты суть одно и то же?

[MoroseTroll]

Force: Если тебе вдруг любопытна тема скорости выполнения draw calls, то вот мой официальный результат.

[Force]

MoroseTroll, спасибо.
Интересно, насколько эти вызовы коррелируют? Ведь дх12 не в 12 раз быстрее дх11, а вызовов в 12 раз больше. Получается, это другие вызовы? Тогда зачем сравнивать их количество? Как-то не понятно.

[MoroseTroll]

Ведь дх12 не в 12 раз быстрее дх11, а вызовов в 12 раз больше.

Одно вытекает из другого: по части скорости выполнения вызовов, D3D12 и Vulkan на порядок быстрее D3D11. Кстати, что этот тест показывает у тебя? По-моему, доступная в Steam демо-версия тоже способна проводить его.

Получается, это другие вызовы?

Те же самые, просто оформленные и обрабатываемые разными способами. Так, в Vulkan практически нет контроля ошибок, а статусы, если не путаю, даже не сохраняются - всё это на совести программы, пользующейся интерфейсом. Зато, в обмен на "хорошее поведение" (дословная цитата из документации), программа получает практически неограниченный и фантастически быстрый и отзывчивый интерфейс.

Тогда зачем сравнивать их количество?

Чтобы знать, какая библиотека лучше подходит для нужд той или иной программы. Если некто пишет движок, где в каждом кадре присутствуют миллионы полигонов, то в какой-то момент он наверняка задумается: сколько же тратится времени на прорисовку каждого? У D3D до 12-й версии и OGL накладные расходы в таких случаях, во-первых, очень высоки, а во-вторых, чересчур нестабильны, т.е. первый миллион вызовов может выполниться, условно, за 0,1 секунды, а второй миллион - уже за 0,5 секунды или даже больше. А всё потому, что где-то внутри видеодрайвера может сработать какой-нибудь вспомогательный механизм, призванный, скажем, выделить больше памяти (если она заканчивается) или же инициализовать какие-нибудь внутренние буферы. Это - плата за удобство использования высокоуровнего интерфейса: ты не командуешь ему что-то сделать (как в случаях с D3D12 и Vulkan), а только просишь его об этом. Он, конечно, сделает, но попутно может заняться и своими делами, о которых ты его не просил.

[Force]

MoroseTroll, я думаю, наибольшее количество задержек в прежних апи связано с асинхронностью и синхронизацией, что влечет к простоям как видеокарты, так и процессора, когда они ожидают друг друга. Потому что видеопамять крайне редко приходится перевыделять, то есть, это сугубо ручной процесс. Не думаю, что драйвер делает много дел, "о которых ты не просил"...

Это всё опять же сильно нивелирует этот тест, потому что получается, что для вулкана и дх12 оценивается в первую очередь архитектура приложения. И если я, например, напишу тест для огла, он с большей долей вероятности выдаст такой же результат, тогда как для вулкана - всё будет сильно зависеть от того, насколько эффективно мне удалось описать механизмы управления ресурсами.

Но вообще, да, это выглядит весьма заманчиво. [off]Я как раз сейчас у себя делаю то же самое, только для огла .[/off]

[MoroseTroll]

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

И это тоже, среди прочего .

Потому что видеопамять крайне редко приходится перевыделять, то есть, это сугубо ручной процесс.

Не знаю насчёт перераспределения видеопамяти, а вот обычной, т.е. оперативной, в какой-то момент времени драйверу может и не хватить. Представь: видеодрайверу "вдруг" потребовался, скажем, не гигабайт, а всего лишь половина, т.е. 512 МБ. Если перевести всё это в 4 КБ-страницы, то их получится 131072 штуки. Вроде бы немного. Но сколько уйдёт времени у ОС на выделение данного объёма, если её менеджер памяти вдруг вздумает заняться сбором мусора как раз тогда, когда приложению нужна мгновенная реакция? Да, есть ещё и большие страницы (4 МБ), но, похоже, ими мало кто пользуется, потому что тот же 7-Zip выявил ошибку в их работе, которой уже несколько лет от роду.

Не думаю, что драйвер делает много дел, "о которых ты не просил"...

Хорошо, пусть так . Тогда вот вопрос: почему в видеодрайверах со временем начинают появляться т.н. оптимизации под те или иные игры? Ведь, казалось бы, куда уж проще: игра просит загрузить текстуру - драйвер грузит, игра просит загрузить геометрию - драйвер грузит и это. Что вообще, по-твоему, там оптимизировать, да ещё и под каждую конкретную игру? Не есть ли эти "оптимизации" всего лишь сценарии, которые, при запуске той или иной игры, как бы говорят драйверу: так, вот здесь тебе потребуется 512 МБ - зарезервируй их заранее, а не когда потребуются; потом вот тут тебе придётся выполнить данный участок кода как можно быстрее, поэтому не занимайся хернёй инициализацией буферов (потом сделаешь), а танцуй в темпе вальса?

Это всё опять же сильно нивелирует этот тест, потому что получается, что для вулкана и дх12 оценивается в первую очередь архитектура приложения. И если я, например, напишу тест для огла, он с большей долей вероятности выдаст такой же результат, тогда как для вулкана - всё будет сильно зависеть от того, насколько эффективно мне удалось описать механизмы управления ресурсами.

D3D12 и Vulkan заточены под многопоточность. В OpenGL, насколько я помню, с этим проблемы (отдавать команды на рисование может только один поток - в котором регистрировался OGL-контекст). В D3D11, формально, многопоточный рендеринг есть, но в драйверах он может быть и не реализован - Microsoft разрешила, потому что поняла, какая это аховая проблема.

[Force]

MoroseTroll

Представь: видеодрайверу "вдруг" потребовался, скажем, не гигабайт, а всего лишь половина, т.е. 512 МБ. Если перевести всё это в 4 КБ-страницы, то их получится 131072 штуки.

Идея ясна, но дело в другом. Видеодрайвер - это менеджер, то есть, управленец, он не хранит данные, и ему вряд ли понадобится гиг или половина. Он всего лишь переливает данные из общего ОЗУ в гпу-шное по указателю, а размер данных апи обязывает указывать заранее, поэтому драйвер всегда знает сколько памяти нужно. Да, у него есть какие-то свои драйверовые данные, но они навряд ли влияют на производительность.

Тогда вот вопрос: почему в видеодрайверах со временем начинают появляться т.н. оптимизации под те или иные игры? Ведь, казалось бы, куда уж проще: игра просит загрузить текстуру - драйвер грузит, игра просит загрузить геометрию - драйвер грузит и это.

Это "твики". То есть, заточка под конкретный случай. К примеру, чуваки из нвидии исследовали, КАК и КАКИМИ порциями ассасинс крид грузит текстуры и поняли, что порции четко влезают в видеопамять такого-то чипа, поэтому, они понимают, что можно не дожидаться выполнения всей текстуры в видеопамять, а получить указатель, сразу же отпустить процесс и он СНОВА пришлет текстурные данные, а потом, когда придет такой-то запрос - польется геометрия и тогда можно будет опустить такие и такие вызовы, объединив их в один "батч".

На самом деле дрова мегаумны, я кажется, говорил, что проводил исследования, пытаясь отрисовать весь уровень сифа за один вызов. Мне это удалось и я выйграл примерно 5% в скорости . Но при этом это была жуткая плохо поддерживаемая и мало расширяемая оптимизация, имеющая перевешивающее количество минусов. То есть и без моих стараний драйвер прекрасно всё делал и выдавал отличную производительность.

D3D12 и Vulkan заточены под многопоточность. В OpenGL, насколько я помню, с этим проблемы (отдавать команды на рисование может только один поток - в котором регистрировался OGL-контекст). В D3D11, формально, многопоточный рендеринг есть, но в драйверах он может быть и не реализован - Microsoft разрешила, потому что поняла, какая это аховая проблема.

В огле не то чтобы "проблемы" с многопоточностью, сколько "особенности". Причем, я так понимаю, это связано с оставлением апи простым, чтобы не включать в него код, управляющий синхронизацией ВНЕШНИХ потоков. Это бы убило напрочь всю производительность, особенно в тех приложениях, где многопоточности нет. Но, если подумать, то становится понятно, что многопоточность отрисовки в гпу через драйвер - это бутылочное горлышко, потому что видеокарта-то всё равно одна и рисует она только тогда, когда не занята ничем другим. Следовательно, чтобы избавиться от этого, нужно было только создать новое апи, где нет горлышка, то есть драйвера, а программист сам бы решал как гпу должен управляться с данными, как и откуда рисовать. Так и появились вулкан и дх12.

У меня раньше было "умно", я для каждого потока создавал контекст, который занимался загрузкой ресурсов "параллельно", а основной поток - рисовал то что ему загрузили. Вроде бы классно. Да вот только потоки, когда загружают дынные, они ДЕЛЯТ видеокарту, то есть, перехватывают ресурс и рисовать мы в этом момент не можем, плюс еще отжирается время на забирание управления, синхронизацию данных в драйвере и т.п. И как оказалось, мое распараллеливание, хоть и работало в параллельных потоках, видеокарту только тормозило. Я только недавно понял, как должно быть правильно и потратил прилично времени, чтобы это всё переписать: теперь параллельные потоки грузят ресурсы в озу, а когда основной поток их подцепляет, он их сразу переливает в гпу и использует, в результате удалось для текстур использовать неблокирующую загрузку, да и код порядком упростился и стал более структурно-опрятным, легче поддерживать. Масштабных тестирований еще не проводил, но уже сейчас видно, что стало быстрее.

[MoroseTroll]

Он всего лишь переливает данные из общего ОЗУ в гпу-шное по указателю, а размер данных апи обязывает указывать заранее, поэтому драйвер всегда знает сколько памяти нужно.

"Всего лишь"? Ну, не знаю... Гляжу вот я на размер OpenGL-драйверов GeForce и Radeon и вижу монструозные DLL объёмом в 30 МБ и более. Представляешь, сколько там строк кода? Многие миллионы. Как-то не тянет это на "всего лишь", не находишь?

Это "твики". То есть, заточка под конкретный случай.

Называй, как хочешь, сути это не меняет.