Войти
ПрограммированиеФорумГрафика

Думы и дуры об GAPI

#0
3:02, 5 апр. 2018

Вот порой думаешь о том, что лучше бы сделали единый GAPI, без лишнего гемора, с простотой как у развитого std и гибкостью как у какого нибудь Vulkan'а.... Я не буду щас затевать речь насколько сложен API, скажу лишь сколько воды в коде надо написать (а иногда даже целый AI) чтобы твоя рендерилка заработала как влитая! Я щас не буду касаться темы трассировки лучей, хотя это тот ещё зоопарк... Главная речь это конечно же управление памятью. Хрен поймешь, какая будет общая для нескольких GPU, какая например для SSBO, текстуры, отдельная сказка это sparse память. Лучше бы создали универсальный, умный аллокатор памяти под опредленный буфер  и задачу, и чтобы память удосужилась освободиться как и когда оно не нужно. И чтобы менеджмент, включая автоматику, памяти GPU был по возможности асинхронным и не было висяков по +100500Mb, особенно где-нибудь в кеше.... вообщем чтобы было все как у людей, а не как у колхозных бабуинов у которых в 95% случаях одна кнопка - ЖАРРИТЬ Carry/Крипту/Говноигру.... и так и оставалось висяком до конца лет и без того с завода бедного компьютера....


#1
6:56, 5 апр. 2018

Ты спрость-то что хотел?

#2
8:44, 5 апр. 2018

elviras9t
> с простотой как у развитого std
Это ты, конечно же, погорячился...

#3
9:47, 5 апр. 2018

Простота и гибкость... простота это вам к FFP, а гибкость это к DX12, Vulkan. Или C#(простота) и ASm(Гибкость) .Заметили?
Чем гибче инструмент. тем он труднее, а почему? Потому что гибкость подразумивает более тонкую настройку. а это уже добавляет сложности

#4
10:07, 5 апр. 2018

Delfigamer
> графические API подгоняют для максимизации эффективности работы с видеокартой.
> Видеокарты меняются - появляются более оптимальные способы достичь того же
> результата - GAPI предоставляет доступ к новому способу. В OpenGL compatibility
> profile старые способы реализуют по-новому для новых карт; в DX устаревшие
> технологии убирают - если взялся работать через DX12, будь добр работать через
> DX12, а не через DX9, потому что если хочется работать через DX9 - подключай
> DX9 и работай на нём, а DX12 пусть останется в покое.
>
> Абстракция и независимость кода - это задача игрового движка. Если хочешь,
> чтобы на всех DX было всё одинаково - бери какого-нибудь огра и пили на нём.

#5
5:37, 6 апр. 2018

Думал, где написать, пусть будет здесь. Мне понравилась тема dx11 с их IASet, PSSet и тд, но почему мне нужен байткод шейдера, чтоб создать InputLayout? Почему это нельзя было до сих пор разделить?

#6
10:06, 6 апр. 2018

Dimich
> PSSet

О да, куча методов с *Set / *Get можно же было сделать Set(ShaderType...

> но почему мне нужен байткод шейдера, чтоб создать InputLayout? Почему это
> нельзя было до сих пор разделить?

вертексный же шейдер, типа валидация при создании

#7
14:11, 6 апр. 2018

FlyOfFly
> Простота и гибкость... простота это вам к FFP, а гибкость это к DX12, Vulkan.
> Или C#(простота) и ASm(Гибкость) .Заметили?
> Чем гибче инструмент. тем он труднее, а почему? Потому что гибкость
> подразумивает более тонкую настройку. а это уже добавляет сложности
В моем понимании простота это когда взял шейдеры (модели 6.0 и даже 6.1), или сам написал, вставил их, поднастраиваешь, и используешь (будто заряжаешь пистолет, и жмешь на курок).
Сейчас что-то такого редко приходится наблюдать (разве что обязательно HLSL, и обязательно принудительно SM5.0).

#8
15:43, 6 апр. 2018

elviras9t
>
> В моем понимании простота это когда взял шейдеры (модели 6.0 и даже 6.1), или
> сам написал, вставил их, поднастраиваешь, и используешь (будто заряжаешь
> пистолет, и жмешь на курок).
> Сейчас что-то такого редко приходится наблюдать (разве что обязательно HLSL, и
> обязательно принудительно SM5.0).
То-есть. взял чужое решение без знания как оно работает и тупо используешь?... Почему вы движки не используйте?

#9
15:46, 6 апр. 2018

elviras9t
> (будто заряжаешь пистолет, и жмешь на курок)
За пистолетами - это к glBegin...glEnd.
Современный ГАПИ - это электрический шестиствольный пулемёт, который ты тщательно и вдумчиво соединяешь со своим самолётом, подводишь питание, охлаждение, патроны, сооружаешь специальный держатель, который позволит тебе нацеливать пулемёт раздельно от направления полёта твоего воздушного судна, загружаешь на бортовой компьютер специальную программу, которая поможет пилоту точнее нацеливать орудие в условиях сверхзвукового боя, взлетаешь и зажимаешь кнопку выстрела.
Ну и да, если хочется, чтобы летало сразу и просто - бери готовый самолёт и лети на нём.

#10
17:59, 6 апр. 2018

Delfigamer
> elviras9t
> > (будто заряжаешь пистолет, и жмешь на курок)
> За пистолетами - это к glBegin...glEnd.
> Современный ГАПИ - это электрический шестиствольный пулемёт, который ты
> тщательно и вдумчиво соединяешь со своим самолётом, подводишь питание,
> охлаждение, патроны, сооружаешь специальный держатель, который позволит тебе
> нацеливать пулемёт раздельно от направления полёта твоего воздушного судна,
> загружаешь на бортовой компьютер специальную программу, которая поможет пилоту
> точнее нацеливать орудие в условиях сверхзвукового боя, взлетаешь и зажимаешь
> кнопку выстрела.
> Ну и да, если хочется, чтобы летало сразу и просто - бери готовый самолёт и
> лети на нём.

Речь идет не о простой простоте. Речь скорее идет о многоуровненности и адаптивности в каждом языке программировании. Особенно остро тема стоит в C++, где уже есть жалобы на то что классовое ООП плохо совместимо с Vulkan API, а фанаты EcmaScript 6 ждут не дождуться усовершенствованной версии TypeScript с поддержкой Vulkan API и Full Desktop приложений. И да, еще я хотел затронуть больную тему как костыли, лишний и ненужный хлам в GAPI, устаревшие функции и т.д. Почему просто нельзя сделать в GAPI сделать по принципу "белого листа", где пишешь "добавить отрисовку N", добавляя параметры, и где надо, пишешь тонкую прослойку/надстройку. Нужен золотой молоток? Пишешь специальный плагин на низком или пред-низком уровне. Вуаля!

А в жизни:
Представьтесь (Instance), что вы хотите сделать (при этом ему похеру на самом деле), наберите набор доступных девайсов (разумеется ручками, и разумеется из доступного арсенала). На этом первая программа собрана, готова к выставке. Вам говорят "а там ничего нет". Дальше и начинается танцы с бубном. Создайте Queue, CommandPool, выбере QueueFamily, отберите по принципу Compute/Graphics/etc. хочется спросить "какой еще... я же выбрал девайс?". Иногда выясняется что данный девайс и вовсе не подходит, ты его отбрасываешь, а если единственный, плачешь слезами 11 летнего школьника/школьницы... а потом все это спрашиваешь "ну и зачем я проходил 11 летний курс военного курсанта, если там всего одна верная кнопка". Первый круг ада прошли. Дальше или Compute Route или Graphics Route, или все вместе т.е. Graphics+Compute (это уже какой-то Undertale на уровне HARDCORE, ну или что-то вроде того). Несколько адовее проходит процесс Graphics Router, и тут мне хочется закончить данный сказ...

#11
18:07, 6 апр. 2018

elviras9t
> Особенно остро тема стоит в C++, где уже есть жалобы на то что классовое ООП
> плохо совместимо с Vulkan API
Это кто так жалуется? Процентов 90, они просто недостаточно хорошо умеют в классовое ООП от С++.

elviras9t
> Почему просто нельзя сделать в GAPI сделать по принципу "белого листа", где
> пишешь "добавить отрисовку N", добавляя параметры, и где надо, пишешь тонкую
> прослойку/надстройку. Нужен золотой молоток? Пишешь специальный плагин на
> низком или пред-низком уровне.
Какой-то странный уровень абстракции. Я тебя не понял.

#12
18:17, 6 апр. 2018

Delfigamer
> Какой-то странный уровень абстракции. Я тебя не понял.
А речь о том, что по идеи уже есть дефолтный сеттингс. Создаешь окно. Указываешь что за окно и где оно. Далее отмодифицировать (девайс, инстанс, окно). Добавить шейдеры (по шаблону). Добавить коммандник (тоже используя шаблоны). Добавить механизм отрисовки (при этом с автоматической инициализациями, очистками памяти, и асинхронностями). Нужен многопоток?
А да, тут еще стоит добавить графический редактор для программирования. Жаль пока и таких нету. На графах, блоках и соединениях. Ну или гибридные редакторы.

#13
19:07, 6 апр. 2018

elviras9t
Бла бла бла. По небу бегают пони оставляя за собой радугу, девочки не пукают, а небо - вечно голубое и трава - вечно зеленая.

А теперь окунаемся в реальный мир.

А в реальном мире, у каждой операционной системы создание окна зависит от API операционной системы - это раз.

Два: создание любого уровня абстракции накладывает определенные ограничения на проектирование самого графического чипа. Соответсвенно некоторые товарищи будут специально создавать свое собственное GAPI чисто для того, чтобы эффективно работать со своим собственным железом и не зависить от хотелок других вендоров.

Три: Создание нового GAPI (привет Metal от Apple) иногда решает в том числе и чисто маркетинговые задачи. А именно - прявязать программистов к своей OS и железу, чтобы усложнить портирование этого софта на другие OS. Или сделать максимально усложнить запуск таких приложений через эмулятор. Это повышает уникальность продукта на рынке за счет непортируемых уникальных приложений и повышает продажи железа\ОС

Три_точка_пять: Никто никогда не хочет плясать под чужую дудку. И если у тебя есть какая-то технология, то нужно заставить пользователей покупать именно твой продукт. (Передаю привет CUDA и её уникальным средствам разработки, одновременно танцуя гопак на надгробье OpenCL )

#14
19:58, 6 апр. 2018

elviras9t
> А да, тут еще стоит добавить графический редактор для программирования. Жаль
> пока и таких нету. На графах, блоках и соединениях.
Для программ приличного размера схемы в таких редакторах обычно монструозные и не поддающиеся осмыслению.

ПрограммированиеФорумГрафика

Тема в архиве.