lee/renderdoc
1
0
Fork 0
mirror of https://github.com/baldurk/renderdoc.git synced 2026-07-29 19:01:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

Rename 'draw' or 'drawcall' to action

Browse Source 
* There's not a good accepted terminology for this kind of event, and for
  historical reasons 'drawcall' has been the accepted term, even though
  that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
  $draw() includes draws and dispatches, but $dispatch() only includes
  dispatches, it's hard to intuitively understand why $draw() matches all
  of these calls.
* As a result we've defined the term 'action' to cover these types of
  events in the same way that we defined 'event' in the first place to
  mean a single atomic API call.
This commit is contained in:
baldurk
2021-07-01 15:15:05 +01:00
parent e7785bd99e
commit 7149302680
283 changed files with 5374 additions and 5320 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/python_api/examples/renderdoc/fetch_counters.rst
+4 -4
View File
@@ -1,7 +1,7 @@
Fetch GPU Counter Data
======================
In this example we will gather GPU counter data over a capture and find any drawcalls that completely failed the depth/stencil test.
In this example we will gather GPU counter data over a capture and find any actions that completely failed the depth/stencil test.
The first thing we do is enumerate a list of counters that the implementation supports using :py:meth:`~renderdoc.ReplayController.EnumerateCounters`. A few of these counters values are statically known - see :py:class:`~renderdoc.GPUCounter`. If you know which counter you want ahead of time you can continue straight away by calling :py:meth:`~renderdoc.ReplayController.FetchCounters` with a list of counters to sample from, or :py:meth:`~renderdoc.ReplayController.DescribeCounter` to obtain a :py:class:`~renderdoc.CounterDescription` of the counter itself:
@@ -34,7 +34,7 @@ However we will also print all available counters. If the implementation support
print(" %s" % desc.description)
print(" Returns %d byte %s, representing %s" % (desc.resultByteWidth, desc.resultType, desc.unit))
Once we have the list of :py:class:`~renderdoc.CounterResult` from sampling the specified counters, each result returned is for one counter on one event. Since we only fetched one counter we can simply iterate over the results looking up the drawcall for each. For actual draws (excluding clears and markers etc) we use the counter description to determine the data payload size, and get the value out. Interpreting this can either happen based on the description, or in our case we know that this counter returns a simple value we can check:
Once we have the list of :py:class:`~renderdoc.CounterResult` from sampling the specified counters, each result returned is for one counter on one event. Since we only fetched one counter we can simply iterate over the results looking up the action for each. For actual draws (excluding clears and markers etc) we use the counter description to determine the data payload size, and get the value out. Interpreting this can either happen based on the description, or in our case we know that this counter returns a simple value we can check:
.. highlight:: python
.. code:: python
@@ -42,10 +42,10 @@ Once we have the list of :py:class:`~renderdoc.CounterResult` from sampling the
# Look in the results for any draws with 0 samples written - this is an indication
# that if a lot of draws appear then culling could be better.
for r in results:
draw = draws[r.eventId]
draw = actions[r.eventId]
# Only care about draws, not about clears and other misc events
if not (draw.flags & rd.DrawFlags.Drawcall):
if not (draw.flags & rd.ActionFlags.Drawcall):
continue
if samplesPassedDesc.resultByteWidth == 4: