Re: [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ville,

On 23 March 2018 at 14:42, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
> On Fri, Mar 23, 2018 at 01:45:50PM +0000, Daniel Stone wrote:
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -13916,7 +13916,8 @@ static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
>>       drm_framebuffer_cleanup(fb);
>>
>>       i915_gem_object_lock(obj);
>> -     WARN_ON(!obj->framebuffer_references--);
>> +     WARN_ON(obj->framebuffer_references < fb->format->num_planes);
>> +     obj->framebuffer_references -= fb->format->num_planes;
>
> Hmm. I'm thinking we can stick to the single reference per fb.
> IIRC this counter is there just to prevent changes of the obj
> tiling mode as long as any fb exists that uses the object. So
> doesn't actually matter how many planes the fb has.
>
> Naturally the story would be slightly difference if we supported
> fbs using multiple different BOs, as each BO would need to get its
> framebuffer_references adjusted.

Yeah, fair enough. It looks a little bit weird (perhaps deserving of a
comment) there. The reason to do that was just the general principle
of having one reference per object pointer, especially when other
drivers (ones which can have separate BOs in a single logical image)
will and do refcount them separately. Having different refcounting
semantics in shared structures depending on which driver is in use
makes me itchy.

Cheers,
Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux