ValveSoftware
Crash Dump: Material System Related Crash
As Bruce said it was fine to do this occasionally, here is a crash dump from an internal Source location that we can't debug.
The hl2.exe minidump: estranged_materialsystem_crash_minidump.dmp
Pre-Requisites
- A ps30 shader
- Code that passes a variable to a constant register in that shader above 32 (in our case, we have a ps30 version of LightmappedGeneric that we need to pass 10 extra constants to, so we can do some pretty phong stuff @AniCator wrote).
Steps to Reproduce
- Load up the game with the pixel shader loaded, and the constants being sent through. Our code to do that looks like the below, in the
DYNAMIC_STATEsection insidelightmappedgeneric_dx9_helper.cpp:
DynamicCmdsOut.SetPixelShaderConstant(32, lightInfo[0].Base(), 10);
- Open the console, and run
mat_reloadallmaterials, or alternatively do something that tries to shutdown the material system, like closing the game.
Result
Boom!
Additional Information
The constants above 32 are passed ok to the shader before the crash, and the shader is able to use the (in our case, light) data without any problems.
When we change the line that passes the number to a number below 32, (and so we don't overlap past 32 with the total slots), like this:
DynamicCmdsOut.SetPixelShaderConstant(31, lightInfo[0].Base(), 1);
..it works ok, and doesn't crash with a reload. So it's just when we try and fill up constants above 32 - which should be fine, because with ps30 shaders apparently you can get up to 224.
This also worked in 2007, and our code is a direct port from the 2007 version. As we don't have the 2013 source for LightmappedGeneric, we had to use the 2007 shader / helper.cpp's - but we haven't seen any other issues (aside from mega rendering bugs on Mac). But that's a separate issue. But, it does mean that this could be an issue with the new GL stuff in Source... or just that our code is very broken :)
We got around this by using the 5 or so free constants in the ps20b version of LightmappedGeneric. Since this is for a really specific problem that probably won't be beneficial to anyone else, I'm closing this issue.
What does mat_info report in your case? I could see this happening if the material system wasn't in SM3 mode to begin with.
Here's the dump from that command on my machine: http://paste.ubuntu.com/6275939/
I'm re-opening this - we now need to use pixel shader constants above 32.
As discussed above, mat_info returns m_NumPixelShaderConstants: 32 on all systems tested with mat_dxlevel 95 and pixel shader 3.0 support - this appears to be incorrect, and is likely responsible for the crash.
Results from various branches of Source, this should help track it down:
- CS:GO: http://paste.ubuntu.com/6820493/
m_NumPixelShaderConstants: 224 - Portal 2: http://paste.ubuntu.com/6820441/
m_NumPixelShaderConstants: 224 - Left 4 Dead 2: http://paste.ubuntu.com/6820453/
m_NumPixelShaderConstants: 224 - Left 4 Dead 1: http://paste.ubuntu.com/6820464/
m_NumPixelShaderConstants: 224 - Alien Swarm: http://paste.ubuntu.com/6820488/
m_NumPixelShaderConstants: 224 - TF2, HL2, SDK 2013: http://paste.ubuntu.com/6820470/
m_NumPixelShaderConstants: 32
The multiple hardware configurations we've tested this on are capable of SM 5.0, and DirectX 11 - this is an engine limit, rather than a physical hardware one, and it's now limiting us in terms of what we can do with shaders in Estranged.
Thank you.
