<div dir="ltr">On 25 November 2013 11:08, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/22/2013 03:08 PM, Paul Berry wrote:<br> > The ARB_geometry_shader4 spec says, in the list of conditions necessary<br> > for framebuffer completeness:<br> ><br> > * If any framebuffer attachment is layered, all attachments must have<br> > the same layer count. For three-dimensional textures, the layer<br> > count<br> > is the depth of the attached volume. For cube map textures, the<br> > layer<br> > count is always six. For one- and two-dimensional array<br> > textures, the<br> > layer count is simply the number of layers in the array texture.<br> > { FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB }<br> ><br> ><br> > When geometry shaders were adopted into desktop GL, this condition was<br> > dropped. The constant FRAMEBUFFER_INCOMPLETE_LAYER_COUNT doesn't appear<br> > at all in the desktop GL spec. Instead, GL 3.2 says (in section 4.4.7<br> > (Layered Framebuffers)):<br> ><br> > When fragments are written to a layered framebuffer, the fragment’s<br> > layer number selects an image from the array of images at each<br> > attachment point to use for the stencil test (see section 4.1.5), depth<br> > buffer test (see section 4.1.6), and for blending and color buffer<br> > writes (see section 4.1.8). If the fragment’s layer number is negative,<br> > or greater than the minimum number of layers of any attachment, the<br> > effects of the fragment on the framebuffer contents are undefined.<br> ><br> > (note: presumably where the spec says "greater", "greater than equal" is<br> > actually intended).<br> ><br> > In other words, a framebuffer is allowed to have layers with mismatched<br> > layer counts, but if so then the client may only reliably render to<br> > layer numbers that are present in all attachments.<br> ><br> > Mesa currently implements the rule in ARB_geometry_shader4.<br> > Technically, this is a bug, since Mesa is trying to implement geometry<br> > shaders as specified in GL 3.2, not as specified in ARB_geometry_shader4.<br> ><br> > However, there are two mitigating factors:<br> ><br> > 1. If we follow the GL 3.2 spec, then it's not clear what should happen<br> > if the client calls glClear() on a framebuffer with mismatched layer<br> > counts. For example, if I have a color attachment with 4 layers and a<br> > color attachment with 2 layers, should all 4 layers of the color<br> > attachment with 4 layers be cleared, or just the first 2? Or is it<br> > undefined? If we're required to clear all 4 layers, that's going to<br> > make the Meta implementation of glClear() a lot more clumsy.<br> <br> </div></div>Principle of least surprise suggests that we should do whatever we<br> already do for mismatches in other dimensions. I seem to recall there<br> being a fairly recent Khronos bug about that very issue. I'll try to<br> track down the resoultion.<br> <div class="im"><br> > 2. The Nvidia proprietary drivers for Linux (version 313.18) follows the<br> > ARB_geometry_shader4 rule (returning<br> > FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB from glCheckFramebufferStatus()),<br> > even when an OpenGL 3.2+ context is used.<br> <br> </div>That is surprising. If you have a test case, maybe Ken could try it on AMD.<br></blockquote><div><br></div><div>Ok, I just tried it on AMD, and what I found was:<br><br></div><div>- Unlike Nvidia, AMD allows a framebuffer to have different layer counts in different attachments.<br> <br></div><div>- Calling glClear() on such a framebuffer causes all layers of all attachments to be cleared, even those layers which aren't present in all attachments.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im"><br> > Currently, I'm inclined to leave Mesa as is, and file a spec bug with<br> > Khronos encouraging them to adopt the ARB_geometry_shader4 text into<br> > OpenGL. I'm curious to hear other people's opinions.<br> <br> </div>Looking at the spec, I think the change was intentional, but I don't<br> recall why. I'd have to do some archaeology to find the reason. If we<br> poke at some other implementations and they all generate<br> FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB, then we should try to get the<br> spec changed. If some implementations don't generate the error, then<br> the next step is not as clear to me.<br></blockquote><div><br></div><div>Here's my current plan:<br><br></div><div>- Change fbo_incomplete() to allow different layer counts in different attachments.<br><br></div><div> - Replace gl_framebuffer::NumLayers with MinNumLayers and MaxNumLayers.<br><br></div><div>- In meta clears, loop from 0 to MaxNumbLayers-1, so that all layers of all attachments get cleared, even if not all attachments have the same layer count.*<br> <br></div><div>*Note: strictly speaking, this makes Meta depend on some undefined behaviour--it depends on the hardware handling writes to undefined layers independently on different attachments. But I believe that's what i965 does, and since i965 is the only user of Meta that supports layered attachments, we should be fine.<br> <br></div><div>Does that seem good to you?<br></div></div></div></div>