[Mesa-dev] RFC: more changes to render_condition

[Roland Scheidegger]

Am 14.06.2013 19:49, schrieb sroland at vmware.com:
> From: Roland Scheidegger <sroland at vmware.com>
> 
> For conditional rendering this makes it possible to skip rendering
> if either the predicate is true or false, as supported by d3d10
> (in fact previously it was sort of implied skip rendering if predicate
> is false for occlusion predicate, and true for so_overflow predicate).
> There's no cap bit for this as presumably all drivers could do it trivially
> (but this patch does not implement it for the drivers using true
> hw predicates, nvxx, r600, radeonsi, no change is expected for OpenGL
> functionality).
> ---


FWIW there's some more changes which would be useful but they are probably
more controversial and may require some more thought so here it goes:


diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst
index ede89be..59403de 100644
--- a/src/gallium/docs/source/context.rst
+++ b/src/gallium/docs/source/context.rst
@@ -385,7 +385,8 @@ A drawing command can be skipped depending on the outcome of a query
 (typically an occlusion query, or streamout overflow predicate).
 The ``render_condition`` function specifies the query which should be checked
 prior to rendering anything. Functions honoring render_condition include
-(and are limited to) draw_vbo, clear, clear_render_target, clear_depth_stencil.
+(and are limited to) draw_vbo, clear, clear_render_target, clear_depth_stencil,
+resource_copy_region. Transfers may also be affected.

 If ``render_condition`` is called with ``query`` = NULL, conditional
 rendering is disabled and drawing takes place normally.
@@ -545,6 +546,13 @@ These flags control the behavior of a transfer object.
   Written ranges will be notified later with :ref:`transfer_flush_region`.
   Cannot be used with ``PIPE_TRANSFER_READ``.

+``PIPE_TRANSFER_HONOR_RENDER_CONDITION``
+  The transfer will honor the current render condition. This is only valid
+  essentially for ``transfer_inline_write`` (but since everyone implements
+  this with a fallback to ordinary transfer_map/transfer_unmap it is valid
+  for transfer_map too, however the same restriction apply, the transfer
+  must be write-only with either DISCARD_RANGE or DISCARD_WHOLE_RESOURCE set).
+

The reasoning for this is that d3d10 has CopyResource/CopySubResource
and UpdateSubResource predicated.
For resource_copy_region if it always honors render_condition,
then state trackers not wanting this can simply disable predication
when they call it. But the opposite is not possible, if it never
honors predication, then a state tracker needing predication will
need to wait on the predicate, hence requiring a cpu/gpu sync (if
the result isn't available yet).
For transfers this is a bit weird I admit it essentially implies
a predicated gpu blit from a staging texture (if you implement this
fully on hardware). If that's too awkward though this one could be
emulated in the state tracker easily enough, if resource_copy_region
honors predication (by just creating a temporary texture and doing
a predicated resource_copy_region), which is probably cleaner from
a API perspective.

Roland