Bug 75664

Created attachment 94955 [details]
screenshot

There's already a bug 71591 about allowing (some) extension declarations in middle of shader.  After that is allowed (there are Mesa patches for that), both Unigine tests run [1].

However, Valley benchmark is still lacking most of lightning.  That can be worked around by running it with:
MESA_EXTENSION_OVERRIDE="-GL_ARB_blend_func_extended" MESA_GL_VERSION_OVERRIDE=3.2 ./valley

If one specifies some other Mesa version, there are GL enum errors and lightning doesn't work.  Without blend override, there aren't error messages, but lightning doesn't work either, regardless of specif Mesa. I.e. there might be some bug in Mesa GL_ARB_blend_func_extended implementation.


[1] If you don't patch Mesa to allow extension declarations in middle of shaders, you need to add "-GL_ARB_sample_shading" to MESA_EXTENSION_OVERRIDE.

The missing lighting is due to a bug in Unigine's dual source blending code.  They enable two source blending, label both outputs as color 0, and never specify color 1.  We could guess, but we'd have a 50/50 chance of getting it right.  I attempted to report that to Unigine today; we'll see what happens though.

In the meanwhile, maybe appropriate workarounds could be added to Mesa drirc also for Valley?


As to other issues with these demos, If I enable MSAA, I get a lot of these warnings from Heaven & Valley:
----------
GLFrameBuffer::enable(): incomplete attachment
GLFrameBuffer::enable(): incomplete attachment
GLFrameBuffer::enable(): incomplete attachment
GLFrameBuffer::enable(): incomplete attachment
GLFrameBuffer::enable(): incomplete attachment
OpenGL error: invalid framebuffer operation
----------

And once:
  UserArray::push(): bad array index 4

On quick look, I don't see a visual problem in the demos though.


Whereas enabling MSAA for Tropics or Sanctuary demo completely breaks them with Mesa.  I get lots of these errors:
-------------
0:165(89): error: bit-wise operations are forbidden in GLSL 1.10 (GLSL 1.30 or GLSL ES 3.00 required)
GLShader::loadFragment(): error in "core/shaders/meshes/fragment_leaf_ambient.shader" file
-------------

Trying to force indicated GLSL version or disabling bit encoding with Mesa environment variables to work around the issue doesn't have any effect on it.

I experience the same bug on a same GPU (Ivybridge HD Graphics 4000) and Mesa 10.2.1... CPU is Core i7-3635QM, Unigine Valley and Heaven don't work - they show white picture instead, and they show the same error log.

I've read comments and I find strange that these apps work on r600 and radeonsi cards with the same Mesa (tested both myself)... Do r600/radeonsi cards have a workaround for that bug or do they use a different shader compiler? O_oo

Yes, Gallium drivers have quite different shader compiler code from classic Mesa side.

Blend function issue will be fixed in next version of Valley, it's a bug in the demo.  If  you don't want to work around the demo bugs with environment variables, you have also an option to patch Mesa:
http://cgit.freedesktop.org/~kwg/mesa/log/?h=unigine

(There are also patches floating around for allowing extension declarations elsewhere in shader source, but they seem to get fairly quickly out of date, and AFAIK they won't get merged into Mesa until Khronos GL specs have been changed accordingly.  See e.g. patch mentioned in bug 71591.)

(In reply to comment #6)
> Yes, Gallium drivers have quite different shader compiler code from classic
> Mesa side.

The front end of the compiler (the only part that sees the GLSL code from the application) is the same for all Mesa drivers.  The difference is the Gallium drivers that are not affected by this issue do not expose GL_ARB_sample_shading... so the Unigine demos don't try to enable it in the middle of the shader.

> Blend function issue will be fixed in next version of Valley, it's a bug in
> the demo.  If  you don't want to work around the demo bugs with environment
> variables, you have also an option to patch Mesa:
> http://cgit.freedesktop.org/~kwg/mesa/log/?h=unigine
> 
> (There are also patches floating around for allowing extension declarations
> elsewhere in shader source, but they seem to get fairly quickly out of date,
> and AFAIK they won't get merged into Mesa until Khronos GL specs have been
> changed accordingly.  See e.g. patch mentioned in bug 71591.)

Allowing extensions in the middle of the shader will NOT be made the default in Mesa.  Khronos decided (wisely, IMO) that the spec is correct as-is.  At least one vendor vowed to fix his implementation.  I posted a bit more explanation in another bug related to this issue... or perhaps it was on the mesa-dev mailing list.

Code has landed in Mesa to enable a driconf option for this, and Ken has a patch on the mesa-dev list to enable this driconf option in the i965 driver:

http://lists.freedesktop.org/archives/mesa-dev/2014-August/065134.html

This patch should land any time now.

The workarounds are upstream.  You do need a new ~/.drirc or /etc/drirc - I would just copy the one from src/mesa/drivers/dri/common/drirc.  It's also installed by "make install", so if you aren't getting it in your distro packages, you should file a bug with your distribution.

We can all hope that Unigine fixes this in the future.