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

[Jose Fonseca]

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.

Jose