Задумался о предложениях перейти на нормальный API. На вулкан пока

не тяну - работы слишком много, сейчас поломать все нельзя. Но хотя бы пересесть уже на шейдеры (самые простые, чтобы все также два треугольника нарисовать и натянуть текстуру), и чтобы затем все это можно было обернуть в NV_command_list. Ибо fixed pipeline дергать уже как-то даже неприлично.
Отсюда нубский вопрос: с чего начать переход? Потому что пока еще слабовато понимаю юниформы и их причастность ко всему остальному...

мне кажется если есть все таки желание мягко вкатиться в вулкан, есть такая штука, называется NVRHI

Переход начать с того, что написать шэйдэр, точно повторяющий твой fixed pipeline и дёргать его. (На этом успокоиться. Поскольку всё равно мудаки из хроносов, тупо похоронившые fixed pipeline были мудаками, и никакого резона ориентироваться на их мнение по поводу того, что правильно а что нет не имеется).

Ну, это понятно, допустим. Тогда резон делать шейдеры в моем случае будет только при условии, что с ними рендер множества мелких draw-call'ов станет быстрее и не будет "клинить" интероп. Или нет?

Один draw call для множества мелких

Батчинг всех вертекс буферов в один? Не помогло, когда на коленке слабал. Хотя, может, неправильно готовил.

1) Основной резон делать шэйдэры -- чтобы сохранялась совместимость с новыми картами, в которых fixed pipeline могут выкинуть. 2) Я так и не понял -- почему ты считаешь, что тебе обязательно делать много дроуколлов.

нет, в твоем случае просто скорее всего это просто совершенно неважно

Конечно.

Потому что 10...12 FullHD 60 fps видеостримов в рантайме.

1) 12 стримов 60 fps -- это немного. Это около 1000 дроуколлов, если делать по одному. Затраты на это будут невелики. Ну, и думаю все жэлающие могут это объединить в пару дроуколлов, замапив каждый буфер в свою текстуру, и отправляя их по 8 штук в fragment shader, при жэлании. Но это, в общем, не важно.

Такая мысль меня и посещала. МБ и впрямь сгруппировать все буферы в один шейдер. Правда, как я понял, надо будет еще завести UBO с инфой о том, где и какая "текстура" должна лежать.

А почему неважно, собственно?

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

Потому, что 1000 дроуколлов в секунду отожрут у нас скорее всего менее миллисекунды в секунду на своё выполнение.

Вот теперь бы почитать бы, как все это делать... А то так-то ничего сложного на вид, но начинаю читать - малость глаза разъезжаются.

Если речь про SwapBuffers - то да. Если про все остальное - как знать. Весь этот BindTexture/BindBuffer/GlDraw на один стрим отжирает сам по себе около 400 мкс.

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

Так стрим уже по враме передается из кУды. И сейчас самое больное место - unmap текстуры в CUDA, который "ждет" какого-то стейта от GL. Какого - особенно не рассказывается.

Так она и пишет. Проблема-то в том, что мапить на куду можно только одну текстуру на cuda-стрим. А потом, чтобы ею воспользоваться, ее надо анмапить. Вот на unmap (да и на map тоже) есть некоторые расходы. Потому что map накладывается на glDraw.

Merde.