Hi all, I've put together a GLSL extension proposal at:
https://people.freedesktop.org/~imirkin/MESA_debug_operations.spec The situation this is trying to alleviate is the fact that it's an _enormous_ pain to actually execute shaders and collect results on any particular hardware without a surrounding driver to handle all the mundane bits. It's much easier to stick it into an already working driver, and basically pass a token to the shader compiler to do what it will. We've had numerous occasions in nouveau development whereby some instruction has a flag that we don't quite understand (or even a whole instruction). We could do one-off hacks to make the shader compiler "test it out", but it's tedious. This enables permanent infrastructure in mesa to pass such tokens through with enough parameters to be able to test anything. (Although I doubt it would ever be submitted for inclusion in the official KHR db.) Since this relies on careful interactions with shader compiler, what the debug ops really mean would need to be either baked in, or provided via env vars. The idea isn't to have anything checked in that would actually use this ext, but to enable driver developers with a simpler testing methodology. But you could have a glsl model of how an operation works and record any differences. Or you could just dump the results into a ssbo in a compute shader for offline analysis. It introduces an ALU-style op, texture, image, and memory. I think that covers it, except for interpolation, but I felt tackling that one would be unnecessarily complicated. And interpolation frequently involves bits outside of the shader as well in any case. I don't have an implementation for this yet, I wanted first to gather some feedback (and most importantly, any opposition) before doing any actual work on this. Cheers, -ilia _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
