← Back to branch summary

~mmach/netext73/mesa-ryzen

« back to all changes in this revision

Viewing changes to docs/drivers/freedreno.rst

  • Committer: mmach
  • Date: 2023-11-02 21:31:35 UTC
  • Revision ID: netbit73@gmail.com-20231102213135-18d4tzh7tj0uz752
2023-11-02 22:11:57

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/drivers/freedreno.rst
42
42
    work and the clusters of registers for the state that hardware blocks use.
43
43
 
44
44
  CP
45
 
    Command Processor.  Reads the stream of statechanges and draw commands
 
45
    Command Processor.  Reads the stream of state changes and draw commands
46
46
    generated by the driver.
47
47
 
48
48
  PFP
165
165
tile), the SQE goes through the ``GROUP_ID``\s and for any with an update since
166
166
the last time they were executed, it executes the corresponding fragment.
167
167
 
168
 
Starting with a6xx, states can be taggged with whether they should be executed
 
168
Starting with a6xx, states can be tagged with whether they should be executed
169
169
at draw time for any of sysmem, binning, or tile rendering.  This allows a
170
170
single command stream to be generated which can be executed in any of the modes,
171
171
unlike pre-a6xx where we had to generate separate command lists for the binning
173
173
 
174
174
Note that this means that the generated draw state has to always update all of
175
175
the state you have chosen to pack into that ``GROUP_ID``, since any of your
176
 
previous statechanges in a previous draw state command may have been skipped.
 
176
previous state changes in a previous draw state command may have been skipped.
177
177
 
178
178
Pipelining (a6xx+)
179
179
^^^^^^^^^^^^^^^^^^
387
387
Note that, since all command streams get captured, it is easy to run the system
388
388
out of memory doing this, so you probably don't want to enable it during play of
389
389
a heavyweight game.  Instead, to capture a command stream within a game, you
390
 
probably want to cause a crash in the GPU during a farme of interest so that a
 
390
probably want to cause a crash in the GPU during a frame of interest so that a
391
391
single GPU core dump is generated.  Emitting ``0xdeadbeef`` in the CS should be
392
392
enough to cause a fault.
393
393
 
569
569
 
570
570
- After the breakpoint is reached each breadcrumb would require
571
571
  explicit ack from the user. This way it's possible to find
572
 
  the last packet which did't hang.
 
572
  the last packet which didn't hang.
573
573
 
574
574
- Find the packet in the decoded cmdstream.
575
575