Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Bypass glDetachShader and glDeleteShader when dumping state #89
Follow issue 78:
Due to a driver bug, I recreate glCreateShaderProgramv in my application but I keep the part that delete/detach the shader part. Unfortunately apitrace isn't able anymore to retrieve shader code source
I think, it would be better to bypass glDetachShader and glDeleteShader too in dumping state.
I'm on the fence for this one.
glDetachShader and glDeleteShader are used a lot. My concern is that, by not freeing shaders, shader names will never be reused, therefore shader names will be very different from the trace file, causing bugs/confusion when dumping state.
Probably the only way to fix this would be to keep a cache of the source when dumping state.
I try to implement a shader cache: https://github.com/gregory38/apitrace/tree/separate-shader_V2
As you can see, I add a new flag (attached to glLinkProgram). The function that cache the source is a duplicate of dumpProgram without JSon stuff. I implement the cache as a map: Program->ShaderMap.
Code can potentially be extended to glCreateShaderProgramv, in this case the shader string must be build from the call parameters.
Sorry for not taking action all this time. I was reluctant between both solutions: the complexity of a shader cache, vs the shader leak/renumbering.
But I have good news: it's not necessary to skip glDeleteShader. Skipping glDetachShader suffices.
And by not skipping glDeleteShader, my concern of shaders being massively renumbered no longer applies. Shaders are still deleted, but merely their desctruction is deferred until the program gets deleted.
So I'll take you'r original patch. And modify it to only skip glDetachShader.