[Mesa-dev] RFC: more changes to render_condition

[Roland Scheidegger]

We decided to drop predicated transfers already. State tracker can
emulate this by using another resource and doing a (predicated)
resource_copy_region, might be slightly suboptimal but predicated
transfers really sound strange.
As for resource_copy_region, I'm fine with a flag indicating if it
honors predication or not. You can have that for blit too if you need it
(maybe if you implement resource_copy_region as a blit?), I was thinking
about it (it is not obvious why blit should behave differently really),
but decided against it because d3d10 apparently does not seem to require
it (and other apis don't predicate that stuff anyway), unless the docs
are wrong (resolve isn't mentioned among the predicated functions).

Roland


Am 22.06.2013 14:27, schrieb 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