Created attachment 120580 [details] Xorg.0.log info System Environment: -------------------------- Mesa Regression: yes Failed Platform: HSW Bug detailed description: ----------------------------- Render error with black pictures when running Unigine-Heave_v4.0 pls refer to attached error picture and xorg.log It's mesa regression, by bisect, shows the first bad mesa commit is 5ead448. commit 5ead448719f39d27bfbf4cabf138324dfee34a4f Author: Marek Olšák <marek.olsak@amd.com> AuthorDate: Tue Jun 16 22:13:34 2015 +0200 Commit: Marek Olšák <marek.olsak@amd.com> CommitDate: Thu Jul 23 00:59:24 2015 +0200 drirc: drop support for Heaven 3.0, fixes tessellation in 4.0 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reproduce steps: --------------------------- 1. xinit& 2. gnome-session& 3. cd unigine-heaven-1.5.2/Unigine_Heaven-4.0/ 4. export LD_LIBRARY_PATH=bin/:$LD_LIBRARY_PATH 5. export force_glsl_extensions_warn=true export MESA_EXTENSION_OVERRIDE="-GL_ARB_sample_shading" 6. vblank_mode=0 ./bin/heaven_x64 -video_app opengl -data_path ../ -sound_app null -engine_config ../data/heaven_4.0.cfg -system_script heaven/unigine.cpp -video_mode -1 -video_fullscreen 1 -extern_define PHORONIX,RELEASE -video_width 1920 -video_height 1080
Created attachment 120581 [details] error pic
(In reply to ye.tian from comment #0) > Created attachment 120580 [details] > Xorg.0.log info > > System Environment: > -------------------------- > Mesa Regression: yes > Failed Platform: HSW > > Bug detailed description: > ----------------------------- > Render error with black pictures when running Unigine-Heave_v4.0 > pls refer to attached error picture and xorg.log Recently I was doing some benchmarking on older versions of mesa, and I found this problem. Having said so ... > > It's mesa regression, by bisect, shows the first bad mesa commit is 5ead448. > commit 5ead448719f39d27bfbf4cabf138324dfee34a4f ... not exactly on this commit. In any case, all seems to work fine using mesa. Doing a git bisect to see when this problem got solved, I found this commit: commit 4acf71c89b5ef5e2fe8c1a3d7ecf6031e191463c Author: Kenneth Graunke <kenneth@whitecape.org> Date: Mon Dec 28 14:20:28 2015 -0800 drirc: Disable ARB_blend_func_extended for Heaven 4.0/Valley 1.0. Unigine Heaven 4.0 and Valley 1.0 use dual color blending but don't specify which fragment shader output is which, so there's at best a 50/50 chance of us guessing it correctly. This is invalid. Unigine fixed this in 4.1 and 1.1 versions over a year and a half ago, but hasn't actually released them for whatever reason. So, add the workaround back so that it works for most people. Fixes Heaven 4.0/Valley 1.0 rendering on Ivybridge. For whatever reason, Broadwell worked. 4.1 and 1.1 have always worked. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92233 Reviewed-by: Marek Olšák <marek.olsak@amd.com> Cc: mesa-stable@lists.freedesktop.org So I will close this bug. I guess that RESOLVED:WORKSFORME is the proper status change.
I later reverted that workaround and did a better one that lets it actually use dual color blending: commit b3340cd32acf5935891f19833de0cfc500a93e0b Author: Kenneth Graunke <kenneth@whitecape.org> Date: Wed Jan 20 17:33:14 2016 -0800 i965: Implement a drirc workaround for broken dual color blending. OpenGL's dual color blending feature was specified so that an implementation could support both multiple render targets (MRT) and dual source blending. Fragment shader outputs specify both "location" (the render target number) and "index" (either color 0 or 1). I believe DirectX only has the notion of "location" - if using dual color blending, location 0 or 1 will specify the operands. If not, then location means the render target index. The two features can't be used together. As such, some applications mistakenly try to use <loc = 0, index = 0> and <loc = 1, index = 0> in a shader used for dual color blending with a single render target, rather than the correct <loc = 0, index = 0> and <loc = 0, index = 1>. In particular, Unigine Heaven 4.0 and Valley 1.0 suffer from this bug. Unigine is aware of the problem, and quickly developed a fix, but has not bothered to change the download link on their website to a working copy in over a year. People were still using the broken version and complaining. We tried working around this by disabling dual color blending, but that apparently hurts performance, and people were once again unhappy. On i965, dual source blending is achieved by using different framebuffer write messages than normal rendering. So, we have to compile different code for the two cases. We're not being pedantic: we actually have to know in order to function. Normally, dual source blending is detectable in the shader: if a shader has an output with index = 1, then it's meant for blending, not MRT. With the broken inputs, they're indistinguishable, so we can only tell by looking at the current GL state. This patch implements a new drirc workaround: export dual_color_blend_by_location=true which makes the i965 driver detect when OpenGL state is configured for dual source blending, and recompile the fragment shader to use the right messages. In that case, we allow either location = 1 or index = 1 to specify the second source for the blending equations. It also re-enables GL_ARB_blend_func_extended for Unigine. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92233 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.