Bug 88627

Created attachment 112543 [details]
bug screenshot1

Created attachment 112544 [details]
bug screenshot2

Created attachment 112545 [details]
bug screenshot3

please try installing package libtxc_dxtn

(In reply to Tapani Pälli from comment #4)
> please try installing package libtxc_dxtn

... and test again, for me it looks like you might be missing DXT texture format support which with Mesa is handled by and external package libtxc_dxtn.

I have already libtxc_dxtn on my system, I have checked all other games working fine. Terminal ouputs:

emamk@emamk-workstation-PC:~$ glxinfo | grep s3
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_filter_anisotropic, 
    GL_OES_EGL_image, GL_OES_read_format, GL_S3_s3tc
    GL_EXT_texture_compression_rgtc, GL_EXT_texture_compression_s3tc, 
    GL_OES_read_format, GL_S3_s3tc, GL_SGIS_generate_mipmap,

emamk@emamk-workstation-PC:~$ ldd /usr/lib/x86_64-linux-gnu/libtxc_dxtn.so 
        linux-vdso.so.1 =>  (0x00007ffffa481000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f57cf9ce000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f57cffc2000)

emamk@emamk-workstation-PC:~$ ldd /usr/lib/i386-linux-gnu/libtxc_dxtn.so 
        linux-gate.so.1 =>  (0xf770c000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf752b000)
        /lib/ld-linux.so.2 (0xf770e000)

Thanks for checking this, the reason for asking is that this game renders fine for me on IVB laptop using current Mesa master. I found 2 of the screenshot areas and I don't have black floor there. This could be Baytrail specific so I will try to get this tested on Baytrail.

Yep, I've reproduced the 'black floors' now on Bay Trail NUC running Mesa 10.5.0-devel (git-adc8cdf).

Created attachment 112697 [details]
another screenshot on baytrail

Okay I have tested this on Intel Haswell HD Graphics 4600 and the bug is not present, so this bug is exclusively related to Intel Bay Trail graphics.

(In reply to Md Imam Hossain from comment #10)
> Okay I have tested this on Intel Haswell HD Graphics 4600 and the bug is not
> present, so this bug is exclusively related to Intel Bay Trail graphics.

What was the Mesa version used in this test? I've reproduced this today on Haswell and confirmed that still works on IVB.

(In reply to Tapani Pälli from comment #11)
> (In reply to Md Imam Hossain from comment #10)
> > Okay I have tested this on Intel Haswell HD Graphics 4600 and the bug is not
> > present, so this bug is exclusively related to Intel Bay Trail graphics.
> 
> What was the Mesa version used in this test? I've reproduced this today on
> Haswell and confirmed that still works on IVB.

Fresh Kubuntu 14.10 install
Mesa 10.5.0-devel (git-9f5fee8 2015-01-26 utopic-oibaf-ppa)
Linux kernel version 3.16.0-23-generic

https://www.youtube.com/watch?v=Iy9yOp5Mm7w

Now game crashes when Mesa compiled with '--enable-debug' on HSW, I've filed a bug #89569 about it.

On BYT there are much more artifacts visible but no crash.

Just to confirm, this bug is still present in latest mesa git master

System:

Ubuntu 15.10
Mesa 11.2.0-devel (git-b476c58 2015-12-19)
Linux kernel version 4.2.0-22-generic

tested with latest Mesa, bug only seems to occur when I change the graphics settings from the default settings to something else and restart the game. If I do the touch default graphics settings or set everything to HIGH detail than bug does not occur.

System:

Ubuntu 15.10

Is there any chance you could create an apitrace?

I'll try to produce a trace today, IIRC this is Pygame and Unreal Engine 3 so could be problem in some other games as well .. not sure if I have anymore access to baytrail to test myself.

Confirm that this issue is reproducible when switching graphics mode from defaulut mode. And after restart grass surface is rendered as a black color. Issue is reproducible on the following platforms:
HSW, SKL, KBL, llvmpipe and AMD.

Shaders responsible for this render was found using qapitrace and frameretrace tools:
FS_c5d224633770824b77948abaa21ac7101f4da3d8.glsl
VS_7a5820722988a8a7897f64f28a35ba4cf47d4aac.glsl

It was found that PConstFloat uniform in a fragment shader is initialized differently for default graphics mode
and low fraphics mode:

Default graphics mode:
======================
PConstFloat[0]:  0.15516959130764008, 1.4687154293060303, 0.6459256410598755, 0.6465722322463989
PConstFloat[1]:  1.4499469995498657, -0.1571781486272812, -0.06912530213594437, -0.069194495677948
PConstFloat[2]:  0.0, 1.2643097639083862, -0.7589484453201294, -0.7597081661224365
PConstFloat[3]:  0.0017628404311835766, 0.0015916860429570079, -9.989959716796875, 3.970821853727102e-5
PConstFloat[4]:  0.0, 0.0, 0.0, 1.0
PConstFloat[5]:  1.0, 1.0, 0.0, 0.0
PConstFloat[6]:  0.5800891518592834, 0.3527241349220276, 0.0, 1.0
PConstFloat[7]:  0.4309230148792267, 0.3861844539642334, 0.29760390520095825, 1.0
PConstFloat[8]:  0.8999999761581421, 0.8999999761581421, 0.0, 0.0
PConstFloat[9]:  0.0, 0.0, 0.0, 1.0
PConstFloat[10]: 0.009999999776482582, 0.20000000298023224, 2.0, 0.20000000298023224
PConstFloat[11]: 2.0, 1.0, 0.0, 2.0
PConstFloat[12]: 0.20000000298023224, 0.0, 0.0, 0.0
PConstFloat[13]: 2.0, 1.2241312265396118, 0.5098317265510559, 0.0
PConstFloat[14]: -0.46666666865348816, 14.999999046325684, 2.0, 0.0
PConstFloat[15]: 0.20000000298023224, 0.0, 0.0, 0.0

Low graphics mode:
==================
PConstFloat[0]:  1.3075134754180908, -0.3961544334888458, -0.3926851153373718, -0.39307817816734314
PConstFloat[1]:  -0.645625650882721, -0.8022872805595398, -0.7952612638473511, -0.7960572838783264
PConstFloat[2]:  0.0, 1.7261825799942017, -0.4597381055355072, -0.4601982831954956
PConstFloat[3]:  -0.00077915407018736, -0.00024380529066547751, -9.989983558654785, 1.6511185094714165e-5
PConstFloat[4]:  0.0, 0.0, 0.0, 1.0
PConstFloat[5]:  1.0, 1.0, 0.0, 0.0
PConstFloat[6]:  0.5800891518592834, 0.3527241349220276, 0.0, 1.0
PConstFloat[7]:  0.4309230148792267, 0.3861844539642334, 0.29760390520095825, 1.0
PConstFloat[8]:  0.8999999761581421, 0.8999999761581421, 0.0, 0.0
PConstFloat[9]:  0.0, 0.0, 0.0, 1.0
PConstFloat[10]: 0.009999999776482582, 0.20000000298023224, 2.0, 0.20000000298023224
PConstFloat[11]: 2.0, 1.0, 0.0, 2.0
PConstFloat[12]: 0.20000000298023224, 0.0, 0.0, 0.0
PConstFloat[13]: 2.0, 1.2241312265396118, 0.5098317265510559, 0.0


Looks like PConstFloat[14] and PConstFloat[15] are not initialized explicitly for low graphics. Accordingly to the spec it is initialized to zeroes and this leads to wrong calculations in a fragment shader:

    Temporary0.a = (Temporary6.r + PConstFloat[14].r);
    Temporary0.a = (Temporary0.a * PConstFloat[14].g);
    Temporary0.a = clamp(Temporary0.a, 0.0, 1.0);
    Temporary0.a = (( log2( abs( Temporary0.a ) ) ) );
    Temporary0.a = (Temporary0.a * PConstFloat[14].b);


In the second line of the code above Temporary0.a is set to 0.0 because uniform PConstFloat[14] was not explicitly initialized. Then float log2(float x) is run with zero input parameter, that is why it returns NaN. In the further calculations NaN value from log2() is set to gl_FragData[0].rgb which leads to incorrect rendering of the ground.

This issue can be fixed by explicit initialization of PConstFloat[14] with the following values (used in default graphics mode):

PConstFloat[14]: -0.46666666865348816, 14.999999046325684, 2.0, 0.0


So, this bug is not related to Mesa.

Created attachment 140357 [details]
Fragment shader

Created attachment 140358 [details]
Vertex shader

Sounds like this isn't our bug, so I'm going to close it. Feel free to re-open if I misunderstood.