Bug 44039

Summary: Mesa 7.12-devel implementation error: unexpected format 0x822e in _mesa_choose_tex_format()
Product: Mesa Reporter: Nikita <servissoft>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact:
Severity: blocker    
Priority: medium CC: b747xx
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 42993    
Attachments: wow log
glxinfo
eve log

Description Nikita 2011-12-21 21:59:53 UTC
Created attachment 54664 [details]
wow log

World of Warcraft crashed running in wine 1.3.35
Error #132 (0x85100084) Fatal Exception
Exception: 0xC0000094 (INT_DIVIDE_BY_ZERO) at 0073:7DAF0712
Comment 1 Brian Paul 2011-12-24 06:38:44 UTC
Can you run with gdb, set a breakpoint on _mesa_problem() and get a stack trace when this error is reported?

I don't know how this would be related to a divide by zero error.

Which driver are you using?
Comment 2 Mathieu Belanger 2012-01-14 17:55:32 UTC
Created attachment 55589 [details]
glxinfo

I have the same error

...
Mesa 8.0-devel implementation error: unexpected format 0x822e in _mesa_choose_tex_format()
Please report at bugs.freedesktop.org
...
wine: Unhandled division by zero at address 0xf7013ef2 (thread 000d)
crash!

OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile IntelĀ® GM45 Express Chipset 
OpenGL version string: 2.1 Mesa 8.0-devel (git-faa90ab)
OpenGL shading language version string: 1.20

Log attach.
Comment 3 Mathieu Belanger 2012-01-14 17:56:12 UTC
Created attachment 55590 [details]
eve log

Wine launching EVE-Online log.
Comment 4 Brian Paul 2012-01-16 08:10:51 UTC
OK, I think I see the problem.  I reproduced something similar with a piglit test.

I have a gen 4 i965 laptop.  If I compile with TEXTURE_FLOAT_ENABLED, glxinfo says GL_ARB_texture_float (and GL_ARB_texture_rg) is supported.  But internally, the ctx->TextureFormatSupported[MESA_FORMAT_RGBA_FLOAT32] entry is false (so is the R_FLOAT32 entry).

In texformat.c the switch case for GL_R32F (0x822e) reads:

      case GL_R32F:
	 RETURN_IF_SUPPORTED(MESA_FORMAT_R_FLOAT32);
	 RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT32);
	 break;

Neither the R_FLOAT32 nor RGBA_FLOAT32 formats are supported so we end up generating the error message in the bug title.

The solution is to add a few more tests:

      case GL_R32F:
	 RETURN_IF_SUPPORTED(MESA_FORMAT_R_FLOAT32);
	 RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT32);
	 RETURN_IF_SUPPORTED(MESA_FORMAT_R_FLOAT16);
	 RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT16);
	 break;

and use a 16-bit format if the 32-bit format is not supported.  We already do the same thing earlier in the function for the GL_RGBA_32F case, etc.

I'll write a patch for this.
Comment 5 Ian Romanick 2012-01-16 12:00:58 UTC
(In reply to comment #4)
> OK, I think I see the problem.  I reproduced something similar with a piglit
> test.
> 
> I have a gen 4 i965 laptop.  If I compile with TEXTURE_FLOAT_ENABLED, glxinfo
> says GL_ARB_texture_float (and GL_ARB_texture_rg) is supported.  But
> internally, the ctx->TextureFormatSupported[MESA_FORMAT_RGBA_FLOAT32] entry is
> false (so is the R_FLOAT32 entry).
> 
> In texformat.c the switch case for GL_R32F (0x822e) reads:
> 
>       case GL_R32F:
>      RETURN_IF_SUPPORTED(MESA_FORMAT_R_FLOAT32);
>      RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT32);
>      break;
> 
> Neither the R_FLOAT32 nor RGBA_FLOAT32 formats are supported so we end up
> generating the error message in the bug title.
> 
> The solution is to add a few more tests:
> 
>       case GL_R32F:
>      RETURN_IF_SUPPORTED(MESA_FORMAT_R_FLOAT32);
>      RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT32);
>      RETURN_IF_SUPPORTED(MESA_FORMAT_R_FLOAT16);
>      RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_FLOAT16);
>      break;

We didn't already do this because the OpenGL 3.0 spec requires that GL_R32F be 32-bit float.  Ken dug into this a bit, and the problem is that GEN4 can't do filtering on 32-bit float formats.  Our current thinking is to just disable GL_ARB_texture_float on GEN4 and GEN4.5.

We could maybe add this work-around, but we'd have to modify compute_version to only advertise 3.0 if the required FLOAT32 formats are supported.  Is that doable?

> and use a 16-bit format if the 32-bit format is not supported.  We already do
> the same thing earlier in the function for the GL_RGBA_32F case, etc.
> 
> I'll write a patch for this.
Comment 6 Roland Scheidegger 2012-01-16 12:57:26 UTC
(In reply to comment #5)
> We didn't already do this because the OpenGL 3.0 spec requires that GL_R32F be
> 32-bit float.  Ken dug into this a bit, and the problem is that GEN4 can't do
> filtering on 32-bit float formats.  Our current thinking is to just disable
> GL_ARB_texture_float on GEN4 and GEN4.5.
This seems a bit inconsequent since there's lots of the same format conversion for other formats (like ordinary rgba16), you just got lucky i965 doesn't hit them (presumably), but GL3 requires fixed size for them just as well.

> 
> We could maybe add this work-around, but we'd have to modify compute_version to
> only advertise 3.0 if the required FLOAT32 formats are supported.  Is that
> doable?
I think that would be a good solution, there's probably way more apps out there which want to use the float16 formats rather than the float32 formats, hence not advertizing texture_float just because your chip can't filter float32 seems a bit harsh. (Or if it doesn't support filtering, maybe just don't filter them? That won't be quite conformant neither certainly but I don't know if that's worse than using f16 instead, you'd think an app using f32 is doing that for a good reason.)
Comment 7 Brian Paul 2012-01-18 09:47:45 UTC
I've pushed the 16-bit float fallback work-around.  Commit 7628696004515074594d4fdac4e422c81c86b32c

Nikita, Mathieu: can you re-test with Mesa/master?
Comment 8 Ian Romanick 2012-01-26 18:33:12 UTC
Closing as FIXED.  Please reopen if the problem persists.

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.