6 Replies Latest reply on Aug 28, 2015 12:08 AM by Cesar Badilla

    BUG REPORT: glTexSubImage2D fails to update stencil in GL_DEPTH_STENCIL texture

    yuriks

      Category

      Questions

      Answers (N/A if not applicable)

      Description

      Provide a detailed description of the issue AND 'does it fail every single time, or only sometimes?' If you can offer a % rate please do.

      On a OpenGL 3.2 Core application, updating a GL_DEPTH_STENCIL/GL_UNSIGNED_INT_24_8 texture using glTexSubImage2D updates only the depth buffer, and leaves the stencil component unchanged.

       

      This has been reproduced in 2 different machines, so I'll give my system information and mention any details I have available from the other machine.

      Hardware (HW)

      Brand and Model of the system.

      Lenovo E440

      Intel i5-4200M CPU @ 2.50GHz (4 CPUs)

      Intel(R) HD Graphics 4600

      Hybrid or switchable graphics system? ie Does it have AMD or NV graphics too?

      Intel-only system. (Bug also reproduces on a system with hybrid Intel-nVidia. Works correctly when forcing usage of the nVidia card.)

      Make and model of any Displays that are used to see the issue (see note2 below).

      LFP = Local Flat Panel (Laptop panel)

      EFP = External Flat Panel (Monitor you plug in)

      N/A

      How much memory [RAM] in the system (see note2 below).

      System RAM: 8 GB

      Provide any other hardware needed to replicate the issue.

      ie: Cables&brand, cable type [vga, hdmi, DP, etc], dock, dongles/adapters, etc

      N/A

      Hardware Stepping (see note1 below).

       

      Software (SW)

      Operating System version (see note2 below).

      Windows 8.1 (also reproduces on a Windows 10 system)

      VBIOS (video BIOS) version. This can be found in “information page” of CUI (right click on Desktop and select “Graphics Properties”.

       

      Graphics Driver version; for both integrated Intel and 3rd party vendors (see note2 below).

      10.18.14.4170 (also reproduced on unknown earlier version)

      SW/Apps version used to replicate the issue.

      N/A

      Configurations

      Single display, clone, or extended (see note2 below).

      Single

      Display resolution & refresh rate setting of each display (see note2 below).

      1600x900 @ 60 Hz

      AC or DC mode, i.e. is power cable plugged in or not?

      AC

      How to repro

      Please provide steps to replicate the issue.  These steps are very crucial to finding the root cause and fix.

      A screenshot to illustrate the issue is a huge plus. A video of the failure is even better! Attach to the post or provide the YouTube link.

       

       

       

       

       

      See below

       

      With a depth-stencil texture, initially created with `glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_DEPTH24_STENCIL8, width = 480, height = 400, border = 0, format = GL_DEPTH_STENCIL, type = GL_UNSIGNED_INT_24_8, pixels = NULL)`, attached to a FBO and then later initialized through rendering, an attempt to update it using glTexSubImage2D will only update the depth part of the texture, while leaving the stencil unchanged. Updating the same texture using glTexImage2D works correctly. This is the call used to update the texture:

       

      memset(temp_fb_depth_buffer, 0, 480 * 400 * 4);
      glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 480, 400, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, temp_fb_depth_buffer);
      
      
      

       

      Apitrace reports no OpenGL errors. I have tried to create a self-contained minimal repro for this but have been unable to: even by mirroring the calls made by my application, it appears that the depth buffer updates correctly. Instead I've attached an apitrace of the problem in my application. In Frame 200, call 25423 should clear the stencil to zero, but it's instead left unchanged, while depth is correctly cleared. On other vendors, the call also correctly clears the stencil buffer to 0. (Note that the trace will produce the same results when executing on any vendor, since the rendering result is downloaded back to system RAM and then re-uploaded to a different texture, which isn't correctly captured by the tracing. You will need to check the texture after the specified call to verify if it's broken or working correctly.)

       

      Let me know if the apitrace isn't enough and you want instructions on how to locally reproduce the issue. The application in question is Citra (citra-emu/citra · GitHub) with a specific test homebrew file.

       

      Message was edited by: Yuri Kunde Schlesner