Так вроде игра Зеленая как Ларка
Да и движок неудобный для АМД карт Unreal Engine 4

zzzzzzz тем не менее радеон тоже очень даже хорошо выглядит, 390-ая обганяет 970-ую, на отмену от тайтлов, где разработка была под эгидой АМД и нвидиа никто вообще не оптимизировал

zzzzzzz
а шильдик есть? или
?

У АМД архитектура SIMD & scalar, у Нвидиа скалярные архитектуры ещё начиная с 8к серии 10 лет назад. Тут уже сколько раз звучали обвинения драйвера и планировщика, игнорируя то, что у АМД и Нвидиа в принципе разный подход. Подход АМД более идеалистичен, он позволяет получить карты с более высокой теоретической производительностью, но требует более бережной оптимизации - со стороны всех, начиная с разработчиков игр

Про идеалистичность - это пустые слова. По-твоему в GF какой-то другой подход? Тот же самый SIMD (вернее, более расширенный вариант - SIMT) на массиве скалярных ALU.
До GCN было иначе, т.к. AMD гораздо позже отказалась от векторных ALU (а до какого-то поколения эти гении и вовсе использовали 5-мерные считалки, хотя в графике 4 канала всегда было, т.е. прямо на уровне архитектуры был заложен 20% недозагруз математики, это не считая потери на 1- и 2-мерных вычислениях).
Оптимизировать код шейдера под свою архитектуру можно на лету в драйвере, что nvidia и делает со времен GF FX. И оптимизировать под скалярники как раз намного проще, чем под векторные ALU, т.к. потери типа "тут нам надо только 2 канала, потому половина мощности просто не используется" отсутствуют как класс.

zzzzzzz в самой игре я имел ввиду, как в мафии и по аналогии.

Неправда, читайте доки по GCN

Я после этой фразы не уверен также, что вы в курсе, что такое VLIW вообще. Эта фраза не имеет никакого смысла в контексте VLIW архитектуры

Я конечно, все понимаю, но этот ваш DX12 отвратительный в нынешнем его виде. Вот даже в BF1 он хуже работает, чем DX11. А уж Mantle в BF4 вообще разрывает в щепки. Вот интересно, как мелкософту удалось переплюнуть себя, что DX12 медленнее не только Mantle, но даже своего же собственного DX11 при этом не имея никаких графических улучшений, ведь он разрабатывался, как раз чисто для повышения производительности.

Это делают все видеокарты со времён появления шейдерной программируемости вообще, сама концепция шейдеров в DirectX это подразумевает

Добавлено спустя 4 минуты 39 секунд:
Dreamlike разработчики сейчас вставляют DX12 как имплементацию для DX11, у кого вообще есть полноценный рендерер, написанный под 12?
Получается что переделывать почти что ничего не нужно, но DX11 вызовы транслируются в DX12. Получается DX11 API -> DX12 API -> driver
Это популярный среди разработчиков метод добавления новых API, он очень мало усилий требует, в сравнении с написанием рендерера под какой-то конкретный API. Не приходится при таком подходе ожидать, что 12 поднимет производительность, хорошо ещё, если не опустит

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

Чтобы не писать специально рендерер под новый API, если бы его пришлось писать под каждый API - это значит отдельно под PS3, XB360, PS4, ну и, будем считать, что под XB0/Windows PC можно унифицированным обойтись, тогда это ещё 2 - DX11 и DX12, сколько получается? Явно слишком много. Потому приходится делать трансляции, пускай это снижает эффективность
У кого-то есть ещё Android и iOS в поддержке, значит ещё 2 API, Metal и OpenGL ES, принципиально отличных от всех предыдущих
Никто не в восторге от такой ситуации, потому индустрии и нужен качественный кроссплатформенный АПИ, каковым может стать Вулкан

Где-то читал, что хоть там и по 4 SIMD векторных ALU, но они могут выполнять разные инструкции параллельно. Если нет, то они еще тупее, чем я считал ранее.

А причем здесь VLIW? Это обертка для инструкций по сути. Речь была про реализацию ALU и SIMD в частности.

Неа. Поначалу ничего не делали. Потом nvidia начала читерить в тестах из-за сложной архитектуры GF FX (которая, по крайней мере в версии NV35, имела теоретическую математическую производительность выше R3xx, но на случайном коде без специальной заточки наоборот проигрывала почти в 2 раза), просто подменяя шейдеры на свои, заранее сделанные под конкретный тест. Их на этом поймали, был большой скандал. Вот тогда то и появился умный анализатор кода шейдеров, который уже не имел базы подменных шейдеров, а прямо на ходу проводил перестановку команд или замену на аналоги.

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

Они не могли не делать ничего потому как набор инструкций шейдеров не какой-то храдвейр-специфик, в отличие от х86 или ARM, он предполагает рекомпиляцию под конкретную видеокарту. Другое дело, что это можно делать честно, согласно спекам, оптимизировать этот код при трансляции без изменения его функциональности, или явно нарушить спеки и поменять функционал, что Нвидиа и делала со своими FX

Там не было недозагруза на уровне архитектуры.
Другое дело, что в играх возможностей драйвера по извлечению ILP не хватало, чтоб загрузить все слоты и в этих задачах ILP < 4.

Сколько раз повторить надо? Речь вообще не о VLIW (я помню про VLIW5 в первых terascale, и если ты подумал, что я о нем рассказываю, то нет). Меня не волнует, как там инструкции запускались (хотя это еще одна отдельная точка появления недогруза). Речь шла об устройстве ALU.

Не совсем. Спеки API четко диктуют, какие низкоуровневые операции поддерживаются считалками. И их на самом деле не очень много. https://en.wikipedia.org/wiki/ARB_assembly_language#ARB_Assembly_Instructions https://msdn.microsoft.com/en-us/library/windows/desktop/hh447232(v=vs.85).aspx
Можно конечно эти спеки игнорировать и выдумывать свой набор, но не похоже, чтобы так кто-то извращался.
Поначалу многие писали шейдеры прямо на ассемблере, пока их в средней игре не развелось слишком много, а сами они не стали сложнее.

Добавлено спустя 5 минут 5 секунд:

Вот на это как раз нет никаких спецификаций
Каждый делает в меру своей испорченности.

Вы не вели речь про устройство ALU, что вы выше писали сами же, относилось сугубо к VLIW

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

Естественно там есть чёткие спецификации. Результат выполнения чётко определён спеками, как он получен - нет

Через интринсики же. И AMD и Nvidia точно извращенцы - у них такое есть.

Нет. Речь шла о векторных ALU. Это ни разу не одно и то же. А еще точнее об MD (multiple data) в SIMD. Только чисто скалярные считалки не имеют никаких ограничений на этот MD. У векторной считалки недостаток данных ведет к недозагрузке. Например, если считать 2 цветовых канала на 4х-мерной считалке, то недозагруз 50%.
VLIW работает еще до SIMD (вспоминаем что означает SI), на уровне раздачи инструкций по считалкам.
Это мы еще не коснулись темы о том, что более простое устройство скалярных ALU позволяет им работать на более высоких частотах.

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

Откуда? Единственная похожая точка проверки - референсный софтовый растеризатор в DX SDK. Главное получить близкую (даже не идентичную) к нему картинку. Нет никаких спецификаций на модификацию кода драйвером. Если есть, то прошу предоставить ссылку.

Потому что в спеках указан необходимый минимум инструкций. А расширять никто не запрещает.