Created attachment 67843 [details] Problematic texture When the Main Protagonist descends from Tu'tara Caverns Floor 19 via Stairs Down into lover level, game crashes, with this message: *-*-* Version 1.6.5 (Shoggoth) terminate called after throwing an instance of 'Ogre::RenderingAPIException' what(): OGRE EXCEPTION(3:RenderingAPIException): Zero sized texture surface on texture MEDIA/PARTICLES/TEXTURES/TRAIL/TRAIL37.DDS face 0 mipmap 2. Probably, the GL driver refused to create the texture. in GLTexture::_createSurfaceList at ../../../../RenderSystems/GL/src/OgreGLTexture.cpp (line 405) ./configure --prefix=/usr --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --libdir=${prefix}/lib/x86_64-linux-gnu --localstatedir=/v ar --build=x86_64-linux-gnu --with-driver=dri --enable-r600-llvm-compiler --with-dri-drivers= --with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri --with-dri-searchpath =/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri --enable-glx-tls --enable-shared-glapi --enable-texture-float --enable-xa --enable-driglx-direct --with-eg l-platforms=x11 drm --enable-gallium-llvm --with-gallium-drivers= nouveau r600 r300 svga swrast --enable-gles1 --enable-gles2 --enable-openvg --enable-gallium-egl --d isable-glu CFLAGS=-Wall -g -O2 CXXFLAGS=-Wall -g -O2 OpenGL renderer string: Gallium 0.4 on AMD JUNIPER OpenGL version string: 3.0 Mesa 9.1-devel OpenGL shading language version string: 1.30 Linux solis 3.6.0-rc6+ #2 SMP Wed Sep 19 11:56:23 CEST 2012 x86_64 GNU/Linux wheezy/sid llvm-3.1: Installed: 3.1-3~exp4 Candidate: 3.1-3~exp4 Version table: *** 3.1-3~exp4 0 501 http://ftp.pl.debian.org/debian/ experimental/main amd64 Packages 500 /var/lib/dpkg/status 3.1-2 0 501 http://ftp.pl.debian.org/debian/ unstable/main amd64 Packages 3.1-1 0 500 http://ftp.pl.debian.org/debian/ testing/main amd64 Packages torchlight: Installed: 1.0.20120924-1 Candidate: 1.0.20120924-1 Version table: *** 1.0.20120924-1 0 500 /var/lib/dpkg/status glxinfo |grep comp GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_combine, GL_ARB_texture_compression_rgtc, GL_ARB_texture_float, GL_ARB_texture_rectangle, GL_ATI_texture_compression_3dc, GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_rgtc, GL_EXT_texture_compression_latc, GL_EXT_texture_integer, GL_AMD_shader_stencil_export, GL_ARB_ES2_compatibility,
Apitrace: pastelink.me/dl/4d477e
This might be a bug in the game itself: Mesa: User error: GL_INVALID_OPERATION in glCompressedTexImage2D(invalid width or height for compression format) If so, it isn't clear to me why it doesn't happen on the proprietary drivers as well? More information here: http://forums.runicgames.com/viewtopic.php?f=24&t=34893 The bug should probably be reassigned to Mesa core as this seems to happen with all Mesa drivers.
Created attachment 67856 [details] [review] I'm so sorry for this thing. This patch hides problem with texture. It's a work in regress, do not use.
Created attachment 67879 [details] [review] I'm still so sorry for this thing. A little better patch. A hack.
Can you tell me what exactly are the parameters to glCompressedTexImage2D which cause this error?
In the thread linked from comment 2, the guy who ported Torchlight to Linux says that the actual call to glCompressedTexture2D() happens within the bowels of the OGRE 3D library and so the exact parameters aren't readily available without some kind of debugging/API-tracing tool. I'll see what I can do, if nobody else beats me to it, but in the interim here's what we do know: - Using Mesa-based GL drivers (that is, not the proprietary nVidia/ATI drivers), Torchlight always crashes when descending from dungeon-level 19 to dungeon level 20. - When it crashes, Ogre prints the message pasted in comment 0, naming mipmap 2 of "trail37.dds". - It turns out, trail37.dds is one of three textures (out of 2776 in the game) that have non-power-of-two dimensions. Specifically, it's 200x64 pixels. - trail37.dds is also S3TC-compressed (like all but 16 of the game's textures), which means its dimensions need to be a multiple of 4 in each direction. - The base texture is 200x64 pixels, which is fine. - Mipmap level 1 is 100x32 pixels, which is fine. - Mipmap level 2 is 50x16 pixels, but 50 is not a multiple of 4. mesa/main/teximage.c has specific code to return GL_INVALID_OPERATION if given dimensions that aren't a multiple of the compression algorithm's block-size, and the error message it includes is exactly the one seen if you start Torchlight with MESA_DEBUG=1 set. This is also consistent with the Ogre error that mentions mipmap 2. It's not immediately clear what Mesa *should* do when fed compressed texture data that isn't a multiple of the block-size, apart from 'not crash'. It looks like attachment 67879 [details] [review] opts for "quietly round the dimensions up to the nearest multiple of four", but that doesn't seem right - you'd wind up with 1-3 pixels of black (or gibberish, depending on how the compression works), at the edge of the texture. I notice Mesa already has some support for such textures: the error-detecting code in teximage.c actually tests "(width > bw && width % bw > 0)" so presumably a 1x3 or 2x4 texture would work just fine. Whatever Mesa does to clip off unwanted pixels when "width < bw", I guess it should do in the "width > bw" case as well.
(In reply to comment #6) > - Mipmap level 2 is 50x16 pixels, but 50 is not a multiple of 4. > mesa/main/teximage.c has specific code to return GL_INVALID_OPERATION if > given dimensions that aren't a multiple of the compression algorithm's > block-size, and the error message it includes is exactly the one seen if > you > start Torchlight with MESA_DEBUG=1 set. This is also consistent with the > Ogre > error that mentions mipmap 2. This looks like a bug in mesa to me. There is no such restriction in neither ARB_texture_compression nor EXT_texture_compression_s3tc. This restriction only applies to [Compressed]TexSubImage calls not the [Compressed]TexImage calls. Among others certainly because otherwise non-square mipmaps would always fail at some point. So I believe the right fix would be to simply drop that test (but don't drop it from the subimage paths) - silently rounding up should not be necessary, things like expectedSize calculations should do the right thing already.
(In reply to comment #7) > This looks like a bug in mesa to me. There is no such restriction in neither > ARB_texture_compression nor EXT_texture_compression_s3tc. This restriction > only applies to [Compressed]TexSubImage calls not the [Compressed]TexImage > calls. Among others certainly because otherwise non-square mipmaps would > always fail at some point. > So I believe the right fix would be to simply drop that test (but don't drop > it from the subimage paths) - silently rounding up should not be necessary, > things like expectedSize calculations should do the right thing already. Agreed. I'll post some patches soon.
The same bug occurs under Fedora 17/x86_64 (Mesa 8.0.4) and Torchlight 2012-09-26 which was posted on 30th September on the Humble Bundle site.
OK, should be fixed with commit df4a88ac4398ec4c152eb57a7129c07bb623edd7
Bug 55817 is probably also of interest to anyone cc'ed to this one.
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.