Geometry shaders / gl_Layer

[sytd]

Hello all,
I am writing a simple 3D application using OpenGL, and I believe I have run across a bug in the ATI fglrx drivers. When binding a cubemap to a framebuffer object using glFramebufferTexture, I am unable to properly use a depth map with the gl_Layer functionality in the geometry shader.

I render my scene in one drawcall to my framebuffer object, with different cubemap textures on the color attachment points and on the depth attachment point. The color buffers work correctly, and I can duplicate vertices for each side and they redirect to the correct "layer" as I specify. The depth buffer, however, seems to always render on the +X side (#0). Consequently, rendering a single side, or multiple sides with the same gs output for each, will work fine - when I start independently transforming each side's vertices, though, I get all kinds of nasty output as they "fight" over the depth buffer.

When I render without the geometry shader, with a draw call for each side and manually binding each cube side with glFramebufferTexture2D, it works fine. Rendering with GS also works fine if depth test is disabled, but then I have to get into depth-sorting/etc.

When rendering with GS, I can show the "unwrapped" cube on-screen and confirm that the depth buffer only contains data in +X. I can also see that the unwrapped cube renders all correctly with depth testing disabled. I have run my program through a GL debugger, and have seen that no errors are generated.

Have I found a bug in the driver, or am I simply doing something wrong? Is there some part of the specification I missed, pertaining to layered framebuffer objects and depth buffers? I searched around a bit, but found no mention of this bug on google or on the "unofficial ati bug tracker." I'm sorry if this isn't quite the right place to ask, but I don't want to start filing bugs if I'm just missing something about GL. I've heard some crazy rumors that ATI people read this forum.

(Ubuntu 9.10 / updated drivers with ...9-12-x86.x86_64.run -> deb packages. fglrxinfo says GL version 3.2.9232. I can upload screenshots or more info if needed.)

[bridgman]

GS support is relatively recent (months not years) in the OpenGL driver so I guess it could be a bug. A bunch of us read the forums including a few of the driver architects, but a bug ticket at ati.cchtml.com is probably the most reliable way to reach the right people.

The bigger question is what the bug ticket should contain. Am I correct in thinking that you expect the depth values to be a mix of +ve and -ve but they're all coming out +ve ? If so, would it be possible to attach a simple program that demonstrates the one piece you think is not behaving correctly ?

The most effective bug tickets are the ones which basically say :

- I ran this data through those GL calls
- output was A, I expected B

At that point one of the devs can usually respond either with "we think A is correct, see point 57 on page 11,357" or "oh crap, we'll fix it"

My first thought was "don't depth values always have a constant sign once the primitives have gone through the vertex shader ?" but that's based more on hardware knowledge than OpenGL knowledge.

[sytd]

The depth values appear to be correct, but they're not being directed to the proper layer of the cubemap texture. They all end up on the postive X layer. I'll attach a screenshot for now while I strip out a demonstration code:

Scene without GS: (Triangular glitch is problem with input data. Coordinate system is converted in modelview from a Quake-like system - sides are correct.)

http://img30.imageshack.us/img30/2829/screenshotiwg.png

With GS:

http://img8.imageshack.us/img8/4371/screenshot2rsf.png

With GS, no depth testing: (It also fails to clear the framebuffer when bound this way, so the top of the cube is mostly just remnants)

http://img8.imageshack.us/img8/3007/screenshot3ei.png

[sytd]

The forum appears to have eaten my previous post. I believe I have whipped up a quick demo to show what I am talking about.

In this demonstration, there is a tetrahedron drawn 5 units away, rotating around X and Y (z=0). There is a surface being drawn 50 units away towards -Z. As the tetrahedron passes through the other sides of the cube, it competes with the flat surface for the depth buffer, and will "occlude" the surface because the depth compares do not go to the correct side of the cube.

It is difficult to see. I am sorry for this; glClear does not appear to work right in this case either! As a result I draw in random colors each frame to hilight what's getting drawn and what isn't. (Seems to only clear one side of the cubemap in the framebuffer.)

edit: fixed the links.

http://img36.imageshack.us/img36/4846/screenshot5sg.png

The code is here.

http://pastie.org/796448

Examples from main app:
no gs: http://img195.imageshack.us/img195/7...eenshotxuc.png
gs: http://img638.imageshack.us/img638/9...reenshot2g.png
gs with depth test disabled: http://img188.imageshack.us/img188/6...eenshot3fm.png

[sytd]

The bug is still present in the 10.1 drivers. Same results, only now the geometry shaders seem to no longer give me any speed boost.

[Dragonlord]

I can definitely confirm this bug. It drives me mad since I can not do cube shadow mapping with a one-pass cube shadow map creation process since glClear only clears the +x side of the cube map and rendering doesn't work any better neither.

[bridgman]

Is there a ticket open for this on ati.cchtml.com ? I did a quick search for "geometry" and didn't get any likely looking hits...

[Dragonlord]

Is there a ticket open for this on ati.cchtml.com ? I did a quick search for "geometry" and didn't get any likely looking hits...

Doesn't look like... but as a "normal guy" you can anyways not make any tickets there... nor are they cared for :/

[bridgman]

I don't understand. What stops you from submitting tickets ?

Why do you think they are not cared for ? At least a half-dozen different developers read the tickets and respond to them. The developers don't respond to all of the tickets but this specific issue sounds like it's worth submitting.

[Dragonlord]

I did try that system once back in time when I reported the bug in the fbo/depth-texture code which causes depth textures to turn invalid if detached and re-attached to an FBO (most probably incorrectly marking the data invalid as it should not be the case). I also wrote a small test-bed which shows the bug clearly. I submitted this all to the devs but nobody cared.

Anyways, I don't have the password or login anymore and since with the same e-mail I can't make a new one. Furthermore I can't obtain the login/pass since for that you need to know your login, which I don't do anymore.