OpenGL - как GLenum представляет собой 32-битное целое число без знака?

Перечисления используются не только для буферов - везде нужна символьная константа. В настоящее время присвоено несколько тысяч значений перечисления (посмотрите свой GL.h и последний glext.h. Обратите внимание, что производители выделяют свои официальные диапазоны перечисления, чтобы они могли реализовать специфичные для поставщика расширения, не мешая другим, поэтому 32-битное пространство перечисления - неплохая идея. более эффективен, так что это не проблема производительности.

ОБНОВЛЕНИЕ: Как отметил Андон М. Коулман, в настоящее время выделяются только 16-битные диапазоны перечисления. Было бы полезно сделать ссылку на OpenGL Enumerant Allocation Policies, где также есть следующее замечание:

Исторически сложилось так, что значения перечисления для некоторых расширений от одного производителя распределялись блоками по 1000, начиная с блока [102000,102999] и постепенно увеличиваясь. Значения в этом диапазоне не могут быть представлены как 16-разрядные целые числа без знака. Это налагает существенное и ненужное снижение производительности на некоторые реализации. Такие блоки, которые уже были выделены поставщикам, будут оставаться выделенными до тех пор, пока поставщик добровольно не освободит весь блок, но никакие дополнительные блоки в этом диапазоне не будут выделены.

Большинство из них, похоже, было удалено в пользу 16-битных значений, но использовались 32-битные значения. В текущем glext.h все еще можно найти некоторые (устаревшие) перечислители выше 0xffff, например

#ifndef GL_PGI_misc_hints
#define GL_PGI_misc_hints 1
#define GL_PREFER_DOUBLEBUFFER_HINT_PGI   0x1A1F8
#define GL_CONSERVE_MEMORY_HINT_PGI       0x1A1FD
#define GL_RECLAIM_MEMORY_HINT_PGI        0x1A1FE
...

В любом случае, зачем вам использовать шорт? В какой ситуации вы когда-либо оказались бы, если бы вы даже сэкономили более 8 КБ оперативной памяти (если отчеты о тысяче GLenum верны), используя short или uint8_t вместо GLuint для объявлений перечислений и const? Принимая во внимание потенциальную несовместимость оборудования и потенциальные кроссплатформенные ошибки, которые вы могли бы внести, довольно странно пытаться сохранить что-то вроде 8-килобайтной оперативной памяти даже в контексте оригинального 2-мегабайтного графического оборудования Voodoo3d, не говоря уже о суперкомпьютерных фермах SGL OpenGL. предназначен для.

Кроме того, современное оборудование x86 и GPU выравнивается по 32 или 64 битам за раз, вы фактически остановите работу CPU / GPU, поскольку 24 или 56 бит регистра должны быть обнулены и ЗАТЕМ прочитаны / записаны, тогда как он мог работать со стандартным int, как только он был скопирован. С самого начала OpenGL вычислительные ресурсы имели тенденцию быть более ценными, чем память, в то время как вы могли вносить миллиарды изменений состояния в течение жизни программы, вы экономили бы около 10 КБ ( килобайт) от RAM max, если вы заменили каждое 32-битное перечисление GLuint на uint8_t. Я так стараюсь сейчас не быть излишне циничным, хех.

Например, одна веская причина для таких вещей, как uint18_t и т.п., - это большие буферы данных / алгоритмы, в которых данные соответствуют этой битовой глубине. 1024 ints против 1024 переменных uint8_t в стеке - 8k, собираемся ли мы разделить волосы на 8k? Теперь рассмотрим необработанное растровое изображение 4k размером 4000 * 2500 * 32 бита, мы говорим о нескольких сотнях мегабайт, и это было бы в 8 раз больше, если бы мы использовали 64-битные буферы RGBA вместо стандартных 8-битных буферов RGBA8 или в четыре раза больше. по размеру, если мы использовали 32-битную кодировку RGBA. Умножьте это на количество открытых текстур или сохраненных изображений, и замена небольшого количества операций процессора для всей этой дополнительной памяти имеет смысл, особенно в контексте такого типа работы.

Вот где имеет смысл использовать нестандартный целочисленный тип. Если вы не используете 64-килобайтную машину или что-то в этом роде (например, звуковой сигнал старой школы, удачи в использовании OpenGL на этой системе), если вы пытаетесь сэкономить несколько бит памяти на чем-то вроде объявления const или счетчика ссылок, вы просто тратить время зря.