This is just barely more pretty-printing than we previously had, but
at least it doesn't leave out unit states in the log.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is quite a bit of spam, but I think it's useful to have in a full
INTEL_DEBUG=batch dump. And a lot of this spam on glxgears is just
because we're awful at handling our constants :/
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The previous brw_state_dump output was rather useless -- last used
program per batch, and just the hex. Now we dump all programs (since
we don't know which were used), and disassemble them. But that's a
ton of spam, and usually when looking into program contents we use
INTEL_DEBUG={vs,wm,misc,other} and when looking into state updates we
use INTEL_DEBUG=batch, so this dump usually just massively clutters up
the output.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Now that we're using state base addresses for most things, we're less
interested in the absolute address of the state, and more in its
offset from the state base address (start of batchbuffer). Also,
reorder the printout so it looks more like the batchbuffer dump.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I want to make brw_state_dump.c handle more than just the last
statechange, so I want to keep track of what's in the batch state. By
using AUB file numbering for most of these packets, this may be
reusable for aub dumping.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will let me hang cached compiler structs off of the context
without having to worry about cleaning them up at destroy time.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There's no pretty way to avoid the overwriting of the src operands, so
just use a temporary destination and rely on the MOV optimization.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We were stomping over the source for the body of the LIT instruction
when doing the MOV of 1.0 to the uninteresting channels.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
From ARB_framebuffer_object:
If a buffer is specified in <mask> and does not exist in both the
read and draw framebuffers, the corresponding bit is silently
ignored.
Using GL_NONE as DataType of Z32_FLOAT_X24S8, not sure what I should put there.
The spec says the type is n/a.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
