https://bugs.freedesktop.org/show_bug.cgi?id=102204
Bug ID: 102204 Summary: GLideN64 very slow on oland/radeonsi Product: Mesa Version: 17.1 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: aaronbpaden@gmail.com QA Contact: dri-devel@lists.freedesktop.org
I'm using: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340] Mesa: 17.1.6 Linux: 4.12.6
This is somewhat related to #98724.
I decided to give GLideN64 another try since it now works with Rogue Squadron, but I've found that while it does render (I wouldn't say that #98724 has been fixed. I just think that GLideN64/GLupeN64 no longer use glDrawElementsIndirect) it's still unplayably slow. The Windows drivers do work fine on the same hardware.
For this test, I was using the prebuilt and configured version found here: https://m64p.github.io/ the executable is mupen64plus-gui. Because of #97226 it has to be launched from the terminal.
The download link doesn't work with HTTPS Everywhere for some reason. Source is here: https://github.com/m64p/mupen64plus-GLideN64
https://bugs.freedesktop.org/show_bug.cgi?id=102204
H4nN1baL reizemberk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|dri-devel@lists.freedesktop |reizemberk@gmail.com |.org |
--- Comment #1 from H4nN1baL reizemberk@gmail.com --- Created attachment 136888 --> https://bugs.freedesktop.org/attachment.cgi?id=136888&action=edit glxinfo
https://bugs.freedesktop.org/show_bug.cgi?id=102204
H4nN1baL reizemberk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|17.1 |17.2 OS|All |Linux (All) Component|Drivers/Gallium/radeonsi |Drivers/Gallium/r600 Assignee|reizemberk@gmail.com |dri-devel@lists.freedesktop | |.org Severity|normal |major Hardware|Other |x86-64 (AMD64) Priority|medium |high
https://bugs.freedesktop.org/show_bug.cgi?id=102204
H4nN1baL reizemberk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|GLideN64 very slow on |GLideN64 very slow on |oland/radeonsi |r600/radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=102204
--- Comment #3 from H4nN1baL reizemberk@gmail.com --- Created attachment 136936 --> https://bugs.freedesktop.org/attachment.cgi?id=136936&action=edit glxinfo2
Upgraded Kernel, xserver-xorg, Mesa, etc.
The problem disappears with "LIBGL_ALWAYS_SOFTWARE=1" and in more older versions of GLideN64 disappears with "MESA_EXTENSION_OVERRIDE=-GL_ARB_buffer_storage"
https://bugs.freedesktop.org/show_bug.cgi?id=102204
H4nN1baL reizemberk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |enhancement QA Contact|dri-devel@lists.freedesktop |reizemberk@gmail.com |.org | Keywords| |love Version|17.2 |17.3
https://bugs.freedesktop.org/show_bug.cgi?id=102204
H4nN1baL reizemberk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://github.com/gonetz/G | |LideN64/issues/1561
https://bugs.freedesktop.org/show_bug.cgi?id=102204
H4nN1baL reizemberk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- QA Contact|reizemberk@gmail.com |dri-devel@lists.freedesktop | |.org Resolution|--- |WONTFIX Summary|GLideN64 very slow on |GLideN64 very slow on |r600/radeonsi |r600/radeonsi - | |GL_ARB_buffer_storage bug Status|NEW |RESOLVED Keywords|love |
--- Comment #4 from H4nN1baL reizemberk@gmail.com --- This problem is currently "solved" on the GLide64 side. But it reveals a serious problem with GL_ARB_buffer_storage extension. GL_UNSIGNED_BYTE with GL_ARB_buffer_storage extension it's extremely slow. GL_UNSIGNED_SHORT with GL_ARB_buffer_storage extension is a little better but is still slow. GL_UNSIGNED_BYTE without GL_ARB_buffer_storage is faster, but not work at full speed. GL_UNSIGNED_SHORT without GL_ARB_buffer_storage works perfect.
The dangerous combination is GL_UNSIGNED_SHORT with GL_ARB_buffer_storage extension, that may end up destroying the hardware under the right conditions.
I quote myself:
Sorry for the delay, but I had a "technical mishap" ...my video card is DEAD, stone-dead. I am responsible for my unwise BIOS configuration (GART error reporting = Enabled + PCIE Spread Spectrum = Auto) and "pushing stress" on GPU to render at non-standard resolutions (monitor 1080p to 120Hz (max 144Hz), mupen64plus windowed to 1400x1050) using a buggy extension like some kind of "steeplechase generator" for benchmarking. Well, I reaped what I sowed.
Original post there: https://github.com/gonetz/GLideN64/pull/1738#issuecomment-369848827
Full history: https://github.com/gonetz/GLideN64/issues/1561 https://bugs.freedesktop.org/show_bug.cgi?id=105256 https://github.com/gonetz/GLideN64/pull/1735 https://github.com/gonetz/GLideN64/pull/1738
cya
https://bugs.freedesktop.org/show_bug.cgi?id=102204
--- Comment #5 from H4nN1baL reizemberk@gmail.com --- Created attachment 138463 --> https://bugs.freedesktop.org/attachment.cgi?id=138463&action=edit glxinfo3
This problem persist even on amdgpu (MSI Radeon RX 560 AERO ITX 4G OC). The problem not exist using nouveau (Gigabyte NVIDIA GeForce 210 GPU - GV-N210D3-1GI).
https://bugs.freedesktop.org/show_bug.cgi?id=102204
H4nN1baL reizemberk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org |org Component|Drivers/Gallium/r600 |Mesa core Severity|enhancement |normal Priority|high |medium Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org |org
dri-devel@lists.freedesktop.org