| 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 |
Comment # 4
on bug 102204
from H4nN1baL
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
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
