>>410974
Видел мою продырявливаемую штуку в >>407053 →?
Она как раз связана с OpenGL.
Рассказать одну крутую штуку, про которую я только тогда и узнал (ну так получилось)?
НАЧНЁМ ИЗДАЛЕКА.

Наши качественные модельки могут иметь десятки тысяч вершин.
Чтобы их нарисовать, видеокарта должна прочитать их из (своей) памяти.
Так можно ненароком упереться в пропускную способность видеопамяти. При размере вершины 32 байта и размере индекса 2 байта, модель из 10 000 вершин и 40 000 индексов займёт 10 000 × 32 + 40 000 × 2 ≈ 400 Кб. Рисуя это 60 раз в секунду, мы кушаем 23 Мб/с. Принимая «фактическую» пропускную способность видеопамяти за 40 Гб/с, получаем теоретический предел количества таких моделей, отрисовываемых в 60 FPS — 40 Гб/с / 23 Мб/с = 1800. Впрочем, основную часть пропускной способности занимают не вершины, а пиксели (1920×1080×RGB8 = 6 Мб = 360 Мб/с, + другие буферы, как минимум буфер 3+1-байтовой глубины, а с крутой постобработкой их может быть штук 5 https://astralcode.blogspot.com/2018/12/reverse-engineering-rendering-of_28.html), поэтому можно ожидать, что пропускная способность в нашем распоряжении окажется меньшей на полпорядка-порядок, то есть мы сможем нарисовать 600–180 таких моделек.

Чтобы остаться подальше от последней цифры, игры могут специально заморачиваться со структурой вершины, втискивая её в как можно меньший размер: 24, максимум 32 байта (длина L2-кэш-линии современных GPU).

Представим типичную вершину с 3D-позицией (3×float32 = 12 байт), нормалью (3×float32 = 12 байт) и 2D-координатами текстуры (2×float32 = 8 байт).
Ну вот, мы только начали и уже получили 32-байтную вершину, а ведь нам понадобится больше: хотя бы вот касательная (для bump mapping), кости (для персонажей)...

К счастью, специально для нас придуманы более компактные форматы:
— Мы можем хранить число в интервале [0.0; 1.0] как 1- или 2-байтовое целое без знака, или аналогично в интервале [-1.0; 1.0] со знаком. Очевидный пример — обычные 8-битные компоненты цветов, хранящиеся как числа 0–255. (https://www.khronos.org/opengl/wiki/Normalized_Integer)
— Для величин, не имеющих простой проекции в эти интервалы, но и не требующих особой точности, мы можем присмотреться к float16. (https://www.khronos.org/opengl/wiki/Small_Float_Formats)

Нормаль упихивается в 3×int8 (3 байта), координата текстуры — в 2×float16 (4 байта). Для позиций можно хранить вершины относительно AABB модели и вычислять настоящую позицию в шейдере как aabb.A + relativePos × (aabb.B - aabb.A). 2-байтовой точности relativePos достаточно: если наш объект имеет размер 10 метров, позиции будут иметь точность 10/65536 м ≈ 0,15 мм. 3×uint16 = 6 байт. (https://www.khronos.org/opengl/wiki/Vertex_Specification_Best_Practices#Attribute_sizes)

GPU обычно требуют выравнивания компонентов вершины на 4 байта, с учётом которого такая вершина займёт 4 + 4 + 8 = 16 байт — гораздо лучше. (А вместо неиспользуемого паддинга можно расширить нормаль или позицию до 4 компонентов и положить в последний что-нибудь полезное.)

ТЕПЕРЬ К ДЕЛУ.
Всё это время я использовал 3×int8-нормали и в ус не дул.
Но поскольку эта кегля генерируется формулой, я решил ради интереса задать какое-нибудь безумное разбиение.
И вылезли жуткие ступеньки (2 картинка).

Справедливости ради, эти ступеньки практически не вылезают на менее безумном разбиении (картинки 5–7) и вообще не вылезают на разбиениях на 10% пути от этих к минимально адекватным, так что int8 всё ещё замечательный вариант.
Условие для того, чтобы ступенька вылезла — треугольники должны быть настолько маленькими, что массово оказываются «плоскими» — например, все 3 вершины треугольника имеют int8-нормаль (+75, −100, +25). Граница острова таких треугольников с соседним островом из (+74, −100, +26) уже может оказаться заметной.

Но ОКАЗЫВАЕТСЯ, помимо 3–4×int8 видеокартами всё это время поддерживался крутой 4-байтовый формат, в терминологии OpenGL — INT_2_10_10_10_REV, выражающий 4-мерный вектор, первые 3 компонента которого имеют 10 бит точности. (А последний всего 2, то есть ограничен тремя значениями — 0 и ±1; 4-е возможное значение не используется в знаковом варианте ради симметричности, см. статью про Normalized Integer.) В данном случае это оказывается решающим, потому что сам цвет имеет 8 бит точности — столько же, сколько и int8-нормали, поэтому ступенька нормали часто приводит к ступеньке в цвете.

По-видимому, 10-битное видео придумано таким же образом.

Конечно, с int10-10-10-2 вместо int8 и тем более float32 сложнее работать. Но не слишком. Например, мы можем представить его как uint32-значение, побитово составленное из денормализованных X,Y,Z∈[−511; 511] и W∈[−1; 1]:
uint32 v = (X & 1023) | (Y & 1023) << 10 | (Z & 1023) << 20 | (W & 3) << 30;

Вот обратное преобразование уже менее приятно (я даже не буду его приводить, интерпретация 10-битного значения как two's complement-знакового числа и его sign extend до, скажем, int32 — такое себе зрелище), но здесь оно и не нужно.

>>413460
Ты чё, ты чё! Исключения охуенны. Раньше я принципиально не использовал исключения, а потом понял, что страдаю хуйнёй. Единственная альтернатива исключениям — возврат и проверка признака ошибки, у этого варианта единственный плюс (переносимость сквозь C API) и целая куча минусов.

Во-первых, к исключению можно прицепить произвольную информацию и они поддерживают стектрейсы. Код ошибки не сообщит тебе о месте своего возникновения, «ошибка стоп ноль ноль ноль» и ебись как хочешь.

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

В-третьих. Можно подумать, что исключения медленны, но это не так. Совсем.
Наивная реализация исключений ведёт стек активных try-блоков. Try выполняет setjmp и добавляет на этот стек запись о себе. При нормальном завершении try-блока элемент снимается со стека, при броске исключения управление longjmp'ается по активным finally-блокам и подходящему обработчику catch. Setjmp довольно быстр, но в небольших функциях всё же неприятен: setjmp-вариант выполняет работу, эквивалентную десятку присваиваний; если наша функция сама выполнялась со скоростью 10 присваиваний, try замедлит её в два раза.

Значительным достижением x86-64 стала стандартизация продвинутого метода — zero-cost exceptions.
В этом варианте try не делает НИЧЕГО. Компилятор строит «карту» кода, в которой размечено, какие участки машинного кода каким блокам try соответствуют, и сохраняет её отдельно. При броске исключения раскручивается стек вызовов, и адреса возврата ищутся по этой карте: находились ли исполнявшиеся инструкции под защитой блока try, и какого именно.

Казалось бы, такое исключение должно бросаться долго и мучительно, но на деле я сейчас попробовал сделать функцию, которая вызывает сама себя под try-finally и на 100 000-м уровне рекурсии бросает исключение, которое продирается через 100 000 обработчиков и ловится catch'ем на самом верху. В zero-cost между броском и ловлей проходит 15 мс; в SJLJ — 70 мс. (Возможно, на большой программе zero-cost покажет себя хуже, чем здесь. Чуть-чуть. Ставлю анус, что даже не в 4,5 раза, на которые сейчас обгоняет.)

Но даже если бы результаты были обратными, суть в том, что программа затачивается под случай, когда исключений не происходит. С кодами возврата ты размазываешь проверку и передачу ошибок (if (!do_something()) return FAILED) прямо по своему коду; тем самым код становится больше, в L1-кэш его влезает меньше и он работает медленнее. Таблицы поиска будут, вероятно, занимать ещё больше, чем эти проверки — но они будут лежать в сторонке, в «холодном» виде. Операционные системы подгружают исполняемые файлы постранично по мере необходимости; пока исключений не бросается, информация для раскрутки вообще не будет прочитана с диска. А код, который не бросил исключение, отработает со скоростью кода, который вообще не проверяет ошибки — отсюда «zero-cost».