[PATCH] drm: refcnt drm_framebuffer

Rob Clark rob.clark at linaro.org
Tue Jul 31 10:41:28 PDT 2012


On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark <rob.clark at linaro.org> wrote:
>> From: Rob Clark <rob at ti.com>
>>
>> This simplifies drm fb lifetime, and if the crtc/plane needs to hold
>> a ref to the fb when disabling a pipe until the next vblank, this
>> avoids the need to make disabling an overlay synchronous.  This is a
>> problem that shows up when userspace is using a drm plane to
>> implement a hw cursor.. making overlay disable synchronous causes
>> a performance problem when x11 is rapidly enabling/disabling the
>> hw cursor.  But not making it synchronous opens up a race condition
>> for crashing if userspace turns around and immediately deletes the
>> fb.  Refcnt'ing the fb makes it possible to solve this problem.
>
> Presumably you have a follow-on patch putting the new refcnt to use so
> that we can judge whether you truly need refcnting on the fb itself in
> addition to the refcnted object and the various hw bookkeeping that
> needs to be performed?

Yes, I do.. although it is a bit experimental at this point, so not
really ready to be submitted as anything other than an RFC.. it is
part of omapdrm kms re-write to use dispc directly rather than go thru
omapdss.  (With omapdss we don't hit this issue because disabling
overlays is forced to be synchronous.. so instead we have the
performance problem I mentioned.)

I *could* just rely on the GEM refcnt, but that gets messier when you
take into account multi-planar formats.  I suppose I also could have
my own internal refcnt'd object to hold the set of GEM objects
associated w/ the fb, but, well, that seems a bit silly.  And
refcnt'ing the fb had been mentioned previously as a good thing to do
(I think it was danvet?)

BR,
-R

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


More information about the dri-devel mailing list