Summary: | [BISECTED] commit "r600g: use shader-based MSAA resolving when hw-based one cannot be used" crashes some games when R600_LLVM=1 with LLVM < 3.4 | ||
---|---|---|---|
Product: | Mesa | Reporter: | Alexandre Demers <alexandre.f.demers> |
Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | maraeo, tstellar, vljn |
Version: | git | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Alexandre Demers
2013-12-29 08:19:23 UTC
This also affects Awesomenauts, Bastion and Trine 2 in the games I own. A bit more info. Serious Sam 3 will launch and begin to load. However, once it has loaded, it crashes when the menu is about to appear and I can even hear a fraction of music before it happens. Marek, can I provide you with something specific? Anything about the shaders I could try to get (with and without R600_LLVM)? I suspect the llvm support for r600 class hardware needs to add support for some additional instructions, etc. that that patch uses. Vincent or Tom may be able to identify what's missing. The shaders are generated by this code: http://cgit.freedesktop.org/mesa/mesa/diff/src/gallium/auxiliary/util/u_simple_shaders.c?id=fc21098a95c8f7d0aadbfcc90cb2e9e78d1e2ef3 http://cgit.freedesktop.org/mesa/mesa/diff/src/gallium/auxiliary/util/u_simple_shaders.c?id=5a609fbcb5459fc5cac2e0361a405ea4b884325f There is nothing special except for the texel fetch instructions which read from MSAA textures. The shaders also contain float<->int and float<->unsigned conversions. I think the latter is not used with GLSL very often. (In reply to comment #3) > I suspect the llvm support for r600 class hardware needs to add support for > some additional instructions, etc. that that patch uses. Vincent or Tom may > be able to identify what's missing. I'm still using LLVM 3.3. I'll try with LLVM 3.4 later if possible just in case it works with that, since LLVM 3.4 has landed in the testing repositories of ArchLinux last night. That might be it. I think LLVM 3.3 doesn't support MSAA texture fetches on R600. Tested with LLVM 3.4 and it does crash. So LLVM 3.4 is required to support correctly the shader-based MSAA. Would there be a way to work around this issue if a user is using LLVM < 3.4? (In reply to comment #7) > Tested with LLVM 3.4 and it does crash. So LLVM 3.4 is required to support > correctly the shader-based MSAA. Would there be a way to work around this > issue if a user is using LLVM < 3.4? Did you mean "it doesn't crash"? (In reply to comment #8) > (In reply to comment #7) > > Tested with LLVM 3.4 and it does crash. So LLVM 3.4 is required to support > > correctly the shader-based MSAA. Would there be a way to work around this > > issue if a user is using LLVM < 3.4? > > Did you mean "it doesn't crash"? Yes, sorry. "... LLVM 3.4 and it doesn't crash." I've been testing with LLVM 3.4. While it doesn't crash anymore, there are some visual glitches. Do you want me to open a different bug about it? I'm closing this bug since it is fixed by using LLVM 3.4. But my question in comment 7 is still pending. (In reply to comment #7) > Tested with LLVM 3.4 and it does crash. So LLVM 3.4 is required to support > correctly the shader-based MSAA. Would there be a way to work around this > issue if a user is using LLVM < 3.4? The workaround would be to disable MSAA (and therefore GL 3 too) if the LLVM backend is enabled and the LLVM version is older than 3.4. Alternatively, LLVM 3.4 could be required as the minimum version on r600 and radeonsi, there are other bugs I remember only happens with 3.3. (In reply to comment #13) > Alternatively, LLVM 3.4 could be required as the minimum version on r600 and > radeonsi, there are other bugs I remember only happens with 3.3. Since LLVM 3.4 is officially out, I would go with this solution. Otherwise, could we wrap 696229523d919de15ebc25d0f475bf56d7dad4a9 code in a if (LLVM >= 3.4) kind of condition? No, the code would be too complex. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.