A V3D_DEBUG=clif file from a non-texturing .shader_test can now be
successfully run through the CLIF runner in the simulator. Now I need to
build an open source CLIF runner against the v3d DRM module.
We need to dump each buffer's contents in order for a CLIF file, so we
need to collect all of the relocs into a buffer (such as the indirect CL
full of both uniforms and GL shader states) before we start dumping.
These will match the names that the CLIF parser expects to see. I may in
the future decide to change more of the other names so that I match the
names the HW/closed SW team uses for their packets, rather than the names
in the spec (which only they and I can read anyway).
A few of the upcoming changes would make the V3D_DEBUG=cl output less
readable, so let's make proper CLIF file production be under a separate
V3D_DEBUG=clif flag.
By default after saying you are emitting a buffer, it'll expect a buffer
size. Once you set a format, it'll keep parsing that format until you
announce something else.
With CLIFs, the parser will choose an address for the buffer being
created, so we need to use effectively relocations to buffers instead of
the addresses that the driver uses. This is also a whole lot more
intelligible for console output than raw addresses!
To generate CLIF files that the v3dv3 simulator can parse, we're going to
need to decode addresses, and for that we'll need the vaddr lookup
function from the clif structure from within v3d_decoder.
The HW will halt when you hit a HALT packet, or when you hit the end
address. Tell CLIF if there's an end address is so that it can stop
correctly. (There was usually a 0 byte after the CL, so it would stop
anyway).
This will be usable with "VC5_DEBUG=cl" on the vc5 driver to stream a CLIF
file (the Broadcom equivalent of i965's AUB) to stderr. I haven't tested
that this is actually usable with the internal CLIF-consuming tools, but
is close enough as a baseline and is useful for visually inspecting the
command stream.
