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