[Mesa-dev] Proposal: MESA_debug_operations

[Ilia Mirkin]

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