Since Catalyst 13.8 beta we've been getting many bug reports about crashes in Second Life on AMD GPUs using recent drivers. I've spent a few days trying to track down the issue and I've come up empty -- all the usual methods of narrowing down the source of the problem have failed and the crashes don't seem to be related to anything in particular that the application is doing. Rolling back to Catalyst 13.4 resolves the issue.
Is there a way to get more clarity on exactly where the driver is crashing?
It's usually underneath a call to glDrawRangeElements, and always an access violation near NULL (eg " Access violation reading location 0x0000002c.")
The callstack is always deep in atioglxx.dll:
|[Frames below may be incorrect and/or missing, no symbols loaded for atioglxx.dll]|
|>||secondlife-bin.exe!LLVertexBuffer::drawRange(unsigned int mode, unsigned int start, unsigned int end, unsigned int count, unsigned int indices_offset) Line 763||C++|
|secondlife-bin.exe!LLRenderPass::pushBatch(LLDrawInfo & params, unsigned int mask, int texture, int batch_textures) Line 510||C++|
Related SL forum discussion:
Resolved: Fix was to use glGenTextures and glDeleteTextures instead of having the application manage its own GL texture names.
After running under a debug, core profile context, I got errors about using texture names that hadn't been returned by glGenTextures (our application manages its own GL texture names to avoid frame stalls from glGenTextures on certain drivers). Apparently that option has been deprecated for some time now, but there were no side effects until around Catalyst 13.8.