Created attachment 97585 [details]
APItrace with GL_R8 cube.
Rendering to an offscreen GL_R8 cubemap (with d24s8 renderbuffer) works, but when trying to render to all faces of a an GL_DEPTH24_STENCIL8 cubemap (no color), only +X face appears to be renderable.
I've attached two traces (apitrace 4.0) when using GL_R8 cubemap and GL_DEPTH24_STENCIL8. I use 3.1 core (latest available on my card).
Created attachment 97586 [details]
APItrace with DEPTH24_STENCIL8 cube.
Created attachment 97587 [details]
Expected result (PNG)
I've been able to reproduce this with a software rasterizer (via LIBGL_ALWAYS_SOFTWARE=1) on Mesa 13.
Thank you for this bug report. This bug has recently been fixed by the following commit in the master branch of the Mesa git repo:
Author: Nanley Chery <firstname.lastname@example.org>
Date: Tue Nov 15 16:42:23 2016 -0800
mesa/fbobject: Update CubeMapFace when reusing textures
Framebuffer attachments can be specified through FramebufferTexture*
calls. Upon specifying a depth (or stencil) framebuffer attachment that
internally reuses a texture, the cube map face of the new attachment
would not be updated (defaulting to TEXTURE_CUBE_MAP_POSITIVE_X).
Fix this issue by actually updating the CubeMapFace field.
This bug manifested itself in BindFramebuffer calls performed on
framebuffers whose stencil attachments internally reused a depth
texture. When binding a framebuffer, we walk through the framebuffer's
attachments and update each one's corresponding gl_renderbuffer. Since
the framebuffer's depth and stencil attachments may share a
gl_renderbuffer and the walk visits the stencil attachment after
the depth attachment, the uninitialized CubeMapFace forced rendering
Signed-off-by: Nanley Chery <email@example.com>
Reviewed-by: Brian Paul <firstname.lastname@example.org>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.