I have mixed feelings about this. Some transfers are implemented with pipe_context::blit instead of resource_copy_region, because MSAA resources should be downsampled in transfer_map and upsampled in transfer_unmap, so that ReadPixels and various fallbacks (CopyPixels, CopyTexSubImage, ...) work. If transfers were to honor the render condition, the blit (including resolve) must honor it too.
Adding a boolean flag to resource_copy_region and blit saying whether the render condition should be honored is preferable. This should keep the render-condition disabling in the driver as it is now. Trying to save/restore the render condition before/after all occurences of resource_copy_region and blit would be prone to regressions and it would also need much more work. Marek On Sat, Jun 15, 2013 at 12:01 AM, Roland Scheidegger <[email protected]> wrote: > Am 14.06.2013 19:49, schrieb [email protected]: >> From: Roland Scheidegger <[email protected]> >> >> 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
