| Bug ID | 102358 |
|---|---|
| Summary | WarThunder freezes always with vblanc=3D1 |
| Product | Mesa |
| Version | git |
| Hardware | Other |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | haro41@gmx.de |
| QA Contact | dri-devel@lists.freedesktop.org |
On latest mesa git (17.3-dev) WarThunder freezes with vsync ac= tivated. The main problem:=20 a system consumes significantly more power (+90W in my case), with vsync deactivated. Switching back to mesa 17.2-rc5 or disabling vsync (vblanc=3D0), are soluti= ons to make it work, atm. Here my system specs: (glxinfo |grep OpenGL) OpenGL vendor string: X.Org OpenGL renderer string: AMD Radeon (TM) R9 380 Series (TONGA / DRM 3.19.0 / 4.13.0-rc5+, LLVM 6.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-devel (git-46a8c4ef81) OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 17.3.0-devel (git-46a8c4ef81) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.3.0-devel (git-46a8c4ef81) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions:
| What | Removed | Added |
|---|---|---|
| Summary | WarThunder freezes always with vblanc=3D1 | WarThunder freezes always with vblank_mode=3D2 |
| What | Removed | Added |
|---|---|---|
| Summary | WarThunder freezes always with vblank_mode=3D2 | WarThunder freezes at start, with activated vsync (vblank_mo= de=3D2) |
Can you bisect which Mesa Git commit introduced the issue?
Yes, i did it via 'git bisect'. Here is the first related commit: d5ba75f8881f0869dc16f71f7395514c0a35b6e2 is the first bad commit commit d5ba75f8881f0869dc16f71f7395514c0a35b6e2 Author: Thomas Hellstrom <t= hellstrom@vmware.com> Date: Tue Jun 20 19:24:34 2017 +0200 st/dri2 Plumb the flush_swapbuffer functionality through to dri3 Implement the state tracker manager drawable interface flush_swapbuffer method by plumbing it through to dri3 if available. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Marek Ol=C5=A1=C3=A1k <marek.olsak@amd.com> Reviewed-by: Brian Paul <br= ianp@vmware.com> Reviewed-by: Sinclair Yeh <sy= eh@vmware.com> :040000 040000 8df730d2ac95b42435c96043da0eb6fba5f6861c 4179b3bb9a075169627eb00de5780bbbe8abea02 M src I hope it makes sense and can help you.
| What | Removed | Added |
|---|---|---|
| CC | thellstrom@vmware.com |
Thomas, any ideas? (In reply to haro41 from comment #2= ) > Yes, i did it via 'git bisect'. Thanks. Any chance you can get a backtrace[0] of the hanging process? [0] Ideally of all threads, something like "thread apply all bt full&q= uot; in gdb.
Created attachment 13371=
9 [details]
gdb all tread backtrace
This looks odd.=20 That commit actually only adds a wait for all swaps to be scheduled at glFinish(), so it shouldn't really be causing any grief unless the server somehow forgets to send the right events or the dri3 wait_for_sbc is broken= ...
BTW: ... setting environment variable LIBGL_DRI3_DISABLE (to switch back to DRI2) fixes the freeze too ...
Created attachment 133771 [details] [review] Patch to see if there might be a race causing this @haro41: Could you test the attached dri3_mutex.diff and see if there i= s a change in behaviour?
@Thomas, i got two rejects when trying to apply the patch. Let me sync to your base version first, to avoid additional diffs, where/when did you branch exactly?
| What | Removed | Added |
|---|---|---|
| Attachment #133771 is obsolete | 1 |
Created attachment 133776 [details] [review] Replacement patch to see if there is a race causing this.
(In reply to haro41 from comment #8) > @Thomas, >=20 > i got two rejects when trying to apply the patch. >=20 > Let me sync to your base version first, to avoid additional diffs, > where/when did you branch exactly? My mistake. Added a new patch based on 0cc4c7e3.
i applied your patch successful, still the freezes, maybe in a=
verage a bit
later now.
The behavoir changed a bit:
before patch:
vblank_mode=3D2 (default)-> always freezes inside 0..2 minutes runtime,=
=20
framerate fix/clamped at 50(as expected)
vblank_mode=3D0 -> no freezes at all, dynamic, high framerates=
=20
LIBGL_DRI3_DISABLE=3D1 -> no freezes at all, framerate fix at 50=20
after patch:
vblank_mode=3D2 (default)-> always freezes inside 0..2 minutes runtime,=
=20
framerate fix/clamped at 100(!!)
vblank_mode=3D0 -> no freezes at all, dynamic, high framerates=
=20
LIBGL_DRI3_DISABLE=3D1 -> no freezes at all, framerate fix at 50=20
To be honest, i am not familiar enough with DRM internals to understand what
exactly happens here, but it looks like something is broken in respect to D=
RI 3
usage.
Somehow i think i could be the only one with this freezes and to ensure i am
not wasting your time:
Can you give me a hint, where i should look first to exclude it is something
specific to my system/setup?
(In reply to haro41 from comment #11) > i applied your patch successful, still the freez= es, maybe in average a bit > later now. >=20 > The behavoir changed a bit: >=20 > before patch: >=20 > vblank_mode=3D2 (default)-> always freezes inside 0..2 minutes runt= ime,=20 > framerate fix/clamped at 50(as expected) > vblank_mode=3D0 -> no freezes at all, dynamic, high framer= ates=20 > LIBGL_DRI3_DISABLE=3D1 -> no freezes at all, framerate fix at 50= =20 >=20 >=20 > after patch: >=20 > vblank_mode=3D2 (default)-> always freezes inside 0..2 minutes runt= ime,=20 > framerate fix/clamped at 100(!!) > vblank_mode=3D0 -> no freezes at all, dynamic, high framer= ates=20 > LIBGL_DRI3_DISABLE=3D1 -> no freezes at all, framerate fix at 50= =20 >=20 >=20 > To be honest, i am not familiar enough with DRM internals to understan= d what > exactly happens here, but it looks like something is broken in respect= to > DRI 3 usage. >=20 > Somehow i think i could be the only one with this freezes and to ensur= e i am > not wasting your time: > Can you give me a hint, where i should look first to exclude it is som= ething > specific to my system/setup? That's really weird :). Actually I don't think anything's wrong with your setup, but rather that there's a multithreading bug in dri3 or the app. There's no concurrency protection at all in the dri3 client and I'm not sure that's correct. I thi= nk you're the only one seeing this possibly perhaps because you're the first to try it with a heavily multithreaded application. Anyway, I'm OK with commenting out the glFinish() wait for swapbuffers until someone has the possibility to debug this thoroughly. Unfortunately WarThun= der doesn't run on vmware's svga driver (yet) due to bugs... It would also be good to try to rule out server side radeon dri3 problems. Perhaps by running it on nouveau or intel...
(In reply to Thomas Hellstr=C3=B6m from comment #12) > It would also be good to try to rule out server = side radeon dri3 problems. > Perhaps by running it on nouveau or intel... Or simply the modesetting Xorg driver. A server-side issue could be in the xserver Present code used by all drivers though.
... i found this related and interesting blog: https://keithp.com/blogs/= DRM-lease-4/ Seems there is something WIP in respect to DRM synchronisation and this very bug.
DRM leases have nothing to do with this issue. Have you got a chance to test if this also happens with the Xorg modesetting driver?
@Michel,
i did just now, but WarThunder freeze behavoir didn't really change.
xorg.conf:
Section "Device"
Identifier "AMD"
Driver "modesetting"
EndSection
DRI 3 is used per default too (X.Org X Server 1.19.3).
BTW:=20
i have tested with my older pitcairn (HD7870), trying amdgpu and radeon ker=
nel
driver. The behavoir is the same as with tonga in both cases.
FWIW, I got it running under dri3/vsync with the svga driver w= ith no apparent issue. It also runs fine with modesetting/svga although there is no true vsync sin= ce the kernel module flips pages instantly.
What happens if you run in windowed mode + vsync?
@Thomas, i get freezes in windowed mode with activated vsync too (tried with latest git).