Member
Статус: Не в сети Регистрация: 19.08.2010 Откуда: Прямо оттуда! Фото: 0
Т.к. в темеWindows 10 обсуждение DirectX 12 является офтопиком, пишем о нём и будущих играх с ним здесь. ******************************************************************************************** О самом DirectX 12 и его "Feature Levels" (какие ВК и какой уровень DirectX 12 поддерживают). Анонсированные игры: "Gears of War: Ultimate Edition (2016)" и "Deus Ex: Mankind Divided". Более полный список: "Список игр с DirectX 12" (немецкий язык, но нужная табличка и так понятна). ************************************************************************************* Одна "Игра в раннем доступе" уже вышла: "Ashes of the Singularity" (Steam). FPS у DirectX 12 примерно в 2 раза выше по сравнению с DirectX 11:
Ashes of the Singularity: DX11 vs DX12 Benchmarks by DigitalFoundry (видео):
Другой тест от GameGPU - в нём прирост всего около 5%. В общем пока всё неясно, и сама игра очень "сырая", её статус на 22.03.2016 - Beta. ************************************************************************* "Правила хорошего тона" (Локальные Правила) этой темы:
ЧИТАЕМ, ПРЕЖДЕ ЧЕМ ПИСАТЬ!:
1) Для начала ознакомиться с Правилами Конференции. 2) Категорически запрещается использовать красный цвет в сообщениях - оставьте его для Модераторов и Куратора! Рекомендуется также не злоупотреблять остальными цветами. 3) Все односложные сообщения (типа: "Аналогично", "+1...", "У меня также") будут стираться без предупреждений. 4) "Шапка" темы будет исправляться как можно быстрее. Куратор всегда в курсе всех изменений. Уважайте и цените труд Куратора - не подгоняйте его! 5) Обсуждение действий Куратора в теме не допускаются! Для этого есть ЛС (Личные сообщения). Прежде, чем написать - советую всё обдумать. "Дыма без огня не бывает!" 6) Предложения и вопросы по "шапке" и FAQ темы принимаются в ЛС (Личные сообщения). В самой теме этого делать не нужно. Спасибо за понимание!
Последний раз редактировалось Alex_Smile 22.03.2016 12:08, всего редактировалось 18 раз(а).
обновление статуса игры "Ashes of the Singularity"
23 июля 2015 года стало известно о планах Square Enix на выпуск Rise of the Tomb Raider для PC (Windows 10) и PlayStation 4. Дата выхода для PC намечена на начало 2016 года, в то время как для PlayStation 4 на конец 2016 года[55].
SlideX прежде чем так спрашивать, хотя бы в гугле смотрите. Все еще с лета известно.
Member
Статус: Не в сети Регистрация: 09.03.2010 Откуда: 161rus
Alex_Smile писал(а):
Все еще с лета известно.
Ни разу оно не известно. С таким же успехом я могу перевести это как "новый томб райдер будет работать даже на виндоус 10" Про версию Дх нигде нет упоминаний. Да и движок игры никто не будет новый пилить, все тот же старый от версии 2013го, даже если там и будет Дх12, то опционально, как в первых играх, которые стали задействовать возможности Дх11. Да и сейчас редко встретишь игру, которая требует обязательно Дх11 и не меньше. От совместимости со старыми версиями карт (на данный момент, я так понимаю сюда относятся карты Дх11) никто отказываться не будет, т.к. это огромный кусок пирога (ну или мешок денег)
Alex_Smile, никакой конкретики нет относительно Rise of the Tomb Raider
Цитата:
Square Enix говорят Rise of the Tomb Raider "будет доступна для Windows 10 и Steam в начале 2016", это можно понимать как исключительно для Windows 10, или как в продаже через магазин приложений на Windows 10 и Steam
Последний раз редактировалось Alex_Smile 03.01.2016 4:27, всего редактировалось 1 раз.
Member
Статус: Не в сети Регистрация: 12.09.2010 Откуда: Калининград
morgden писал(а):
этого не понял,DX12 это понятно что это двенадцатый директ,а что такое тогда 11_0?я думал что означает одиннадцатый директ,да к тому же аида пишет Аппаратная поддержка DirectX-DirectX v11,вот меня и смущает это,а точнее будет ли задействован дх12 на новых играх на моей карте если Аппаратная поддержка DirectX-DirectX v11
Эти Feature Levels ввели в DX11, благодаря которым DX10 полностью устарел и стал ненужным, DX11 возможно использовать даже на видеокартах GeForce FX 2003-го года выставив feature level 9_1. С поддержкой DX12 пока что полный бардак, feature level не работают т.к. видеокарта А поддерживает фичу 1, но не поддерживает фичу 2, видеокарта Б наоборот. Разработчикам придётся проверять поддерживает ли видеокарта определённую фичу, а не полагаться на её поддержку - так было во времена до выхода DX10 и так со всеми OpenGL, ничего нового вобщем-то
Hybernaculum писал(а):
C точки зрения программирования, DX12 это один большой и обширный геморрой, поскольку необходимость писать часть кода видеодрайвера (кто видел код DX12 примеров, тот поймёт) существенно усложняет сам рендер и его отладку, так как менеджмент ресурсов видеокарты, в том числе заполнение и многопоточная синхронизация буферов команд и т.п. в DX12 ложатся на разработчиков игр (раньше этим занимался драйвер).
Среди разработчиков игр очень популярно использование сторонних движков, особенно сейчас, выбор только начинается с UE4, Source( 2 ) и Unity. Разработчики этих движков сделают поддержку DX12( поддержку Metal в UE4, например, встроили, на вид, быстро и эффективно ) => множество проектов на этих движках сможет его использовать без существенных затрат в сравнении с разработкой под DX11 Если кто-то пишет свой рендерер и игра не слишком масштабная - DX11 никто не отбирает, пишите на нём. Даже DX9.0c 2004-го года до сих пор прекрасно работает и его можно использовать для разработки, наличие более новых API просто расширяет выбор Необходимость DX12 по-моему куда как больше под вопросом не потому что это низкоуровневый API, а потому что скоро выходит Vulkan, который будет мультиплатформенным. Если его капитально не зафейлят, зачем нужен DX12 не очень понятно
Добавлено спустя 1 час 10 минут 51 секунду: И ещё пара слов про оптимизацию для высокоуровневых API вроде DX11, это всегда был, есть и будет ад Простой пример, я хочу в пикселном шейдере записывать значения пикселов в UAV и мне нужен счётчик сколько всего пикселов было записано. Беру простой атомик, использую InterlockedAdd, и... получаю совершенно ужасную производительность. Убираю атомик, использую встроенный в UAV IncrementCounter - казалось бы, одно и то же, просто интерфейс немного разный. А в результате скорость увеличивается в 100 раз. Внезапно. А ведь есть ещё AppendBuffer который я мог бы использовать - и опять же, совршенно неизвестно насколько это было бы быстрее/медленнее кучи других варинтов которые у меня есть Или другой пример, всем известно что вызовы отрисовки дорого стоят. Но что же насчёт вызова на выполнение компьют шейдера? У Нвидиа я нашёл в документации уверения что Dispatch почти что ничего не стоит и его можно смело вызывать. У АМД? Без понятия, так и не нашёл что они говорят Типичная картина для высокоуровнего API когда совершенно неизвестно что под капотом происходит, оптимизация превращается в кошмар. Приходится искать документацию, перечитывать форумы и в конце-концов делать свои тесты( и не факт что их результаты будут коррелировать с результатами использования в реальном приложении ) Не у всех есть на это время, не у всех есть возможность задать вопрос непосредственно Нвидиа/АМД/Майкрософт чтобы прояснить какие-то важный момент С низкоуровневыми DX12/Vulkan таких ситуаций будет меньше, хочется верить что на порядок А сейчас с появлением новых высокоуровневых ситуация ухудшается в геометрической прогрессии - добавляются новые фичи, в итоге 1 и тот же графический эффект можно сделать десятком разных способов, но совершенно непонятно что же будет с производительсностью, какие-то из этих способов могут оказаться катастрофически медленными. Я перепробовал 6 различных методов просто чтобы понять как же мне оптимальнее рисовать системы частиц, поддержку которых вырезали в DX10 и сказали делайте сами. Хочу заметить, самый быстрый способ из тех что я опробовал( простой инстансинг + вписывание квадов/кругов в треугольник ) всё равно в 2 раза медленее полуфиксированного конвеера из DX9 С древних времён и до DX8 API предоставляли исключительно фиксированный конвеер для отрисовки, туда добавляли со временем новые и новые фичи - бамп маппинг, скиннинг, спекулар лайтинг. Когда API начали ломиться от фич, сделали программируемый конвеер скинув реализацию многих фич что раньше были в API на самих разработчиков, да, стало нужно всё делать вручную - даже просто для вывода треугольника стало нужно написать пару шейдеров. Так что по сути история повторяется, место текущим API в могиле и не вижу смысла откладывать
Последний раз редактировалось Industrialice 29.12.2015 3:53, всего редактировалось 1 раз.
кубики должны быть с одинаковыми текстурами и одного размера, т.е. copy/paste.
Нет, не должны. В случае аппаратного геометрического инстансинга у каждого кубика можеть быть своя индивидуальная позиция, размер, цвет, ориентация и даже текстура, если использовать атлас (много текстур упакованы в одной), текстурный массив или 3D текстуру.
MEX-74 писал(а):
выделять огромное количество видеопамяти из-за этих самых DIP-ов
Сами по себе DIP'ы отношения к выделению видеопамяти, тем более огромному, не имеют, по сути это лишь команда на отрисовку индексированного примитива (Draw Indexed Primitive) с заданными параметрами, буферами, текстурами и т.п.
_________________ Царствие божие внутри тебя и повсюду вокруг тебя, а не в зданиях из камня и дерева. Расколи кусок дерева и я там, подними камень и ты найдёшь меня.
Member
Статус: Не в сети Регистрация: 12.09.2010 Откуда: Калининград
Hybernaculum писал(а):
использовать атлас (много текстур упакованы в одной), текстурный массив или 3D текстуру
Hybernaculum писал(а):
В реальном же DX11.0 (даже не 11.2) приложении, все эти кубики выводились бы батчами/инстансингом (десятками тысяч кубиков за раз), это снизило бы количество DIP'ов до нескольких сотен, что не только разгрузило бы процессор, но и повысило бы FPS, по сравнению с DX12, во много раз и это даже без использования геометрического шейдера, вертексного шейдера и выборки координат кубиков из текстуры (тогда количество DIP'ов можно вообще до 1 (одного) свести, то есть все эти кубики можно генерировать и рисовать внутри самой видеокарты без участия CPU вообще)!
Генерировать на GPU можно по-разному - можно на лету в вершинном или геометрическом шейдере, можно 1 раз построить геометрию на GPU, записать в буффер и потом из него рисовать. Записать в буффер можно также несколькими способами - можно записать используя компьют шейдер, можно использовать Stream-Output и писать из вершинного или геометрического шейдера Можно использовать инстансинг, но он вообще предусматривает что все инстанции будут содержать одинаковое количество вершин. Ну, можно его не использовать - можно записать дополнительно буффер с количеством вершин, или можно помечать вершины которые означают конец геометрии, рисовать просто как триэнгл стрипы и генерировать вырожденные треугольники для разделения геометрии. При таком подходе данные во входящем буффере могут быть весьма произвольными - как читать конкретную инстанцию будет определяться с помощью бранчей в вершинном шейдере Тут можно долго так сидеть и рассуждать сколько у нас оригинальных вариантов это сделать, а потом доходит до того что нужно выбрать только один - вот где и начинается тот самый ffffuuuuu. Функциональную разницу между ними несложно прикинуть, а вот насколько это будет быстро работать на разном железе - ну, удачи Я это к тому что вы сами же и расписываете про то как у нас тут много способов что-то сделать( практически без шансов прикинуть ресурсоёмкость конкретного варианта ), а потом сами же говорите что нет, у нас тут всё ок, а DX12 слишком сложный
Я это к тому что вы сами же и расписываете про то как у нас тут много способов что-то сделать( практически без шансов прикинуть ресурсоёмкость конкретного варианта ), а потом сами же говорите что нет, у нас тут всё ок, а DX12 слишком сложный
1. Не надо путать мух с котлетами. DX12 не уменьшает количество вариантов "что-то сделать" и не упрощает жизнь разработчику, он лишь увеличивает сложность реализации уже имеющихся в DX11 варианов решения задачи, поскольку то, что должен делать драйвер, в DX12 взвалили на разработчиков. 2. Прикинуть ресурсоёмкость конкретного варианта в конкретной ситуации можно только тестированием, универсального способа "на все случаи" нет. 3. Речь шла о том, что тестирование вырожденных случаев неоптимального решения задачи (например задачи вывода 1млн. кубиков) в синтетике не несёт в себе практического смысла для прогнозирования производительности в реальных играх и приложениях, иначе получается как в известной рекламе - "положим обычную газету в серную кислоту, а ххххх - в дистиллированную воду".
_________________ Царствие божие внутри тебя и повсюду вокруг тебя, а не в зданиях из камня и дерева. Расколи кусок дерева и я там, подними камень и ты найдёшь меня.
Последний раз редактировалось Hybernaculum 29.12.2015 8:36, всего редактировалось 1 раз.
Member
Статус: Не в сети Регистрация: 26.04.2008 Фото: 15
Hybernaculum писал(а):
в DX12 взвалили на разработчиков.
Бедные, бедные разработчики, неужели им что то придется делать. Может быть когда нибудь остановят конвейер по выпуску не оптимизированного, тормозного шлака.
Member
Статус: Не в сети Регистрация: 17.03.2008 Откуда: РФ Фото: 9
Все понятно, DX12 значит будет не скоро, в 2016 точно не будет. А что сейчас с DX11 multithreaded rendering-ом? вроде как один поток до сих пор везде в играх.
Добавлено спустя 18 минут 10 секунд: Hybernaculum
Цитата:
Нет, не должны. В случае аппаратного геометрического инстансинга у каждого кубика можеть быть своя индивидуальная позиция, размер, цвет, ориентация и даже текстура, если использовать атлас (много текстур упакованы в одной), текстурный массив или 3D текстуру.
Теоретически да, но практически везде 3 типа куста и 3 типа дерева и у нас уже готовая локация "лес" и типа никто не заметит))))). Кстати растительность часто дропает фпс нехило, например в ГТА5 когда за город выезжаешь.
Бедные, бедные разработчики, неужели им что то придется делать. Может быть когда нибудь остановят конвейер по выпуску не оптимизированного, тормозного шлака.
Если какие-то разработчики не способны оптимизировать задачу даже под DX11, то под DX12 им это не удастся и подавно.
MEX-74 писал(а):
А что сейчас с DX11 multithreaded rendering-ом? вроде как один поток до сих пор везде в играх.
Никто не мешает делать больше потоков, поддержка многопоточности в DX уже давно есть, просто в большинстве случаев это нецелесообразно, так как реальные игры и приложения упираются совсем не в количество DIP'ов, которое драйвер может скормить видеокарте, а в степень нагрузки на видеокарту при отрисовке кадра, львиную долю которой, в конечном счёте, составляет скорость выполнения шейдеров, при условии что рендер не упирается в филлрейт и пропускную способность шины (например загрузка/выгрузка больших текстур каждый кадр может положить любой рендер).
_________________ Царствие божие внутри тебя и повсюду вокруг тебя, а не в зданиях из камня и дерева. Расколи кусок дерева и я там, подними камень и ты найдёшь меня.
Member
Статус: Не в сети Регистрация: 12.09.2010 Откуда: Калининград
Hybernaculum и разработчик более-менее знает чего он хочет, а драйвер должен делать огромное количество предположений. Написали "неудобный" код = получили то что вызывается медленный путь драйвера = получили боттлнек там где этого нельзя было ждать. Таких сюрпризов станет меньше Вариантов что-то сделать тоже где-то станет меньше, сейчас они искусственно раздуты из-за перегруженности API фичами
MEX-74 писал(а):
А что сейчас с DX11 multithreaded rendering-ом? вроде как один поток до сих пор везде в играх.
В DX11 добавили концепцию deferred context, можно создавать комманд буфферы из разных потоков. Так что определённая поддержка многопоточности есть, просто потом эти контексты нужно рендерить в одном потоке
сейчас они искусственно раздуты из-за перегруженности API фичами
Ага, давайте уберём все фичи и будем вместо игры писать драйвер, чтобы общаться напрямую с видеокартой только ради того, чтобы рисовать 1млн. кубиков через 100500 DIP'ов, нагружая при этом все ядра CPU, забыв про всё остальное.
Industrialice писал(а):
получили то что вызывается медленный путь драйвера
Как показывает практика, такие ситуации возникают крайне редко, если не пытаться решать задачи через одно место.
_________________ Царствие божие внутри тебя и повсюду вокруг тебя, а не в зданиях из камня и дерева. Расколи кусок дерева и я там, подними камень и ты найдёшь меня.
Последний раз редактировалось Hybernaculum 29.12.2015 10:16, всего редактировалось 1 раз.
Member
Статус: Не в сети Регистрация: 17.03.2008 Откуда: РФ Фото: 9
Hybernaculum
Цитата:
так как реальные игры и приложения упираются совсем не в количество DIP'ов, которое драйвер может скормить видеокарте, а в степень нагрузки на видеокарту
DIP это тоже самое что Draw calls? если да, то сказанное вами верно не всегда, в зависимости от типа игры. Все что сказано ниже - это не ради версуса нвидиа/амд, хотя я предпочитаю амд ))) Например, в драйвере нивидиа есть поддержка многопоточного дисплей списка а в драйвере амд этого сих пор нет, т.е. на nvidia можно выдавать большее количество draw calls (есть цифры в последнем обновлении 3Dmark) чем на amd при наличии одинаковой платформы. При этом в некоторых играх когда попадает большое количество объектов в кадре то у амд дропается фпс из-за меньшего draw calls. Далеко ходить не надо, последние игры Daying light, Progect cars, Fallout 4 это подтверждают
Например, в драйвере нивидиа есть поддержка многопоточного дисплей списка а в драйвере амд этого сих пор нет
Очевидно что это проблемы AMD, а не API или разработчиков игр.
_________________ Царствие божие внутри тебя и повсюду вокруг тебя, а не в зданиях из камня и дерева. Расколи кусок дерева и я там, подними камень и ты найдёшь меня.
Member
Статус: Не в сети Регистрация: 12.09.2010 Откуда: Калининград
Hybernaculum писал(а):
Ага, давайте уберём все фичи и будет вместо игры будем писать драйвер, чтобы общаться напрямую с видеокартой только ради того, чтобы рисовать 1млн. кубиков через 100500 DIP'ов, нагружая при этом все ядра CPU, забыв про всё остальное.
Я уверен что будет куча надстроек над DX12 вроде SDL, какие-то из них будут удобны в использовании и иметь низкий оверхед Напоминает мне как С++ уже несколько десятков лет хоронят, зачем он нужен когда есть куда как более дружественные Go, Java, C# etc. которые на бумаге как минимум ни чем не уступают
Hybernaculum писал(а):
Как показывает практика, такие ситуации возникают крайне редко, если не пытаться решать задачи через одно место.
Простейший пример. Используйте RWTexture2D вместо RWStructuredBuffer для работы с текстурой и вот вам запросто медленный путь драйвера с огромным падением производительности. Не вижу тут ничего через одно место. Кроме реализации драйвера конечно
Member
Статус: Не в сети Регистрация: 17.03.2008 Откуда: РФ Фото: 9
Hybernaculum
Цитата:
Очевидно что это проблемы AMD, а не API или разработчиков игр.
Да, и нет одновременно. GTX980 в DX11 multithreaded выдает всего в 2 раза больше (на i7) draw calls чем в singlethreaded (т.е. больше чем в у 290х или FuryX для которой одинаково draw calls что single что multi) , в тоже время 290х выдает в DX12 multithreaded в 15 раз больше (на i7) чем в singlethreaded. Т.е. AMD считает что для в 15раз большего эффекта лучше сосредоточиться на поддержке DX12 чем менять (если это возможно) работу драйвера дляпостепенно устареващего DX11, ведь игры усложняются и насыщаются объектами, это поколение приставок (для которых нет ограничения DIP) всего 2 года на рынке, игроки требуют все больше и больше зрелища, т.е. дальше игры будут технически сложнее и насыщеннее.
Если игра упирается в количество DIP'ов, на нормальном современном железе, то у её разработчиков руки явно не из того места растут.
MEX-74 писал(а):
AMD считает что для в 15раз большего эффекта лучше сосредоточиться на поддержке DX12 чем менять (если это возможно) работу драйвера
Всё гораздно банальнее, AMD не осилила оптимизировать драйвер для XBoX One под многопоточность, в виду рукожопости драйверописателей и(или) ограничений архитектуры GPU в XBoX One, поэтому AMD подрядилась разработать свой API (Mantle), который изначально планировался как довесок к DX11, в котором нерешённые драйверописателями AMD проблемы ложились бы на плечи разработчиков игр, а потом Micro$oft взяла Mantle, скопипастив даже документацию, оформила в отдельный API и переименовала в DX12. Классический способ решения проблемы превращеним бага в "фичу".
_________________ Царствие божие внутри тебя и повсюду вокруг тебя, а не в зданиях из камня и дерева. Расколи кусок дерева и я там, подними камень и ты найдёшь меня.
Member
Статус: Не в сети Регистрация: 12.09.2010 Откуда: Калининград
Hybernaculum писал(а):
Всё гораздно банальнее, AMD не осилила оптимизировать драйвер
Вобщем всё превратилось в теорию заговора. AMD не смогли оптимизировать свой драйвер, решили разработать Mantle т.к. разработать принципиально новый API и драйвера к нему куда проще( ! ) Затем Apple решили сделать также с Metal Потом Майкрософт решила на его основе сделать DX12( зачем им так было делать - who cares ) Ну и Khronos со своим OpenGL Next, теперь именуемым Vulkan, просто решили не отстовать, выбросив свой OpenGL который до этого принципиально не перерабатывался несколько декад Всё это не эволюция индустрии к которой разработчики так долго призывали( те же Crytek ещё в 2008 просили низкоуровневый доступ к картам ), а просто всё из-за лени P.S. наверное про эту теорию заговора всё-таки было в шутку сказано, не может же это быть всерьёз. Но Poe's law в действии
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения