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?

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.

Created attachment 55590 [details]
eve log

Wine launching EVE-Online log.

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.

(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.

(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.)

I've pushed the 16-bit float fallback work-around.  Commit 7628696004515074594d4fdac4e422c81c86b32c

Nikita, Mathieu: can you re-test with Mesa/master?

Closing as FIXED.  Please reopen if the problem persists.