Archives Discussions

[dark_sylinc]

Hi everyone!

I've been told this is the best place to report AMD GL driver bugs as there is no official bug tracker, but GL Driver team monitors this forum. So here it goes:

When creating a 3D textures where the depth is higher than width and height, glGenerateMipmap will crash with an access violation reading location 0x00000020 deep inside the driver.

The following code can reproduce the crash (modified version of gl-320texture3d.cpp from g-truc's samples😞

bool initTexture()
{
  std::size_t const Size(16);


  std::vector<float> Data(Size * Size * 128);
  for(std::size_t k = 0; k < Size; ++k)
  for(std::size_t j = 0; j < Size; ++j)
  for(std::size_t i = 0; i < Size; ++i)
  Data[i + j * Size + k * Size * Size] = glm::simplex(glm::vec4(i, j, k, 0.0f) / float((Size / 8 - 1)));


  glPixelStorei(GL_UNPACK_ALIGNMENT, 1);


  glGenTextures(1, &TextureName);


  glActiveTexture(GL_TEXTURE0);
  glBindTexture(GL_TEXTURE_3D, TextureName);
  glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_BASE_LEVEL, 0);
  glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MAX_LEVEL, int(glm::log2(float(Size))));
  glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
  glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
  glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
  glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
  glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE);


  //glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MAX_LEVEL, 5);


  //glTexParameteri( GL_TEXTURE_3D, GL_GENERATE_MIPMAP, GL_TRUE );


  size_t mipmap = 0;
  size_t newSize = Size;
  size_t depth = 32;
  //while( newSize > 0 && depth > 0 )
  {
  glTexImage3D(
  GL_TEXTURE_3D,
  mipmap,
  GL_RGBA8,
  GLsizei(newSize),
  GLsizei(newSize),
  GLsizei(depth),
  0,
  GL_RGBA,
  GL_UNSIGNED_BYTE,
  &Data[0]);


  /*newSize = newSize >> 1;
  /*if( !newSize )
  newSize = 1;*//*
  depth = depth >> 1;
  ++mipmap;*/
  }


  glGenerateMipmap(GL_TEXTURE_3D);

  glPixelStorei(GL_UNPACK_ALIGNMENT, 4);


  return glf::checkError("initTexture");
}

The call stack:

	atioglxx.dll!5b135a21()
	[Frames below may be incorrect and/or missing, no symbols loaded for atioglxx.dll]
	atioglxx.dll!5b139692()
	atioglxx.dll!5b13dbf3()
	atioglxx.dll!5b128d08()
	atioglxx.dll!5adef819()
	atioglxx.dll!5ae673f3()
	atioglxx.dll!5ae677c5()
	atioglxx.dll!5b696159()
	atioglxx.dll!5b6962e0()
	atioglxx.dll!5b6960f2()
	atioglxx.dll!5ae2284a()
	atioglxx.dll!5addf031()
	atioglxx.dll!5a6472e1()
	atioglxx.dll!5acfc1a0()
	atioglxx.dll!5ace116d()
>	gl-320-texture-3d.exe!initTexture()  Line 155 + 0xd bytes	C++
	gl-320-texture-3d.exe!begin()  Line 185 + 0x5 bytes	C++
	gl-320-texture-3d.exe!glf::run(int argc=1, char * * argv=0x00546008, const glm::detail::tvec2<int,0> & Size={...}, int Profile=1, int Major=3, int Minor=2)  Line 359 + 0x5 bytes	C++
	gl-320-texture-3d.exe!main(int argc=1, char * * argv=0x00546008)  Line 236 + 0x26 bytes	C++

I can provide more information if requested. The actual bug happened in an Ogre sample where it crashes in a call we perform to glGetTexLevelParameteriv instead, but the driver's DLL's code location where it crashes is exactly the same (to be exact, it crashes at rep movs    dword ptr es:[edi],dword ptr [esi];  where esi = 0x20)

Whenever depth is lower than width or height, the crash doesn't seem to occur (or if mipmaps aren't generated).

Catalyst 13.12,

OpenGL Driver version: 6.14.10.12618

AMD Radeon 7770 1GB GDDR5 Clock 1095 Mhz  Memory 1245Mhz

Windows 7 SP1 64-bit (tested applications were 32-bit)

8GB RAM

Intel Core 2 Quad Core Extreme QX9650

Best Regards,

Matias

[dark_sylinc]

Attached a sample file that reproduces the crash. Just run the program and watch it crash.

The exe was build in release mode but has debug symbols so you can see what's happening in the context gl-320-texture-3d.cpp (to compile that file, just download g-truc's samples and replace the cpp file)

[gsellers]

Hi Matius,

We've figured out the problem and fixed it in our internal builds. There was some logic that was not taking depth into consideration when computing the number of mipmap levels required to store the texture. The fix will be in an upcoming Catalyst driver.

Thanks,

Graham