Am 14.06.2013 19:49, schrieb srol...@vmware.com: > From: Roland Scheidegger <srol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
