Archives Discussions

[particlepeter]

I think I found a driver bug and would like to report this one.

Uploading to a GL_TEXTURE_CUBE_MAP with glTextureSubImage3D (please notice: direct state access function) does work only for layer 0 (face positive x). The other layers are not uploaded and produce this GL_DEBUG error:

   source   : GL_DEBUG_SOURCE_API

   type     : GL_DEBUG_TYPE_ERROR

   severity : GL_DEBUG_SEVERITY_HIGH

   id       : 0x3e8

   message  :

      glTextureSubImage3D has generated an error (GL_INVALID_VALUE)

System: Kaveri 7800 A-10 (Radeon R7, GN 1.1), Driver: Crimson Edition 15.12 (supposed to support GL 4.5 except shader version 450).

On NVidia GTX 970 with current driver the problem does not exist, and the upload works as expected.

The GL 4.5 spec does not allow to specify GL_TEXTURE_CUBE_MAP and GL_TEXTURE_CUBE_MAP_ARRAY as named textures for glTextureSubImage3D, but ARB_direct_state_access extension does.

Besides there is no DSA way upload data to a named cubemap texture unless a texture view with an acceptable target for glTextureSubImage3D is used ( should be considered as hack ).

[ionutcava]

I'd like to confirm the issue. It never worked on AMD cards and I had to use a hackish workaround (use cube map arrays with a single layer instead of a regular cubemap).

[particlepeter]

You can still use GL_TEXTURE_CUBE_MAP, you just can't upload bits directly into. But you can use any matching texture view to upload the data. For me GL_TEXTURE_2D_ARRAY works and in theory (not tested) GL_TEXTURE_CUBE_MAP_ARRAY and GL_TEXTURE_2D (one view per cubemap face) should work as well. 

[ionutcava]

Indeed, GL_TEXTURE_2D_ARRAY works fine with regular cubemaps. In my personal case, GL_TEXTURE_CUBE_MAP_ARRAY provided a more elegant solution for my codebase. Not a showstopper by any means, but a bug is a bug (and I'm a bit OCDish about workarounds).