On Sun, Jul 27, 2014 at 1:38 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Sun, Jul 27, 2014 at 6:20 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: >> On Sun, Jul 27, 2014 at 11:17 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: >>> On Sat, Jul 26, 2014 at 12:51 AM, Rob Clark <robdclark@xxxxxxxxx> wrote: >>>> We're going to need this for atomic. >>>> >>>> Signed-off-by: Rob Clark <robdclark@xxxxxxxxx> >>> >>> I disagree. Iiui correctly Rob's concern is that the additional stuff >>> to keep track of mode lists (list_head and the idr stuff) could >>> confuse driver writers into doing stupid stuff when they embed >>> drm_display_mode into some other stuff. Imo the right fix would be to >>> just remove them (but that's fairly invasive to the mode list code). >> >> bleh, all the deep copies seem ugly either way, I still think >> refcnt'ing and shallow copies is the better idea > > Until people start screaming at me I'm not really concerned with cpu > overhead in the modeset code. We need to do piles of uncached register > writes (at least in most drivers) and it's run about 60 times per > second. Imo we can and should optimize programmer time over cpu time > here. So if deep copies allow us to avoid refcounting, them I'm all > for it. oh, I'm sure it would be hard to measure a difference.. just seems pointlessly stupid not to do refcnt'ing ;-) >>> Now wrt atomic we only need refcounting because currently >>> drm_atomic_state is refcounted. And we don't need that afaics (and I'm >>> working on the draft code to show how). So without a clear need for >>> refcounting I really prefer we don't add this complexity - doing >>> refcounting for fbs wasn't fun at all ;-) >> >> Well, that was somewhat different, because there were some side-effects of rmfb > > That's not the part I've meant since that's just a gross hack - the > rmfb stuff isn't done on the final unref, only on the final unref from > userspace. And the hack was required to avoid undoing all the benefits > of the finer-grained locking. I'm meaning the inherent auditing we > need to do when adding refcounting, and the potential complexity going > forward. we use refcnt'ing in enough other places, it isn't like it is a new and foreign concept.. if needed, we can back it up w/ some debugfs to simplify checking for leaks.. BR, -R > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
