| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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).
|
|
|
|
|
|
| |
This matches what CLIF parsing expects, and makes
TILE_BINNING_MODE_CONFIGURATION_COMMON_CONFIGURATION into a much more
legible TILE_BINNING_MODE_CFG_COMMON.
|
|
|
|
|
|
| |
The CLIF format expects american english spelling, and the rest of Mesa is
too. I was previously adhering to the spec's spelling, which is
counterproductive.
|
|
|
|
| |
This makes us match up with the V3D HW team's names a bit more.
|
|
|
|
| |
The parser doesn't handle float input, so we have to dump the raw value.
|
|
|
|
|
| |
The struct field names aren't part of the CLIF ABI, just the order of
fields within the struct. The comments are there for human readability.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
V3D only has one of these (the top 16 bits of a float32) left in its CLs,
but VC4 had many more. This gets us proper pretty-printing of the values
instead of a large uint.
|
|
|
|
|
| |
Reported-by: Rob Clark <[email protected]>
Fixes: e92959c4e03c ("v3d: Pass the whole clif_dump structure to v3d_print_group().")
|
|
|
|
|
| |
The parser doesn't expect them, so our fields would end up mismatched.
They're not really useful in console output, either.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Previously, we emitted in XML order, which I happen to type in the
decreasing offset order of the specifications. However, the CLIF parser
wants increasing offsets.
|
|
|
|
|
|
|
| |
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!
|
|
|
|
|
| |
The parser wants to see a 1 or 0. We can put "true" and "false" in a
comment to clarify that it's a boolean and the parser will skip it.
|
|
|
|
| |
Now all the printing happens from the same worklist processing.
|
|
|
|
|
| |
The clif dumper is going to need information about all of our BOs if we're
going to dump them for replay purposes.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
This reflects a change on the HW/closed SW side to drop this unused HW.
With it dropped on their side, the CLIF parser no longer expects to find
VG fields.
|
|
|
|
| |
This lets the comments be ignored by the CLIF parser.
|
|
|
|
|
| |
That's what a user should want to see, and what the CLIF parser wants.
This should maybe be generalized.
|
|
|
|
|
|
|
| |
This is controlled by a new nir_shader_compiler_options flag, and fixes
dEQP-GLES3.functional.shaders.builtin_variable.pointcoord on V3D.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python 2 has a range() function which returns a list, and an xrange()
one which returns an iterator.
Python 3 lost the function returning a list, and renamed the function
returning an iterator as range().
As a result, using range() makes the scripts compatible with both Python
versions 2 and 3.
Signed-off-by: Mathieu Bridon <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We can do one per instruction, and we have to be careful not to overwrite
raddr_b, but this greatly reduces the pressure on uniform loads
(particularly around ldvpm/stvpm instructions).
total instructions in shared programs: 90768 -> 88220 (-2.81%)
instructions in affected programs: 82711 -> 80163 (-3.08%)
|
|
|
|
|
|
| |
Sometimes when iterating over sources, we might want to check if it's the
implicit one. We wouldn't want to match on a non-implicit src using this
function.
|
|
|
|
|
|
| |
shader-db:
total instructions in shared programs: 91275 -> 90768 (-0.56%)
instructions in affected programs: 20702 -> 20195 (-2.45%)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These instructions let us write directly to the phys regfile, instead of
just R4. That lets us avoid moving out of R4 to avoid conflicting with
other SFU results, and to avoid conflicting with thread switches.
There is still an extra instruction of latency, which is not represented
in the scheduler at the moment. If you use the result before it's ready,
the QPU will just stall, unlike the magic R4 mode where you'd read the
previous value. That means that the following shader-db results aren't
quite representative (since we now cause some stalls instead of emitting
nops), but they're impressive enough that I'm happy with the change.
total instructions in shared programs: 95669 -> 91275 (-4.59%)
instructions in affected programs: 82590 -> 78196 (-5.32%)
|
|
|
|
|
| |
These instructions allow writing the result to any register, instead of a
special writeback to r4.
|
|
|
|
|
| |
Noticed while trying to sort a new op into the appropriate place to match
the documentation.
|
|
|
|
|
| |
If we fail initial disassembly, it's good to know what instruction it was
that failed.
|
|
|
|
| |
We lower saturates in NIR.
|
|
|
|
|
|
|
|
|
|
|
| |
Similarly to VC4's implementation, by not picking r0 immediately upon
freeing it, we give the scheduler more of a chance to fit later writes in
earlier. I'm not clear on whether there's any real cost to picking phys
over accumulators, so keep that behavior for now.
shader-db:
total instructions in shared programs: 96831 -> 95669 (-1.20%)
instructions in affected programs: 77254 -> 76092 (-1.50%)
|
|
|
|
|
|
|
|
|
| |
This restriction existed in V3D 2.x, but lifting it was a major change in
3.x.
shader-db results:
total instructions in shared programs: 98117 -> 96831 (-1.31%)
instructions in affected programs: 48520 -> 47234 (-2.65%)
|
|
|
|
|
| |
I keep having to ignore these shader-db changes since I don't trust them,
so just disable the reports entirely.
|
|
|
|
|
|
|
|
| |
total instructions in shared programs: 98578 -> 98119 (-0.47%)
instructions in affected programs: 27571 -> 27112 (-1.66%)
and it also eliminates most spills/fills on the CTS's randomized uniform
usage testcases.
|
|
|
|
| |
The docs had an update noting this restriction, so reflect it in the code.
|
|
|
|
|
| |
This doesn't affect us yet since we're not doing TMUWTs, but I think we
will for GLES 3.1.
|
|
|
|
|
| |
Fixes a bunch of piglit interpolation tests, and reduces my concern about
some MSAA blit shaders with noperspective varyings.
|
|
|
|
|
|
| |
We weren't using the field yet, so it didn't affect anything.
Fixes: c0476d964abb ("v3d: Express dithering mode in the same way that the CLIF parser does.")
|
|
|
|
| |
Fixes piglit ext_framebuffer_multisample-draw-buffers-alpha-to-one
|
|
|
|
|
| |
We don't actually set the two flags together, but I want to use the
r/g/b/a reordered fields in the next commit.
|
|
|
|
|
| |
This fixes GPU hangs on 7278 in transform feedback tests such as
GTF-GLES3.gtf.GL3Tests.transform_feedback2.transform_feedback2_basic
|
|
|
|
| |
It doesn't depend on V3D_VER, since it's just calling v3d_print_group.
|
|
|
|
|
| |
Noticed when trying to CLIF parse a transform feedback job that hangs on
HW.
|
| |
|
|
|
|
|
|
| |
We were overlapping it with the threadable/nan flags, resulting in
incorrect relocations (threadable/nan included in the offset) and wrong
ordering in the CLIF files.
|
|
|
|
|
| |
It looks like we don't need this flag for anything (not that I'm clear on
what it does), but it makes our struct dumping line up with CLIF parsing.
|