Войти
ФлеймФорумПрограммирование

Почему GAPI стали такими сложными? (7 стр)

Страницы: 13 4 5 6 7 8 Следующая »
#90
16:57, 17 дек. 2018

Ziltop
> Я так понял ТС хочет загрузить текстуры и модель в видеокарту и что бы сама видеокарта выдала картинку не хуже FarCry 5.
Нет, ты неправильно понял.
Я хочу делать простую графику типа Minecraft в миниатюре и не писать для вывода куба на экран полторы тыщи строк кода.


#91
17:01, 17 дек. 2018

lookid
> Те, у кого не так - уже мертвы. Они не смогут портироваться на консоли или другие платформы в сроки.
А не всем оно надо. Есть куча инди разработчиков, которые физически не потянут во всех этих кишках ковыряться. Тут либо брать готовый двиг, который оборачивает потроха вулкана в человеческое API, либо даже не знаю...

#92
18:08, 17 дек. 2018

NuclearMissileDetect
> который оборачивает потроха вулкана в человеческое API, либо даже не знаю...
Кроме того чтоб ослилить апи вулкана, надо еще и правильно его использовать, а то будет куча багов из-за отсутствия синхронизаций или жуткие тормоза из-за излишних синхронизаций.
Драйвер OpenGL и DX11 справляется с этим намного лучше большинства программистов.

#93
18:12, 17 дек. 2018

Suslik
> займёт как минимум раз в 10 больше кода
> то же самое на opengl я могу легко уложить на экран кода
Когда я первый раз учил OpenGL у меня было точно такое же впечатление.
Типа вместо одной строчки "нарисуй картинку" я должен создавать какие-то буферы и т.д.

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

MrShoor
> Звучит достаточно просто. Не знаю с чем там могут возникнуть сложности.
Да, для меня это так.
Основная сложность - бОльший объем кода, из-за чего больше чисто механических ошибок. Но в OpenGL их тоже много до того момента, пока руку не набьешь.

#94
19:22, 17 дек. 2018

Great V.
> Основная сложность - бОльший объем кода, из-за чего больше чисто механических
> ошибок. Но в OpenGL их тоже много до того момента, пока руку не набьешь.
руку то набьешь а механические ошибки никуда не денутся.

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

#95
(Правка: 19:38) 19:35, 17 дек. 2018
а то что никто тут не делает ляпов а сразу рожаете кристальный код

Програмина могла сразу писать кристальный код !
#96
19:52, 17 дек. 2018

ronniko
Кристальный код песала повелительница, в своем архтике.

#97
20:55, 17 дек. 2018

Повелительница была мужиком :)

#98
(Правка: 21:06) 20:59, 17 дек. 2018

Програмина была целеустремленной и всегда стояла на своем ! С места не сдвинуть :)

#99
21:00, 17 дек. 2018

ronniko
А мне помнится, что роника подкатывал к ней/нему, или ошибаюсь?

#100
21:01, 17 дек. 2018

Без комментариев :)

#101
(Правка: 21:24) 21:21, 17 дек. 2018

NuclearMissileDetect
> Я хочу делать простую графику типа Minecraft в миниатюре и не писать для вывода
> куба на экран полторы тыщи строк кода.
> Тут либо брать готовый двиг, который оборачивает потроха вулкана в человеческое API
народ как-то разучился структурировать код.
привыкли ко всему готовому

#102
21:44, 17 дек. 2018

Great V.
> Да, для меня это так.
То была ирония.

Современные GAPI (вулканы там всякие) - переусложнены из-за того, что фрейм практически полностью формируется на CPU, да еще и асинхронно. Надо настраивать весь пайплайн (каждый пук надо делать со стороны немощного CPU), вызывать команды отрисовки, а потом снова настраивать пайплайн. Короче CPU ботлнек, но NVidia сделала первый шаг в сторону того, чтобы вытащить все это на GPU. Все носятся с кококо рейтрейсингом, а киллерфича на самом деле вот тут: https://devblogs.nvidia.com/introduction-turing-mesh-shaders/
Просто маркетингу продвигать какой-то меш шейдер, и гораздо проще продвигать рейтрейсинг. Так что вангую, что через несколько лет (5-10 лет) появится какой-нибудь Frame shader, в котором мы будем писать все то, что сейчас пишем на CPU: настраивать пайплайны, апдейтить юниформы и делать инвокейшны в другие шейдеры. Вся рисуемая геометрия будет жить на GPU, а CPU будет нужен только для загрузки этой самой геометрии а так же будет служить спусковым крючком в виде "нарисуй фрейм" и все.

#103
21:49, 17 дек. 2018

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

#104
22:04, 17 дек. 2018

MrShoor
> появится какой-нибудь Frame shader, в котором мы будем писать все то, что
> сейчас пишем на CPU: настраивать пайплайны, апдейтить юниформы и делать
> инвокейшны в другие шейдеры.
Почти все это поддерживается в device generated commands

Страницы: 13 4 5 6 7 8 Следующая »
ФлеймФорумПрограммирование