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