On Sun, Jul 27, 2014 at 1:38 PM, Daniel Vetter <daniel at ffwll.ch> wrote: > On Sun, Jul 27, 2014 at 6:20 PM, Rob Clark <robdclark at gmail.com> wrote: >> On Sun, Jul 27, 2014 at 11:17 AM, Daniel Vetter <daniel at ffwll.ch> wrote: >>> On Sat, Jul 26, 2014 at 12:51 AM, Rob Clark <robdclark at gmail.com> wrote: >>>> We're going to need this for atomic. >>>> >>>> Signed-off-by: Rob Clark <robdclark at gmail.com> >>> >>> 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
