Comme=
nt # 14
on bug 10173=
9
from Krystian Ga=C5=82aj
(In reply to Gregor M=C3=BCnch from comment #10)
> Some comments from a VP dev:
> https://www.gamingonlinux.com/articles/the-linux-beta-of-arm=
a-3-has-been-
> updated-to-180-compatible-with-windows-again-for-a-time.11349/
> comment_id=3D118838
>=20
> Seems to be that it's not clear if the bug is on Mesa or VPs side. May=
be
> some Mesa dev could comment.
I am not sure what we could do on VP side to work around the bug. It happen=
s in
a single execution of fragment shader on a multisampled color buffer and de=
pth
buffer. The same execution is writing a color value, and it's supposed to w=
rite
a depth value into the corresponding sample of depth buffer. I don't know of
any additional keywords in GLSL that we could specify to make sure this is =
the
case. If anyone knows about something we're specifying wrong, please advise.
As for rendering techniques used, we are only converting the rendering
technique used by the original Arma 3 developer team from Direct3D API to
OpenGL. So one way of working around the problem would be to ask them to do=
LOD
switching in another way in future release - and then we could port that new
version. But since it's not happening on the same graphics cards on Windows=
or
Mac, only on Linux, it isn't likely this rework would be given any high
priority. And we are good at API knowledge and conversion between them, but
inventing another technique to swap in for existing technique in not our ga=
me
requires slightly different approach, and, above all, good knowledge of the
entire complicated rendering engine used in the game, so as not to break
anything.
I don't think that working around the problem is a good thing to mention in=
a
bug ticket... this thing might be happening in other games, maybe not so hi=
gh
profile, so it would make sense to fix it in driver. It can be done, if it's
working on the same cards using Windows drivers...