| 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] O= land 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 Squadr= on, but I've found that while it does render (I wouldn't say that #98724 has be= en 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 executa= ble 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. Sourc= e is here: https://gith= ub.com/m64p/mupen64plus-GLideN64
| What | Removed | Added |
|---|---|---|
| Assignee | dri-devel@lists.freedesktop.org | reizemberk@gmail.com |
| 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 |
| What | Removed | Added |
|---|---|---|
| Summary | GLideN64 very slow on oland/radeonsi | GLideN64 very slow on r600/radeonsi |
Created attachment 136936 [detai=
ls]
glxinfo2
Upgraded Kernel, xserver-xorg, Mesa, etc.
The problem disappears with "LIBGL_ALWAYS_SOFTWARE=3D1" and in mo=
re older
versions of GLideN64 disappears with
"MESA_EXTENSION_OVERRIDE=3D-GL_ARB_buffer_storage"
| What | Removed | Added |
|---|---|---|
| Severity | major | enhancement |
| QA Contact | dri-devel@lists.freedesktop.org | reizemberk@gmail.com |
| Keywords | love | |
| Version | 17.2 | 17.3 |
| What | Removed | Added |
|---|---|---|
| URL | https://github.com/gonetz/GLideN64/issues/1561 |
| What | Removed | Added |
|---|---|---|
| QA Contact | reizemberk@gmail.com | dri-devel@lists.freedesktop.org |
| Resolution | --- | WONTFIX |
| Summary | GLideN64 very slow on r600/radeonsi | GLideN64 very slow on r600/radeonsi - GL_ARB_buffer_storage = bug |
| Status | NEW | RESOLVED |
| Keywords | love |
This problem is currently "solved" on the GLide64 s= ide. 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 b= ut 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 wor= ks perfect. The dangerous combination is GL_UNSIGNED_SHORT with GL_ARB_buffer_storage extension, that may end up destroying the hardware under the right conditio= ns. I quote myself: Sorry for the delay, but I had a "technical mishap" ...my video c= ard is DEAD, stone-dead. I am responsible for my unwise BIOS configuration (GART error reporting =3D Enabled + PCIE Spread Spectrum =3D 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 "stee= plechase 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.c= om/gonetz/GLideN64/issues/1561 https://bugs.freedesktop.org/show_bug.= cgi?id=3D105256 https://github.com= /gonetz/GLideN64/pull/1735 https://github.com= /gonetz/GLideN64/pull/1738 cya
Created attachment 138463 [detai=
ls]
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).
| What | Removed | Added |
|---|---|---|
| QA Contact | dri-devel@lists.freedesktop.org | mesa-dev@lists.freedesktop.org |
| Component | Drivers/Gallium/r600 | Mesa core |
| Severity | enhancement | normal |
| Priority | high | medium |
| Assignee | dri-devel@lists.freedesktop.org | mesa-dev@lists.freedesktop.org |