I'm running a depth map demo that uses fbo depth maps as a render target. The fbo (EXT) is filled with static stuff (like a mask that is moved over the screen). So the contents i drawed into the buffer (the depth component is bound to the buffer) are ignored I don't know if this feature is in progress or if you know what is missing in the driver. If you have no clue, I can offer the following things after a request: - Pics of the artifacts - Videos that show that the depth texture is not updated - Explanation how i set up the FBO/Renderbuffer The thing works with fglrx. Extensions I used: Framebuffer_EXT Renderbuffer_EXT (for depth store)
Here the code: glGenFramebuffersEXT(1, @fb); glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb); glGenRenderbuffersEXT(1, @render_buf); glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, render_buf); glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT, ShadowSize, ShadowSize); glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, render_buf);
You'll probably have more luck with the r600 gallium driver (r600g).
Oh I forgot: Driver is of course r600g.
i found a demo that reproduces the bug for me: http://cgit.freedesktop.org/mesa/demos/ in /demos/shadowtex in all programs the texture looks the same. i attached a pic how the demo looks like. watch the shadow
Created attachment 42761 [details] shadow map
The following hint is given in the docs: 6.3 CB 6.3.1 DB->CB Copies: RV6xx In RV610, RV630, RV620, and RV635 but not R600, RV670, or RS780, the DB->CB copies needs the following programming sequence to ensure the DB will read the Z/Stencil data. 1. Z_ENABLE = true 2. STENCIL_ENABLE = true 3. Z_WRITE_ENABLE = false 4. STENCILWRITEMASK = 0xff 5. Z vertices = 0.0. (like a Z clear to 0.0) 6. ZFUNC= LEQUAL 7. STENCILFUNC = REF_ALWAYS 8. STENCILZPASS = STENCIL_KEEP 9. STENCILZFAIL = STENCIL_INCR_CLAMP 10. DB_RENDER_OVERRIDE.FORCE_HIZ_ENABLE = FORCE_DISABLE It seems to be a RV6xx specific problem. I hope, you can fix it.
Probably fixed by d171ae086bae37279251a1d6f32e16e333cfc154, shadowtex is at least.
the latest changes (between 11bc8991e94e2fa6d461193a6aff47f8f94b7a47 and 5e19b5ad16b2761fe9d8877318f2fc97b229335c) broke the driver. I can use 2D menus with OGL and glxgears works but when I start using the 3D part (uses FBO, shaders and vertex buffers), the image freezes and I cannot stop my prog.
does reverting 11bc8991e94e2fa6d461193a6aff47f8f94b7a47 fix it?
Git bisect blamed 14880a510a1a288df0778395097d5a52806abfb0, there are strange things happening. The framerate drops downto 3 FPS and the texture bug appears again. I also created a patch inspired from glisse that fixes the bug (but is maybe not the correct solution because the tiling management is still unfinished)
(In reply to comment #9) > does reverting > > 11bc8991e94e2fa6d461193a6aff47f8f94b7a47 > > fix it? no
Created attachment 42797 [details] [review] Patch that fixes the depth map copying (but not the freeze) This patch is inspired by Jerome Glisse This patch does not solve the problem that the screen is freezing
When I revert 14880a510a1a288df0778395097d5a52806abfb0, i can play with working depth textures and 3 FPS.
Ah, as I see the original problem is fixed in git but the glsl compiler had a deadlock so that I cannot test it.
resolved long time ago
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.