Advanced: Тема повышенной сложности или важная.
зачем холивары про АПИ? Сейчас под каждое семейство железок получается нужно писать на разном. Немного жаль, но что делать.
Что я делаю не так?
// create depth cubemap texture glGenTextures(1, &depthCubemapPoint); glBindTexture( GL_TEXTURE_CUBE_MAP_ARRAY_ARB, depthCubemapPoint); glTexImage3D( GL_TEXTURE_CUBE_MAP_ARRAY_ARB, 0, GL_DEPTH_COMPONENT, m_options->GetShadowMapPointWidth( ), m_options->GetShadowMapPointHeight( ), NR_POINT_LIGHTS * 6, 0, GL_DEPTH_COMPONENT, GL_FLOAT, nullptr); glTexParameteri( GL_TEXTURE_CUBE_MAP_ARRAY_ARB, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri( GL_TEXTURE_CUBE_MAP_ARRAY_ARB, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameteri( GL_TEXTURE_CUBE_MAP_ARRAY_ARB, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameteri( GL_TEXTURE_CUBE_MAP_ARRAY_ARB, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); glTexParameteri( GL_TEXTURE_CUBE_MAP_ARRAY_ARB, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE); glTexParameterfv( GL_TEXTURE_CUBE_MAP_ARRAY_ARB, GL_TEXTURE_BORDER_COLOR, borderColor); glBindTexture( GL_TEXTURE_CUBE_MAP_ARRAY_ARB, 0); .... glGenFramebuffers( 1, &depthOnlyFrameBufferPoint); glBindFramebuffer( GL_FRAMEBUFFER, depthOnlyFrameBufferPoint); glFramebufferTexture( GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, depthCubemapPoint, 0); glDrawBuffer( GL_NONE); glReadBuffer( GL_NONE); GLenum Status = glCheckFramebufferStatus( GL_FRAMEBUFFER); if ( Status != GL_FRAMEBUFFER_COMPLETE ) { printf( "FB error, status: 0x%x\n", Status); } glBindFramebuffer( GL_FRAMEBUFFER, 0);
Status не GL_FRAMEBUFFER_COMPLETE. Вроде бы что фреймбуфер не полон.
Такое только на intel. но решить надо
war_zes
ты больно много всего намешал за раз: у тебя массив кьюбмепов байндится как буфер глубины, тут что угодно может пойти не так, тем более на интеле. попробуй сначала одну текстуру забайндить как буфер клубины, потом одну текстуру из массива, потом уже из массива кьюбмепов. на каждом шаге проверяй glGetError(), разумеется.
war_zes
> Что я делаю не так?
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_textur… map_array.txt
каждый фейс нужно байндить как слой - я так думаю
Есть свой парсер GLSL шейдеров, с примитивным препроцессором (развертывание #include).
Сейчас я хочу прикрутить поддержку SPIRV.
Большинство моих шейдеров использует методологию UberShader.
Собственно вопрос:
1) Мне бы хотелось избежать дублирования шейдеров. Отсюда возникает вопрос. Есть ли препроцессор в SPIR-V, и могу ли я передавать дефайны уже скомпилированному байткоду.
2) Если же это невозможно, то возникает следующий вопрос - возможно ли не разделять фрагментный и вертексный шейдеры, и получить аналогичный шейдерный кеш (с opengl 4.3 есть возможность использовать shadercache, но он устаревает даже при обновлении драйверов, мне же больше интересует механизм аналогичный байткоду из dx)
Признаюсь, что я сейчас не очень понимаю, как работает SPIR-V
NickGastovski
>1) Мне бы хотелось избежать дублирования шейдеров. Отсюда возникает вопрос. Есть ли препроцессор в SPIR-V, и могу ли я передавать дефайны уже скомпилированному байткоду.
Откуда возникает дублирование кода? Шейдер с разным набором мкросов? и при компиялции типа нужно подавать 1 и тот-же шейдер, но с разными макросами это имелось ввиду?
Макросы передаются заранее при компиляции GLSL в SPIR-V. Как это байт коду передать то? это же бираный код не текстовый.
Если для компиляции ты используешь glslang то там можно через TShader::setPreamble набить прям набор #define macro val
>2) Если же это невозможно, то возникает следующий вопрос - возможно ли не разделять фрагментный и вертексный шейдеры, и получить аналогичный шейдерный кеш (с opengl 4.3 есть возможность использовать shadercache, но он устаревает даже при обновлении >драйверов, мне же больше интересует механизм аналогичный байткоду из dx)
Аналога glLinkProgram вроде нету в SPIR-V, забудь про это, ну и Vulkan/Direct3D используют раздельные шейдеры, так что для совместимости и будущего переходи на раздельные шейдера.
Andrey
> ну и Vulkan/Direct3D используют раздельные шейдеры
ты опять за своё ? не надоело ? в Vulkan/DX12 используется pipeline с вытекающими последствиями
war_zes
чем всё закончилось ?
innuendo
пока ничем - руки еще не дошли, но на заметку все написанное взял
>Откуда возникает дублирование кода? Шейдер с разным набором мкросов? и при компиялции типа нужно подавать 1 и тот-же шейдер, но с разными макросами это имелось ввиду?
Andrey, да.
Мои шейдеры выглядят следующим образом
(пример, файл glsl):
[GLSL_FRAGMENT_SHADER] #define USE_BUMPMAPPING 1 #include "components/test.frag" [GLSL_VERTEX_SHADER] #define USE_BUMPMAPPING 1 #include "components/test.vert"
Собственно я хотел бы сделать бинарную версию вот этих frag/vert шейдеров, макросы же задавать в данном файле.
>Макросы передаются заранее при компиляции GLSL в SPIR-V. Как это байт коду передать то? это же бираный код не текстовый.
Я просто помню, что в DX рендерах (например, шейдеры в skyforge), есть бинарное представление шейдеров. Вроде байт-код (он через отдельную утилиту раньше генерился). Но я не знаю, возможно ли ветвление с этим кодом, или же все макросы передаются при создании
>Если для компиляции ты используешь glslang то там можно через TShader::setPreamble набить прям набор #define macro val
Понимаешь, у меня реализована обратная совместимость и заранее так предопределить просто невозможно. Например, у меня строчка #version вычисляется
>Аналога glLinkProgram вроде нету в SPIR-V, забудь про это, ну и Vulkan/Direct3D используют раздельные шейдеры, так что для совместимости и будущего переходи на раздельные шейдера.
Если я тебя правильно понял, то у меня уже давно так и сделано ( так же реализован GL Pipeline ), сейчас я хочу добиться того, что бы мои шейдеры везде работали.
NickGastovski
> Есть ли препроцессор в SPIR-V, и могу ли я передавать дефайны уже
> скомпилированному байткоду.
Там вроде есть какие-то specialization constants. Можно заменить дефайны на if от них и это вроде как будет эквивалентно дефайнам в SPIR-V.
gammaker, спасибо, сейчас посмотрю.
Собственно еще вопрос, как я понимаю SPIRV гарантирует обратную совместимость. То есть, я пишу код на последнем стандарте, загоняю его в SPIRV и могу забыть про головные боли в виде: "Это работает на NV, не работает на AMD, работает на Intel"?
p.s: понимаю, что на мой вопрос можно ответить полистав спеку - просто не могу уделить время. Прошу прощения за хелпвампиризм.
NickGastovski
> То есть, я пишу код на последнем стандарте, загоняю его в SPIRV и могу забыть
> про головные боли в виде: "Это работает на NV, не работает на AMD, работает на
> Intel"?
да. Но баги драйверов наверное учесть стоит, но с этим проблем все же меньше, нежели компилить как раньше glsl компилятором определенного вендора.
Andrey
> нежели компилить как раньше glsl компилятором определенного вендора.
если писать на glsl по стандарту - это были редкие проблемы