Created attachment 370372 [details] [diff] [review] Workarounds for Linux ATI fglrx crashes and bugs The Canvas 3D driver doesn't work with the fglrx drivers on Linux. The ATI fglrx driver doesn't say that it's compatible with pbuffers in the glx server and glx extension strings, so the Canvas 3D extension doesn't try to use the ATI driver. The client string does say that it supports pbuffers (and it actually does), so maybe we could just skip the server&extension checks and rely on LoadSymbols to catch the missing symbols? Disabling the checks makes Canvas 3D crash on fglrx drivers due to some subtle issues with their GLX implementation. In particular: 1. destroying the current pbuffer context causes a crash 2. switching between contexts with different Display* causes a crash 3. binding a second pbuffer to a context causes a crash 4. pbuffer contexts don't work before making a non-pbuffer context current (on R300 at least)
Created attachment 371163 [details] [diff] [review] GLX ATI fglrx workarounds Changes: - When resizing, put previous context in glXCreateNewContext share list to preserve textures, buffers and FBOs across resizes. - Use glXGetClientString to check fbconfig and pbuffer support as the MESA-based drivers have pbuffer only in GLX client extensions.
Comment on attachment 371163 [details] [diff] [review] GLX ATI fglrx workarounds So this is a bug in fglrx: 16:17 < ajax> the client extension list is the set of entrypoints that your libGL exposes. the server list is the set of extensions that the renderer you're using supports. the strict intersection is what you can actually use. 16:28 < vlad> with the DRI driver.. also advertises pbuffers only in client-side glx 16:29 < ajax> right, mesa's libgl has the entrypoints, but we don't have support for it in the server 16:29 < vlad> ok, so on the latter it's not supposed to work 16:30 < ajax> it _might_ work in fglrx anyway, but if it does it's a bug that they don't get the server extension list right So I don't want to change the code for the pbuffer check entirely, but I think we can check the vendor string and employ this workaround if we see ATI/fglrx.
Alright, I'll try and make the vendor string workaround. Also, we probably only need to check glXExtensionsString, as it's supposed to be the intersection of the server and client strings ( http://lists.freedesktop.org/archives/xorg/2006-December/020149.html )
Created attachment 372391 [details] [diff] [review] GLX ATI workarounds Using glXQueryExtensionsString for the ext check, skipping pbuffer check on vendor ATI.
I'm pretty sure this must be fixed now, since we don't do that pbuffer check anymore.