2013-07-30 21:29:24 +01:00
|
|
|
<!--
|
|
|
|
|
|
|
|
|
|
============================================
|
|
|
|
|
Application bugs worked around in this file:
|
|
|
|
|
============================================
|
|
|
|
|
|
2015-06-16 21:13:34 +01:00
|
|
|
* Unigine Heaven 3.0 and older contain too many bugs and can't be supported
|
|
|
|
|
by drivers that want to be compliant.
|
|
|
|
|
|
2013-07-30 21:29:24 +01:00
|
|
|
* Various Unigine products don't use the #version and #extension GLSL
|
|
|
|
|
directives, meaning they only get GLSL 1.10 and no extensions for their
|
|
|
|
|
shaders.
|
|
|
|
|
Enabling all extensions for Unigine fixes most issues, but the GLSL version
|
|
|
|
|
is still 1.10.
|
|
|
|
|
|
2014-07-08 19:24:55 +01:00
|
|
|
* If ARB_sample_shading is supported, Unigine Heaven 4.0 and Valley 1.0 uses
|
|
|
|
|
an #extension directive in the middle of its shaders, which is illegal
|
|
|
|
|
in GLSL.
|
|
|
|
|
|
2013-07-30 21:29:24 +01:00
|
|
|
TODO: document the other workarounds.
|
|
|
|
|
|
|
|
|
|
-->
|
|
|
|
|
|
2012-01-25 22:22:03 +00:00
|
|
|
<driconf>
|
2013-07-30 21:29:22 +01:00
|
|
|
<!-- Please always enable app-specific workarounds for all drivers and
|
|
|
|
|
screens. -->
|
|
|
|
|
<device>
|
2012-03-20 22:43:42 +00:00
|
|
|
<application name="Unigine Sanctuary" executable="Sanctuary">
|
2012-01-25 22:22:03 +00:00
|
|
|
<option name="force_glsl_extensions_warn" value="true" />
|
2012-07-18 08:07:17 +01:00
|
|
|
<option name="disable_blend_func_extended" value="true" />
|
2017-01-05 21:06:35 +00:00
|
|
|
</application>
|
2013-07-30 21:29:24 +01:00
|
|
|
|
2012-03-20 22:43:42 +00:00
|
|
|
<application name="Unigine Tropics" executable="Tropics">
|
2012-01-30 21:30:53 +00:00
|
|
|
<option name="force_glsl_extensions_warn" value="true" />
|
2012-07-18 08:07:17 +01:00
|
|
|
<option name="disable_blend_func_extended" value="true" />
|
2017-01-05 21:06:35 +00:00
|
|
|
</application>
|
2013-07-30 21:29:24 +01:00
|
|
|
|
2012-03-20 22:43:42 +00:00
|
|
|
<application name="Unigine Heaven (32-bit)" executable="heaven_x86">
|
2014-07-08 19:24:55 +01:00
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
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>
2016-01-21 01:33:14 +00:00
|
|
|
<!-- remove dual_color_blend_by_location if 4.1 ever comes out -->
|
|
|
|
|
<option name="dual_color_blend_by_location" value="true" />
|
2017-01-05 21:06:35 +00:00
|
|
|
</application>
|
2013-07-30 21:29:24 +01:00
|
|
|
|
2012-03-20 22:43:42 +00:00
|
|
|
<application name="Unigine Heaven (64-bit)" executable="heaven_x64">
|
2014-07-08 19:24:55 +01:00
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
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>
2016-01-21 01:33:14 +00:00
|
|
|
<!-- remove dual_color_blend_by_location if 4.1 ever comes out -->
|
|
|
|
|
<option name="dual_color_blend_by_location" value="true" />
|
2017-01-05 21:06:35 +00:00
|
|
|
</application>
|
2014-07-08 19:24:55 +01:00
|
|
|
|
|
|
|
|
<application name="Unigine Valley (32-bit)" executable="valley_x86">
|
|
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
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>
2016-01-21 01:33:14 +00:00
|
|
|
<!-- remove dual_color_blend_by_location if 1.1 ever comes out -->
|
|
|
|
|
<option name="dual_color_blend_by_location" value="true" />
|
2017-01-05 21:06:35 +00:00
|
|
|
</application>
|
2014-07-08 19:24:55 +01:00
|
|
|
|
|
|
|
|
<application name="Unigine Valley (64-bit)" executable="valley_x64">
|
|
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
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>
2016-01-21 01:33:14 +00:00
|
|
|
<!-- remove dual_color_blend_by_location if 1.1 ever comes out -->
|
|
|
|
|
<option name="dual_color_blend_by_location" value="true" />
|
2017-01-05 21:06:35 +00:00
|
|
|
</application>
|
2013-07-30 21:29:24 +01:00
|
|
|
|
2012-07-19 09:40:24 +01:00
|
|
|
<application name="Unigine OilRush (32-bit)" executable="OilRush_x86">
|
|
|
|
|
<option name="disable_blend_func_extended" value="true" />
|
2015-08-12 17:48:22 +01:00
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
2017-01-05 21:06:35 +00:00
|
|
|
</application>
|
2013-07-30 21:29:24 +01:00
|
|
|
|
2012-07-19 09:40:24 +01:00
|
|
|
<application name="Unigine OilRush (64-bit)" executable="OilRush_x64">
|
|
|
|
|
<option name="disable_blend_func_extended" value="true" />
|
2015-08-12 17:48:22 +01:00
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
2017-01-05 21:06:35 +00:00
|
|
|
</application>
|
2013-07-30 21:29:24 +01:00
|
|
|
|
2012-12-06 00:36:06 +00:00
|
|
|
<application name="Savage 2" executable="savage2.bin">
|
|
|
|
|
<option name="disable_glsl_line_continuations" value="true" />
|
|
|
|
|
</application>
|
2013-07-30 21:29:24 +01:00
|
|
|
|
2013-03-30 00:29:52 +00:00
|
|
|
<application name="Topogun (32-bit)" executable="topogun32">
|
|
|
|
|
<option name="always_have_depth_buffer" value="true" />
|
|
|
|
|
</application>
|
2013-07-30 21:29:24 +01:00
|
|
|
|
2013-03-30 00:29:52 +00:00
|
|
|
<application name="Topogun (64-bit)" executable="topogun64">
|
|
|
|
|
<option name="always_have_depth_buffer" value="true" />
|
|
|
|
|
</application>
|
2014-12-08 18:43:09 +00:00
|
|
|
|
|
|
|
|
<application name="Dead Island" executable="DeadIslandGame">
|
|
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
|
|
|
|
</application>
|
2015-04-10 18:24:33 +01:00
|
|
|
|
|
|
|
|
<application name="Second Life" executable="do-not-directly-run-secondlife-bin">
|
|
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
|
|
|
|
</application>
|
2016-03-31 22:32:53 +01:00
|
|
|
|
|
|
|
|
<application name="Warsow (32-bit)" executable="warsow.i386">
|
|
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
|
|
|
|
</application>
|
|
|
|
|
|
|
|
|
|
<application name="Warsow (64-bit)" executable="warsow.x86_64">
|
|
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
|
|
|
|
</application>
|
2016-06-24 19:28:51 +01:00
|
|
|
|
|
|
|
|
<application name="Rust" executable="rust">
|
|
|
|
|
<option name="glsl_zero_init" value="true"/>
|
|
|
|
|
</application>
|
2017-01-07 13:38:23 +00:00
|
|
|
|
|
|
|
|
<application name="Divinity: Original Sin Enhanced Edition" executable="EoCApp">
|
|
|
|
|
<option name="allow_glsl_extension_directive_midshader" value="true" />
|
|
|
|
|
</application>
|
2017-02-14 15:18:25 +00:00
|
|
|
|
|
|
|
|
<application name="Worms W.M.D" executable="Worms W.M.Dx64">
|
|
|
|
|
<option name="allow_higher_compat_version" value="true" />
|
|
|
|
|
</application>
|
2017-02-14 15:18:26 +00:00
|
|
|
|
|
|
|
|
<application name="Crookz - The Big Heist" executable="Crookz">
|
|
|
|
|
<option name="allow_higher_compat_version" value="true" />
|
|
|
|
|
</application>
|
2012-01-25 22:22:03 +00:00
|
|
|
</device>
|
|
|
|
|
</driconf>
|
