The game is sometimes rendering trees. It has multiple tree me=
sh models, and
when the tree gets close, the game is switching between different LODs/mode=
ls
by rendering both models overlapping on a grid of pixels, as if checkerboar=
d,
pixels of old LOD in black fields of it, new one in white.
As long as it=E2=80=99s doing that using single-sampled buffers as render t=
argets, all
is fine. However in higher quality modes, the game switches to multisampled
buffers. When using multisampled buffers, if ATOC is turned on in settings,=
the
game is using alpha-to-coverage technique without polygon sorting to make s=
ure
that the grass is rendered correctly. At the same time it=E2=80=99s using d=
epth test
and depth write to fill up the depth buffer. In the same execution of fragm=
ent
shader it sets the output color and alpha value, and the depth buffer value,
and it expects the alpha value to cause the color value to end up only in s=
ome
samples of multisampled texture, and - the important bit - the depth value =
to
end up only in the corresponding samples of the depth buffer.
This technique works on DX11 on Windows, on all drivers on Mac OS X, and on
NVidia drivers on Linux, but on Mesa Radeonsi drivers on Linux it makes the
rendering go bad, rendering most of the tree pixels white until the LOD
transition ends.
The white is visible on the screen because it is the initial color of the
multisampled render target, and for some reason this color is allowed to le=
ak
through, which means that in some cases the depth buffer value is set, when=
the
corresponding color buffer value isn=E2=80=99t.
Both depth and color buffer have the same number of samples (8), and were
created with fixedSamples =3D true in OpenGL call.
It looks as if the depth buffer values in case of Mesa Radeonsi driver were:
- correctly not written when the depth test fails for the fragment shader,
- correctly written to all samples of the depth buffer when alpha coverage
directs the draw to fill them all, but
- INCORRECTLY assigned not only to those samples to which alpha coverage
directed the fragment output color, but either to all the samples in depth
buffer, or to samples in depth buffer that don=E2=80=99t correspond to the =
samples in
color attachment buffer.
We encountered the same issue in 2015 in fglrx drivers, contacted AMD team
about it, and received confirmation that it is a bug, and that it was fixed.
Unfortunately, shortly after that fglrx drivers went out of use.
The issue can be easily reproduced in Arma 3 by:
- launching Arma 3 game,
- switching to High quality or higher to turn on multisampled buffers,
- enabling ATOC (alpha to coverage) in Video settings, or making sure it's
enabled,
- launching first level of Drawdown 2035 campaign, ie. starting a new
campaign, bypassing optional tutorial, and observing as the main character
walks into the base, the bushes flicker white from time to time as they get
closer.
The issue is present in Mesa 17.2.0-devel from padoka PPA, on at least Rade=
on
R7 260X/360.