On 04/06/16 20:36, Rob Clark wrote:
On Fri, Jun 3, 2016 at 8:53 AM, Rob Clark <robdcl...@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.

Freedreno mailing list

Reply via email to