Часовой пояс: UTC + 3 часа




Начать новую тему Новая тема / Ответить на тему Ответить  Сообщений: 1756 • Страница 4 из 88<  1  2  3  4  5  6  7 ... 88  >
  Версия для печати (полностью) Пред. тема | След. тема 
В случае проблем с отображением форума, отключите блокировщик рекламы
Автор Сообщение
 
Прилепленное (важное) сообщение

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 темы принимаются в ЛС (Личные сообщения). В самой теме этого делать не нужно.
Спасибо за понимание! :writer:


Последний раз редактировалось Alex_Smile 22.03.2016 12:08, всего редактировалось 18 раз(а).
обновление статуса игры "Ashes of the Singularity"



Партнер
 

Member
Статус: Не в сети
Регистрация: 09.03.2010
Откуда: 161rus
Alex_Smile писал(а):
Rise of the Tomb Raider (DX12 Only) добавлена в базу Steam

Это вы в хрустальном шаре узнали или на кофейной гуще гадали? :crazy:

_________________
Intel Xeon E5-2690v4 @3.2GHz||X99 Jingsha D8 ||DDR4 4x8GB||MAXSUN RTX2060S
Intel Xeon E5-2696v2 @3.1GHz||X79 Deluxe 6.11||DDR3 2x8GB||ASUS GTX1070


 

Member
Статус: Не в сети
Регистрация: 19.08.2010
Откуда: Прямо оттуда!
Фото: 0
MEX-74, SlideX https://www.google.ru/search?q=rise+of+ ... windows+10
Или почитать Вики о ней в шапке:
Цитата:
23 июля 2015 года стало известно о планах Square Enix на выпуск Rise of the Tomb Raider для PC (Windows 10) и PlayStation 4. Дата выхода для PC намечена на начало 2016 года, в то время как для PlayStation 4 на конец 2016 года[55].

SlideX прежде чем так спрашивать, хотя бы в гугле смотрите. Все еще с лета известно.

_________________
i5-12600 | 32 GB RAM | RTX 4070 | Odyssey G4 27” 240Hz | HyperX Alloy Elite | Logitech G403 HERO | Creative AE-5 Plus | TAKSTAR SHADE | Sony DualSense


 

Member
Статус: Не в сети
Регистрация: 09.03.2010
Откуда: 161rus
Alex_Smile писал(а):
Все еще с лета известно.

Ни разу оно не известно. С таким же успехом я могу перевести это как "новый томб райдер будет работать даже на виндоус 10" :crazy:
Про версию Дх нигде нет упоминаний. Да и движок игры никто не будет новый пилить, все тот же старый от версии 2013го, даже если там и будет Дх12, то опционально, как в первых играх, которые стали задействовать возможности Дх11. Да и сейчас редко встретишь игру, которая требует обязательно Дх11 и не меньше. От совместимости со старыми версиями карт (на данный момент, я так понимаю сюда относятся карты Дх11) никто отказываться не будет, т.к. это огромный кусок пирога (ну или мешок денег) :D

_________________
Intel Xeon E5-2690v4 @3.2GHz||X99 Jingsha D8 ||DDR4 4x8GB||MAXSUN RTX2060S
Intel Xeon E5-2696v2 @3.1GHz||X79 Deluxe 6.11||DDR3 2x8GB||ASUS GTX1070


Последний раз редактировалось Alex_Smile 03.01.2016 4:27, всего редактировалось 2 раз(а).
Rise of the Tomb Raider удалена из шапки


 

Member
Предупреждение 
Статус: Не в сети
Регистрация: 09.02.2014
Фото: 0
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 раз.
Rise of the Tomb Raider удалена из шапки


 

Member
Статус: Не в сети
Регистрация: 26.04.2008
Фото: 15


 

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 раз.

 

Member
Статус: Не в сети
Регистрация: 27.10.2006
MEX-74 писал(а):
кубики должны быть с одинаковыми текстурами и одного размера, т.е. 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 слишком сложный


 

Member
Статус: Не в сети
Регистрация: 27.10.2006
Industrialice писал(а):
Я это к тому что вы сами же и расписываете про то как у нас тут много способов что-то сделать( практически без шансов прикинуть ресурсоёмкость конкретного варианта ), а потом сами же говорите что нет, у нас тут всё ок, а 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 когда за город выезжаешь.

_________________
13600k/MSI z690 tomahawk/ 2x16GB DDR5 5600 CL36/4070


 

Member
Статус: Не в сети
Регистрация: 27.10.2006
EVGENIYYY писал(а):
Бедные, бедные разработчики, неужели им что то придется делать. Может быть когда нибудь остановят конвейер по выпуску не оптимизированного, тормозного шлака.

Если какие-то разработчики не способны оптимизировать задачу даже под DX11, то под DX12 им это не удастся и подавно.

MEX-74 писал(а):
А что сейчас с DX11 multithreaded rendering-ом? вроде как один поток до сих пор везде в играх.

Никто не мешает делать больше потоков, поддержка многопоточности в DX уже давно есть, просто в большинстве случаев это нецелесообразно,
так как реальные игры и приложения упираются совсем не в количество DIP'ов, которое драйвер может скормить видеокарте, а в степень нагрузки
на видеокарту при отрисовке кадра, львиную долю которой, в конечном счёте, составляет скорость выполнения шейдеров, при условии что рендер
не упирается в филлрейт и пропускную способность шины (например загрузка/выгрузка больших текстур каждый кадр может положить любой рендер).

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


 

Member
Статус: Не в сети
Регистрация: 12.09.2010
Откуда: Калининград
Hybernaculum и разработчик более-менее знает чего он хочет, а драйвер должен делать огромное количество предположений. Написали "неудобный" код = получили то что вызывается медленный путь драйвера = получили боттлнек там где этого нельзя было ждать. Таких сюрпризов станет меньше
Вариантов что-то сделать тоже где-то станет меньше, сейчас они искусственно раздуты из-за перегруженности API фичами
MEX-74 писал(а):
А что сейчас с DX11 multithreaded rendering-ом? вроде как один поток до сих пор везде в играх.

В DX11 добавили концепцию deferred context, можно создавать комманд буфферы из разных потоков. Так что определённая поддержка многопоточности есть, просто потом эти контексты нужно рендерить в одном потоке


 

Member
Статус: Не в сети
Регистрация: 27.10.2006
Industrialice писал(а):
сейчас они искусственно раздуты из-за перегруженности 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 это подтверждают

_________________
13600k/MSI z690 tomahawk/ 2x16GB DDR5 5600 CL36/4070


 

Member
Статус: Не в сети
Регистрация: 27.10.2006
MEX-74 писал(а):
Например, в драйвере нивидиа есть поддержка многопоточного дисплей списка а в драйвере амд этого сих пор нет

Очевидно что это проблемы 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 года на рынке, игроки требуют все больше и больше зрелища, т.е. дальше игры будут технически сложнее и насыщеннее.

_________________
13600k/MSI z690 tomahawk/ 2x16GB DDR5 5600 CL36/4070


 

Member
Статус: Не в сети
Регистрация: 27.10.2006
MEX-74
MEX-74 писал(а):
выдает всего в 2 раза больше (на i7) draw calls

Если игра упирается в количество 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 в действии


Показать сообщения за:  Поле сортировки  
Начать новую тему Новая тема / Ответить на тему Ответить  Сообщений: 1756 • Страница 4 из 88<  1  2  3  4  5  6  7 ... 88  >
-

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Перейти:  

Лаборатория














Новости

Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB | Kolobok smiles © Aiwan