glFramebufferTextureLayer is slow

Hello, I’m rendering to a 3D texture and I found out that the command glFramebufferTextureLayer (or glFramebufferTexture3D) cause a huge stall of about 15 miliseconds in my application.
Everything else is working fine including the framebuffer I want to render to.

Could someone explain me why is this so slow?

Thanks in advance.

Generally, you should just set up FBOs before starting your render loop. So the performance characteristics of the function that attaches images to framebuffers is not generally important.

Ok, so is there any way to render to a 3D texture without using glFramebufferTextureLayer? What’s the correct way of doing this?

Afaik: create FBO at app-start, attach all slices (or go the glframebuffertexture3D way), check FBO completion.
On frame: glDrawBuffers() - to select which slice/layer to draw to. The glDrawBuffers() way takes nanoseconds, up to a microsecond; the invalidation+recreation of a FBO is generally guaranteed to be much slower.

I can’t attach all layers to the framebuffer because I only have 8 color attachments while my volume texture has 64 layers. On the other hand, and as I said before, the glFramebufferTexture3D is as slow as glFramebufferTexturelayer so that isn’t an opinion either.

Hm? Only 8 color attachments possible? Afaik, you can have an unlimited number of them in a FBO. The HW limit is “how many attachments can be enabled to be drawn to at once (MRT)” .

I can’t attach all layers to the framebuffer because I only have 8 color attachments while my volume texture has 64 layers.

Make a bunch of different FBOs, one for every 8 layers in your 3D texture.

Hm? Only 8 color attachments possible? Afaik, you can have an unlimited number of them in a FBO.

From the spec:

Table4.11:Framebuffer attachment points. i in COLOR_ATTACHMENTi may range from zero to the value of MAX_COLOR_ATTACHMENTS -1.

You can only have so many color attachments in an FBO.

Thanks, I’ll give it a try.

Thanks for the correction.

After digging a little bit more into the performance issues I was having I found out that the whole rendering to volume texture is not a good ideia because it’s slow.

I’m not sure if this is true but it seems that every time glFramebufferTextureLayer is called, somekind of pipeline flush occurs. And even though its performance cost is small, when you multiply it by the number of layers you have to render (32 in my case) the performance drop becomes serious.
I ended up using a single 2D texture (which simulates an unwrapped 3d texture) to avoid all the layers changes during rendering and that trick provided me with a good performance increase.

Thanks for the help, guys.

After digging a little bit more into the performance issues I was having I found out that the whole rendering to volume texture is not a good ideia because it’s slow.

So, what happened when you tried to use multiple FBOs?