[Mesa-dev] RFC: more changes to render_condition

[Marek Olšák]

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 <sroland at vmware.com> wrote:
> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev