Архитектура OpenGL враппера

Поднадоело при каждом вызове команд OpenGL передавать стопицот аргументов в духе

Например, вот расшифровки трех типов:
1. UBVec4_unorm расшифровывается как GL_RGBA8 + GL_RGBA + GL_UNSIGNED_BYTE;
2. IVec3 - как  GL_RGB32I + GL_RGB_INTEGER + GL_INT;
3. u8_srgba_dxt5 - как GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5 + GL_RGBA + GL_UNSIGNED_BYTE.

Получившийся формат хорош, если с текстурами работаем по старинке через glTexImage2D, где все три аргумента указываются одновременно.

Акт четвертый
Но если мы стильные модные молодежные, у нас везде в коде используется DSA, то идти по старому пути уже не получится, придется использовать Texture Storage.
А в таком случае текстура создается через glCreateTextures+glTextureStorage2D - тут нужно указывать только internal format, а для записи и чтения format+type каждый раз могут быть разными.

Притом нереально сделать метод upload без спецификации типа текстурынх данных и передавать туда что угодно, проверяя лишь кол-во компонентов(r,rg,rgb или rgba) и тип данных(int, uint, float и тд) потому что как видно из примера выше, можно залить в текстуру массив четырехмерных векторов unsigned byte, которые в одном случае будут нормализовываться и конвертироваться в float(1), а в другом случае это будут сжатые блоки(3).

Тут есть как минимум два варианта:
1. Можно строго типизировать текстуры, один раз в начале указать тип данных и далее везде подставлять одни и те же internal format + format + type. Таким образом в методе upload достаточно двух аргументов - mip-map уровень и собственно сами данные (понятное дело что нужна ещё версия upload_sub_image с указанием offset и size).

Но вообще говоря, текстуры бывают float, srgb float, compressed float, compressed srgb float, signed integer, unsigned integer, depth, stencil и depth-stencil, и можно сначала записать во float текстуру f32 данные а затем дополнить данными normalized u8. Или создать DXT текстуру, записать несжатое изображение и вытащить сжатое.
2. Тогда надо указывать тип данных при каждой операции чтении/записи и проверять его на совместимость с типом, указанным при создании текстуры, т.е. у метода upload будет три аргумента - mip-map уровень, тип данных и сами данные.

В этот момент мои мозги закипели

и я решил набраться опыта, посмотрев решения в других библиотеках. И вот какую дичь увидел:

https://docs.rs/glium/0.26.0-alpha1/glium/texture/index.html
Чувак создал 76(!) типов текстур, по одному на каждую комбинацию типов и таргетов, и строго ограничил работу с ними. Ну это вообще ни в какие ворота не вписывается.

Кароче запарился уже думать как правильно это дело организовать и решил спросить у вас, как вы себе представляете оптимальную обертку над текстурами OpenGL, которая даёт максимум возможностей и с которой будет просто работать?

Джек Аллигатор
> а для записи и чтения format+type каждый раз могут быть разными.
не могут, это большой оверхэд, ведь драйвер сам будет менять формат

делай движок под задачу, и по ходу появления новых задач(в новых проектах) доделывай новые фичи
делать все и сразу на все случаи жизни-рецепт неуспеха
извиняюсь за очевидный факт

Джек Аллигатор
> Но вообще говоря, текстуры бывают float
для 99.99999% проектов просто ставят максимально доступный размер текстуры(флоат32, даже для одноцветных черно белых текстур) не парясь с оптимизацией и сколько памяти оно жрет(если проект упрется в это, тогда оптимизируют). Для мобилок допиливают в последний момент, если есть необходимость их поддерживать.

кароче берешь любой GLES3 движок опенсурс, копипастишь оттуда основную логику загрузчиков АПИ, и будет тебе 10-15 нужных коротких функций вместо тыщи строк кода.

Джек Аллигатор
> IVec3
Никогда не используй vec3 в 2019
либо vec2 либо vec4
все сведи к флоатам для простоты

Джек Аллигатор
> mip-map уровень
все очень плохо, оно очень поломано на всех платформах(если надо чтото кроме одной ОС поддерживать)
на один мипмапинг у тебя уйдет год и ты не сможешь это пофиксить(ни один GLES3 движок не смог)

/A\
> не могут, это большой оверхэд,
пока существует Юнити, про оверхед можешь даже не думать

Danilw
> все очень плохо, оно очень поломано на всех платформах(если надо чтото кроме
> одной ОС поддерживать)
> на один мипмапинг у тебя уйдет год и ты не сможешь это пофиксить(ни один GLES3
> движок не смог)
?
Загрузил текстуру, вызвал glGenerateMipmap.
Либо предварительно готовлю все уровни текстуры и заливаю по одному уровню.
Что тут может работать не так?

> делай движок под задачу, и по ходу появления новых задач(в новых проектах)
> доделывай новые фичи
> делать все и сразу на все случаи жизни-рецепт неуспеха

> кароче берешь любой GLES3 движок опенсурс, копипастишь оттуда основную логику
> загрузчиков АПИ, и будет тебе 10-15 нужных коротких функций вместо тыщи строк
> кода.
Дык там совсем немного кода получается. Тем более я не только враппер пишу, но и параллельно изучаю OpenGL.
Это только на текстурах так встрял, без них планировалось за пару дней весь враппер закончить и вернуться к движкописательству.

Джек Аллигатор
> glCopyImageSubData(srcName, srcTarget, srcLevel, srcX, srcY, srcZ, dstName, dstTarget, dstLevel, dstX, dstY, dstZ, srcWidth, srcHeight, srcDepth);
эта функция даже не учитывает texture arrays, то есть для всяких cubemap работать не будет.

я бы сделал как минимум так:

auto srcSubresource = ImageSubresource()
  .setImage(srcImage)
  .setLevel(2)
  //.setLayer(0) //аргументы по умолчанию можно не указывать
  .setOffset(glm::ivec2(16, 16));
auto dstSubresource = ImageSubresource()
  .setImage(dstImage)
  .setLevel(2);
renderGraph->AddTask(RenderGraph::CopyImageSubresourceTask()
  .setSrcSubresource(srcSubresource)
  .setDstSubresource(dstSubresource));

ещё можно сделать немного другой подход — необходимые аргументы указывать прямо в конструкторе, а все остальные — через setBlaBla().

Ну и если ты — один из тех, кому платят обратно пропорционально объёму написанного кода, то код выше можно сократить до:

Джек Аллигатор
Предлагаю вертеть SRGB дополнительным постэффектом, и отказаться от ненормализованных форматов,
тогда их станет на порядок меньше.

Джек Аллигатор
> Поднадоело при каждом вызове команд OpenGL
фига ты терпила. только сейчас начал враппер писать.

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

а вообще понадобилась фигня - сразу дописывай кусок враппера. весь враппер тебе вообще не нужен, тк игру пишешь, а не враппер

Suslik
ты точно не переусложняешь?

или ты так обходишь крестопроблему обязательного указывания не обязательных аргументов в крестах?

*Lain*
Да ну, по-моему очень приятный код.

*Lain*
> ты точно не переусложняешь?
а как ещё ты укажешь 2 из 20 необязательных полей в общем случае? ещё одна важная проблема, которую решает такой подход. вот есть тебя код:

glCopyImageSubData(tex, mipLevel, arrayLayer, ...);
glCopyImageSubData(tex, arrayLayer, mipLevel, ...);

можешь определить, в какой из строчек ошибка?
а так?

auto sub = ImageSubresource()
  .setImage(tex)
  .setArrayLayer(mipLevel)
  .setMipLevel(arrayLayer);
auto sub = ImageSubresource()
  .setImage(tex)
  .setArrayLayer(arrayLayer)
  .setMipLevel(mipLevel);

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

Suslik
> можешь определить, в какой из строчек ошибка?
Это решается именованными типами. Тыж об этом писал.

> а как ещё ты укажешь 2 из 20 необязательных полей в общем случае?

glCopyImageSubData(texture:tex, layer:arrayLayer, mip:mipLevel);

Suslik
> renderGraph->AddTask(RenderGraph::CopyImageSubresourceTask{{srcImage, 2, 0,
> glm::ivec2(16, 16)}, {dstImage, 2}});
Что за зверь этот RenderGraph? Где можно почитать, что это такое? Нашел только презентацию по Frostbite.

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

Fedor1995
> Это решается именованными типами. Тыж об этом писал.
если бы C++ поддерживал нормальную реализацию strong typedef'ов, я бы использовал оба способа одновременно. к сожалению, без поддержки со стороны языка не получится обойтись без синтаксического оверхеда местами.

Fedor1995
> glCopyImageSubData(texture:tex, layer:arrayLayer, mip:mipLevel);
только сейчас обнаружил, что в C++ наконец-то добавляют designated initializers! то есть можно будет так:

ImageSubresource srcSubresource = {.tex=srcTex, .level=srcLevel, .layer=srcLayer};

так можно уже сейчас, то только в C, а почему-то не в C++ (я всё ещё не понимаю, как так получилось). если реализовать такую штуку, то можно будет избегать ошибок не только на этапе компиляции, если strong typedef'ы не совпадают, но и уже на этапе написания и без синтаксического оверхеда.

Vlad2001_MFS
> Что за зверь этот RenderGraph? Где можно почитать, что это такое?
это паттерн написания рендерера, целью которого ставится составление полного графа зависимостей пассов внутри кадра, чтобы пользоваться этой информацией для автоматических оптимизаций и синхронизации. например, в вулкане на основе рендерграфа можно автоматически расставлять барьеры синхронизации и конвертить image layout'ы. имеет мало смысла для предыдущих API вроде opengl/dx11, так как в них часть работы рендерграфа за тебя реализует драйвер. хотя после реализации рендерграфа вообще не понимаю, как без него жил, потому что он позволяет by design кучу ошибок предотвращать и находить, автоматически строит информацию для профайлинга и так далее.

я о своей реализации тут писал: https://gamedev.ru/flame/forum/?id=238789&page=8&m=4957979#m111