OpenGL 4.x (81 стр) / Графика / Форум / Программирование игр

// 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. но решить надо

Suslik
Модератор

#1202
(Правка: 6:26) 6:26, 1 авг. 2018

war_zes
ты больно много всего намешал за раз: у тебя массив кьюбмепов байндится как буфер глубины, тут что угодно может пойти не так, тем более на интеле. попробуй сначала одну текстуру забайндить как буфер клубины, потом одну текстуру из массива, потом уже из массива кьюбмепов. на каждом шаге проверяй glGetError(), разумеется.

MrShoor
Участник

#1203
7:24, 1 авг. 2018

war_zes
> Что я делаю не так?

For glFramebufferTexture and glNamedFramebufferTexture, if texture is the name of a three-dimensional, cube map array, cube map, one- or two-dimensional array, or two-dimensional multisample array texture, the specified texture level is an array of images, and the framebuffer attachment is considered to be layered.

Думается мне нехорошо, что ты пихаешь кубмап эррей как GL_DEPTH_ATTACHMENT.
Попробуй сделать через glFramebufferTexture2D, либо бинди не в GL_DEPTH_ATTACHMENT, а в GL_COLOR_ATTACHMENT

innuendo
Постоялец

#1204
9:11, 1 авг. 2018

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_textur… map_array.txt

каждый фейс нужно байндить как слой - я так думаю

NickGastovski
Постоялец

#1205
5:05, 2 авг. 2018

Есть свой парсер GLSL шейдеров, с примитивным препроцессором (развертывание #include).
Сейчас я хочу прикрутить поддержку SPIRV.
Большинство моих шейдеров использует методологию UberShader.

Собственно вопрос:
1) Мне бы хотелось избежать дублирования шейдеров. Отсюда возникает вопрос. Есть ли препроцессор в SPIR-V, и могу ли я передавать дефайны уже скомпилированному байткоду.
2) Если же это невозможно, то возникает следующий вопрос - возможно ли не разделять фрагментный и вертексный шейдеры, и получить аналогичный шейдерный кеш (с opengl 4.3 есть возможность использовать shadercache, но он устаревает даже при обновлении драйверов, мне же больше интересует механизм аналогичный байткоду из dx)

Признаюсь, что я сейчас не очень понимаю, как работает SPIR-V

Andrey
Постоялец

#1206
11:08, 2 авг. 2018

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 используют раздельные шейдеры, так что для совместимости и будущего переходи на раздельные шейдера.

innuendo
Постоялец

#1207
(Правка: 11:16) 11:11, 2 авг. 2018

Andrey
> ну и Vulkan/Direct3D используют раздельные шейдеры

ты опять за своё ? не надоело ? в Vulkan/DX12 используется pipeline с вытекающими последствиями

innuendo
Постоялец

#1208
11:17, 2 авг. 2018

war_zes

чем всё закончилось ?

war_zes
Постоялец

#1209
13:03, 2 авг. 2018

innuendo
пока ничем - руки еще не дошли, но на заметку все написанное взял

NickGastovski
Постоялец

#1210
(Правка: 18:15) 18:06, 2 авг. 2018

>Откуда возникает дублирование кода? Шейдер с разным набором мкросов? и при компиялции типа нужно подавать 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 ), сейчас я хочу добиться того, что бы мои шейдеры везде работали.

gammaker
Постоялец

#1211
18:17, 2 авг. 2018

NickGastovski
> Есть ли препроцессор в SPIR-V, и могу ли я передавать дефайны уже
> скомпилированному байткоду.
Там вроде есть какие-то specialization constants. Можно заменить дефайны на if от них и это вроде как будет эквивалентно дефайнам в SPIR-V.

NickGastovski
Постоялец

#1212
20:04, 2 авг. 2018

gammaker, спасибо, сейчас посмотрю.

Собственно еще вопрос, как я понимаю SPIRV гарантирует обратную совместимость. То есть, я пишу код на последнем стандарте, загоняю его в SPIRV и могу забыть про головные боли в виде: "Это работает на NV, не работает на AMD, работает на Intel"?

p.s: понимаю, что на мой вопрос можно ответить полистав спеку - просто не могу уделить время. Прошу прощения за хелпвампиризм.

Andrey
Постоялец

#1213
20:22, 2 авг. 2018

NickGastovski
> То есть, я пишу код на последнем стандарте, загоняю его в SPIRV и могу забыть
> про головные боли в виде: "Это работает на NV, не работает на AMD, работает на
> Intel"?
да. Но баги драйверов наверное учесть стоит, но с этим проблем все же меньше, нежели компилить как раньше glsl компилятором определенного вендора.