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. >> 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. -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
