hi. Does provided apitrace display the issue? I watched your video, and then apitrace - they look different (in the video red threangle over the targets, and in the apitrace - purple treangle over your character).

Could you please point exact issue in apitrace?

Sorry, my description should be more clear. On the apitrace, there are significant differences between what Intel and AMD GPU shows. There are two images that show what happens on them:

Intel HD Graphics 520: https://cdn.discordapp.com/attachments/234032525297582081/452632355753033729/IntelHd520.png

AMD Radeon HD 5450: https://cdn.discordapp.com/attachments/234032525297582081/452632462015594506/AMDRadeonHD5450.png

Notice the lines around the portal, they may blink for a instant in Intel HD Graphics 520, when they should circle it all the time, as it happens on Windows and using the AMD GPU.

Is there any additional information I could provide to improve this bug report?

I tested your trace with Kabylake (very similar to your 520 part) and the trace looked like the picture you posted for radeon.  I tested with Mesa 18.0 and 18.2-devel

The circles rotated around the portal with no blinking.

Thank you for your quick answer. I took some time to answer because I was rebuilding Mesa to test. Unfortunately it did not work, the lights around the portal still do not appear properly. Below there are some details:

Build configuration, based on what Ubuntu uses to build Mesa:

./autogen.sh --prefix=/usr/local/mesa --enable-dri --with-dri-drivers=i915,i965,swrast \
--with-vulkan-drivers=intel --enable-libglvnd --enable-osmesa --enable-glx-tls \
--enable-shared-glapi --enable-xvmc --disable-omx-bellagio \
--enable-driglx-direct --enable-gbm --enable-dri3 --with-platforms=x11,surfaceless,drm \
--enable-xa --enable-llvm --enable-opencl --enable-opencl-icd ac_cv_path_LLVM_CONFIG=llvm-config-6.0 \
--enable-vdpau --enable-va --enable-gallium-extra-hud --enable-lmsensors --with-gallium-drivers=i915,svga,swrast \
--enable-gles1 --enable-gles2 --enable-nine CFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall" \
CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" CXXFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall" \
FCFLAGS="-g -O2 -fstack-protector-strong" FFLAGS="-g -O2  -fstack-protector-strong" \
GCJFLAGS="-g -O2 -fstack-protector-strong" LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro" \
OBJCFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security" \
OBJCXXFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security"

The glxinfo -B output:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) x86/MMX/SSE2 (0x1916)
    Version: 18.2.0
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) x86/MMX/SSE2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.0-devel (git-f8e54d02f7)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 18.2.0-devel (git-f8e54d02f7)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.2.0-devel (git-f8e54d02f7)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Hi!
>>>Notice the lines around the portal, they may blink for a instant in Intel HD Graphics 520, when they should circle it all the time, as it happens on Windows and using the AMD GPU.

Thanks a lot for clarification. I reproduced and bisected the issue to the first "bad" commit.

_____________________________________________________________
aaaa22c775f484922ccac705de41dd892e2aff4d is the first bad commit
commit aaaa22c775f484922ccac705de41dd892e2aff4d
Author: Jordan Justen <jordan.l.justen@intel.com>
Date: Mon Apr 25 16:09:21 2016 -0700

vbo: Return INVALID_OPERATION during draw with a mapped buffer

Fixes the OpenGLES 3.1 CTS:

    ESEXT-CTS.draw_elements_base_vertex_tests.invalid_mapped_bos

Because this is triggering the error message after the normal API
validation phase, we don't have the API function name available, and
therefore we generate an error message without the draw call name:

Mesa: User error: GL_INVALID_OPERATION in draw call (vertex buffers are mapped)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95142
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

oh, forgot to mention. Issue was checked and reproduced on SKL and KBL laptops.

Actually it is an expected behavior here because the game calls draw functions when buffer is mapped and according to spec it is an incorrect behavior:

Section 6.3.2 of the GL 4.5 spec says: 

"Any GL command which attempts to read from, write to, or change the state of a buffer object may generate an INVALID_OPERATION error if all or part of the buffer object is mapped ... However, only commands which explicitly describe this error are required to do so. If an error is not generated, such commands will have undefined results and may result in GL interruption or termination."

But actually the Mesa already has an feature/ability to allow such behavior:

Commit 	e401cfa28a6e32d7081f9de998e731965ce966fb:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=e401cfa28a6e32d7081f9de998e731965ce966fb

>i965: Allow mapped VBOs during drawing in non-debug contexts.


This option will be enabled automatically only for non-debug contexts.
But unfortunately Game creates context with flag GLX_CONTEXT_FLAGS_ARB=GLX_CONTEXT_DEBUG_BIT_ARB and the Game is unable to use this feature/ability and as far as I researched the mesa source code there is no way to force Mesa to enable it.

as we found out that it is not mesa issue, this ticket may be closed.
Also, I sent email to support@tomoshibi.NET with kind request to add the fix into the game.

I'm commenting to say I solved the issue. It wasn't a Mesa bug, it wasn't a game bug, it was also not a bug, it was a feature. A Wine feature.

Wine was creating the debug context somehow. Setting the environment variable:

WINEDEBUG="-all"

Solved the problem. It's strange that Wine created debug contexts as I set nothing related to Wine debug and, as I had set no debug option, I expected there would be no debug context and never suspected of that.

All effects are appearing correctly, the game is running perfectly and I'm very happy.

Thank you.