Created attachment 61869 [details]
day time rendered image 2

Created attachment 61870 [details]
night time rendered image 1

Created attachment 61871 [details]
night time rendered image 2

A bunch of errors also appear on the console when the app starts rendering night time.
Error sample:

GLShader::loadFragment(): error in "core/shaders/default/mesh/fragment_base_light_omni.shader" file
defines: UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_3D,USE_TEXTURE_ARRAY,USE_ALPHA_FADE,USE_REFLECTION,USE_DEFERRED,USE_PARALLAX,HAS_DEFERRED_COLOR,HAS_DEFERRED_NORMAL,HAS_DEFERRED_PARALLAX,USE_PHONG_RIM,USE_ENVIRONMENT,USE_NORMALIZATION,USE_DIRECTIONAL_LIGHTMAPS,USE_SCATTERING_FALLOFF,USE_SHADOW_KERNEL,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,USE_ARB_BLEND_FUNC_EXTENDED,HAS_ARB_DRAW_INSTANCED,BASE_LIGHT_OMNI,OMNI,SHADOW,PHONG_RIM,OVERLAY_0
0:629(18): error: syntax error, unexpected NEW_IDENTIFIER

Created attachment 61874 [details] [review]
[PATCH] st/mesa: expose "force_glsl_extensions_warn" option

I think attached patch might help. It allows to use less strict extension handling to workaround some unigine problems. You'll also need to set "force_glsl_extensions_warn" environment variable to "1" or "true" before running the app:

force_glsl_extensions_warn=1 ./heaven

I see this too on a similar setup:
Slackware-current
kernel 3.4-rc7

OpenGL renderer string: Gallium 0.4 on AMD RV670
OpenGL version string: 2.1 Mesa 8.1-devel
OpenGL shading language version string: 1.30

The patch from Vadim fixes the night-time scenes and the errors are away, but not the wrong rendering of the shadows.
I have the same wrong shadows in HoN too, disabling shadows fixes this.

I confirm that the patch doesn't help with the daylight scenes. They look the same.

It helped with night time scenes, just like the previous comment says.

(In reply to comment #6)
> I confirm that the patch doesn't help with the daylight scenes. They look the
> same.
> 
> It helped with night time scenes, just like the previous comment says.

The night time scenes should be fixed with the fixes from Bug 43477 .
You can test the fixes with current mesa git master or with the 9.0 branch.

What's up with the day time issue?
I can't reproduce this issue on my system:

Kernel 3.4
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 2.1 Mesa 9.1-devel (git-e81ee67)
OpenGL shading language version string: 1.30

Additionally I'm using MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_bit_encoding"
as workaround for Bug 53118 .

Created attachment 66925 [details]
OgreSampleBrowser - Shadows

Appears to be related.

I'd say it looks like a depth precision/bias issue, but I'm not sure.

I still have this problem with Mesa 9.2-devel (git-4deefd9)
( patched with:
 r600g: emit a ps partial flush after CP DMA
 r600g: enable CP DMA on r6xx (v3) )
The night times scenes work better with force_glsl_extensions_warn=true

I saw this problem with Unigine Heaven 3.0, Heroes of Newerth 3.0.3 (also 2.x) and Xonotic 0.6.0 .

I think the last one is interesting because it is under GPL and works fine if I just enable shadows from realtime world lights but shows the problem if I enable "Soft shadows" too. The tooltip of "Soft shadows" is:
[enables use of shadowmapping (depth texture sampling) instead of stencil shadow volumes, requires gl_fbo 1]
The problem in Xonotic can be seen only in a few places with dynamic world lightning, like some rooms with lava in level 6 and the lights behind some big fans in level 8.

HD3850 (RV670) AGP, kernel 3.8.0

Created attachment 80226 [details]
Xonotic with shadow mapping

Bug still present today in Mesa 9.2.0 (git-c754f7a), kernel 3.9.4.

I saw a similar glitch also in Brütal Legend, Stacking and Costume Quest, especially with ambient occlusion, so I suppose all the games using the Buddha engine from Double Fine are affected.


I think the bug title should be changed for the following reasons:

The black stripes problem isn't specific to Unigine but happens with at least 4 different engines: Unigine, Buddha, DarkPlaces and K2.

The 3 people who see the bug here all use an RV670.

There is a workaround for the wrong shaders in the night time scenes.

The black stripes problem seems related to shadows, because disabling them in Xonotic and Heroes of Newerth removes the stripes and disabling ambient occlusion in games using the Buddha engine reduces the stripes slightly.


So I propose to change the title to: Broken shadows on RV670

I'm not sure if it's just a problem with shadow mapping because even if using stencil shadow volumes works in Xonotic the screenshot posted by Micael of the OgreSampleBrowser exhibit a similar problem and the text: "Technique Stencil".


Could the output of any R600_DEBUG setting be useful?


Attached a screenshot of the bug in Xonotic.

Created attachment 80228 [details]
Xonotic with shadow mapping, sharp flavour

The black stripes in Xonotic can be soft or sharp.

Created attachment 80229 [details]
Xonotic with stencil shadow volumes

Stencil shadow volumes work in Xonotic, so you can see how the shadows should be.

Created attachment 80230 [details]
Xonotic without shadows from realtime world lights

Comparing this to the screenshot with stencil shadow volumes you can see which shadows are affected.

Is this still an issue with current Mesa?

(In reply to comment #14)
> Is this still an issue with current Mesa?

I no longer have access to the hardware, so I cannot confirm.

First off, please bear with me if I make some noobish mistakes. I just recently switched to Linux, and this is my first actual report I've made on a bug. This is also my first venture into the depths of the actual GPU hardware.

I have a Radeon HD3650 (RV635, non-mobility) card, and I can verify that the shadow stripes are still present. I don't play HoN, but I am playing the new S2 game, Strife, which uses the same engine. Setting shadows to lowest possible does accomplish the same as Off in HoN as mentioned above.

I'd like to point out that the stripes actually change in size depending on the variability of the setting. Medium shadows have about a 50/50 split of the dark stripe compared to the light stripe. High has mostly full shadows with a very little bit on the lighter stripe.

One last thing, and probably unrelated, but my card also seems to have problems with some transparent shaders, as well. In Strife, it's visible in the launcher quite easily.
http://i.imgur.com/17vq5In.jpg
This is with Shaders on Low. Higher settings result in worse corruption for this. The blue and green boxes seem to change depending on which part they're in. Green for the lightshaft/fog that runs across the center, as well as the gem glow in the top-left. Cyan/blue for the background lighting.

For the record, both of these problems render fine in software mode.

I'm using Xubuntu 14.04, with the obiaf ppa, if it helps, though I can say this issue is present in every version I've tried, including the default drivers on the original 14.04 disc, as well as some of the stuff I managed to get working from 13.10. Therefore, I can assume they're both not regressions, but just missing or otherwise not-fully-working implementations.

Just searching around, and found this:
https://bugs.freedesktop.org/show_bug.cgi?id=37296
Seems like this bug is similar, and possibly the same problem.

Oh, and before I forget, if anyone needs more info, or wants me to test something, I'm more than willing to help. However, in terms of applying/testing patches, I'd need some guidance since I've never done that before, so probably a how-to or whatever will be needed.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/410.