Bug 91993

Created attachment 118241 [details]
Main menu rendered normally with GPU.

Created attachment 118242 [details]
Main menu rendered in software/CPU.

Created attachment 118243 [details]
Main menu rendered normally with GPU.

Didn't realise I needed to flag the content-type. Same image, but now it's marked as an image.

Also:

kernel version: linux 4.1.6-1 
xorg version: 1.17.2
llvm-libs version: 3.6.2-3

 Can't reproduce this with Debian version of astromenance neither with radeonsi or swrast - works fine here with that llvm+mesa version.

 Likely game bug or it need some patches on Arch, look at a Debian changelog there are some patching involved:

 http://metadata.ftp-master.debian.org/changelogs//contrib/a/astromenace/astromenace_1.3.2+repack-3_changelog

 Yeah either w32 version from site has broken rendering.

 But Debian patched version is all fine for me on both radeonsi or with Catalyst.

Created attachment 118248 [details] [review]
Patche for the game from the Debian package

I can reproduce this with openastromenace in Gentoo. fix_work_on_intel_videocards.patch from the debian package (attached) fixes the menu for me, but even the comment for the patch mentions that this is only a workaround and GL_ARB_texture_storage needs to be fixed in mesa.

 Hm and 2 years passed :( does that work on intel's current driver?

 Just checked Catalyst, does not complain with or without.

FWIW 19604d30e1351868f7f54847c91ffec7b3fcd27e fixes the crash (on intel), might also fix the graphical issues on radeonsi but not really sure.

It does not - at least for me the issue is unchanged with current Mesa git.

(In reply to Daniel Scharrer from comment #10)
> It does not - at least for me the issue is unchanged with current Mesa git.
Since it reportedly works with the "intel" debian patch, my guess would be there's another bug somewhere with handling (or creating) incomplete mip pyramids in case of immutable textures, which is apparently (at least for compressed textures) unusual enough that there's no piglit test for it, and no other app so far using it (as at least on intel, it was a guaranteed crash for 2+ years). That's just a shot in the dark though...

I am also affected by this bug, Gallium 0.4 on AMD HAWAII (DRM 2.43.0, LLVM 3.8.0), OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.0.2 (git-4c0b484) here.

It is quite painful as this is by far the best FOSS 3d scroll shooter around, for those interested, the homepage is here:
http://www.viewizard.com/astromenace/index_linux.php

download/build wiki here:
http://www.viewizard.com/download.php

sourcecode here:
http://sourceforge.net/p/openastromenace/code/HEAD/tree/

As I am running a 390X with Mesa 11.0.2 from git and had no problems before upgrading my card from a Radeon 6950 it is probably radeonsi related ?
Could someone please test this with some modern GCN hardware on latest Mesa to confirm ?

I've built Astromenace from source and couldn't reproduce this.

Here's a trace from the openastromenace version in Gentoo (1.3.2) that works with Catalyst but is broken with radeonsi git for me:

 http://constexpr.org/tmp/AstroMenace-radeonsi.trace.xz (49 MiB)

Can you reproduce it with that?

With the apitrace, I do see an obvious graphical glitch (looking slightly different than the attachment).

apitrace reports an error: api issue 1: FBO incomplete: no attachments [-1] in frame 0. I do not know whether this is related to the graphical glitch, but you should probably report it to AstroMenace in any case.

The bug is caused by the combination of a (technically correct, but unintentional) off-by-one problem in AstroMenace with a bug in the Mesa state tracker.

(Old versions of) AstroMenace use glTexStorage2D to create a texture with an incomplete mipmap pyramid (the 1x1 level is missing). This pyramid is not honored by the state tracker's implementation of glGenerateMipmap, which results in various broken textures.

Current versions of AstroMenace no longer have the off-by-one problem, which is why Marek could not reproduce the bug.

I'm working on a Piglit test and Mesa patch to fix the bug on our side.

I can confirm that updating and recompiling of the AstroMenace source (Version 1.3.3 svn build 140929 now) now fully fixed the problem for me \o/ (radeonsi, R390X here).

Thanks a lot to everyone helping with this !

I noticed though that the OpenGL Shading Language and Shadow Quality options in AstroMenace's Advanced Video Settings are not available (red), while the log shows no problems.
I do not remember if those settings could be activated in previous versions of the game though and if they are even implemented... maybe someone could also check that ?

Created attachment 119055 [details]
GLSL and Shadows not available on radeonsi with OpenGL 3.0, LLVM 3.6.2

(In reply to Nicolai Hähnle from comment #16)
> (Old versions of) AstroMenace use glTexStorage2D to create a texture with an
> incomplete mipmap pyramid (the 1x1 level is missing). This pyramid is not
> honored by the state tracker's implementation of glGenerateMipmap, which
> results in various broken textures.

Hmm I totally missed this when I fixed pretty much the same bug in mesa core mipgen code. I guess it's a real pity there's no piglit test for this...

(In reply to Roland Scheidegger from comment #20)
> Hmm I totally missed this when I fixed pretty much the same bug in mesa core
> mipgen code. I guess it's a real pity there's no piglit test for this...

Now there is :)

MC Return, as for these menu options: Since I don't think any features were _removed_ from the driver, this sounds like it's an AstroMenace bug if anything, so you should probably talk to their developers. In any case, that topic is separate and therefore does not belong into the discussion of this particular bug here. Thanks for your patience :)

The fix for this has been in Mesa master for a while now (rev 24c9088), let's mark this as resolved.