[Mesa-dev] RFC: more changes to render_condition

[Christoph Bumiller]

On 22.06.2013 16:36, Roland Scheidegger wrote:
> 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

You could still go with adding a separate render_condition
(non_render_stuff_condition) for transfers, copies and blits, that's how
it's done on NV hardware.
Adding booleans to all the functions looks ugly.

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