[Freedreno] [Mesa-dev] tilers and out-of-order rendering..

[Rob Clark]

On Mon, Jun 6, 2016 at 5:19 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 04/06/16 20:36, Rob Clark wrote:
>>
>> On Fri, Jun 3, 2016 at 8:53 AM, Rob Clark <robdclark at gmail.com> wrote:
>>>
>>> Ok, so I had a really evil thought that I wanted to bounce off
>>> people..  it's a quite different approach from the more obvious one
>>> discussed below (and which I've already started implementing)
>>>
>>> Basically, idea is to have a wrapper pipe driver, similar to
>>> ddebug/rbug/trace/etc, which re-orders draw calls.  All the CSO
>>> objects would have to be wrapped in a refcounted thing, so
>>> pending-draw's could hang on to their associated state.  For things
>>> that are not refcounted (draw_info, and all the non-CSO state) there
>>> would unfortunately be some memcpy involved.. not sure how bad that
>>> would be, but it seems like the thing that could doom the idea?
>>
>>
>> so the slightly awkward thing is how to deal with things like
>> u_blitter (pipe->blit/pipe->copy_region).. if we were re-ordering
>> things to avoid unnecessary render target switches, the wrapper layer
>> would have to handle these paths itself.  But looks like vc4 has some
>> special handling (vc4_tile_blit()).. not really sure how that would
>> work out.
>>
>> (and in general, the wrapper layer would want to handle some cases, as
>> well as transfer_map, itself.. so it could generate ghost
>> pipe_resources for things like writing into a busy texture.. but that
>> probably isn't too hard since a wrapper pipe_resource could replace
>> the ref to hw driver's pipe_resource and schedule blits to copy from
>> previous pipe_resource where needed..  hopefully combination of
>> PIPE_TRANSFER_DISCARD* and pipe_draw_info::discard type hint (as I
>> mentioned below) could "DCE" those copy blits.  Except I somehow need
>> to deal w/ CSO's which have reference to the ghosted resource.. bleh)
>
>
> Yeah, wrapper pipe drivers sound nice in theory, but aren't that great in
> practice, for anything other than debugging pipe drivers.
>
> A driver auxiliary library that drivers can opt-in/out and extend, is much
> more flexible.
>
> But still, rather than aiming straight at a driver indepedendent code, it
> might be better to first prototoype as an internal driver component, and
> then generalize/refactor in a 2nd step.

well, it is two fairly different approaches.  Doing it in the driver,
you would (presumably) be buffering up baked cmdstream.  Vs the
wrapper layer that is buffering up gallium state.  I do like the
aspect that it keeps all the (rather generic) complexity of dependency
tracking and resource ghosting out of the driver.

And I do like the fact that switching it on/off is just a matter of
deciding to wrap the screen or not, and when you don't wrap the screen
the overhead goes away completely.

idk, I may end up trying it both ways in the end..

BR,
-R