Re: [PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

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

 



Hi,

On 4 April 2017 at 11:27, Christopher James Halse Rogers
<chris@xxxxxxxxxxxxxx> wrote:
> On 4 April 2017 6:31:12 pm AEST, Daniel Vetter <daniel@xxxxxxxx> wrote:
>>This seems like an awful specific special case. Why can't you do the
>>entire dance upfront, i.e. import buffer, addfb2? None of that has any
>>visible effect, and it will also allow you to check runtime constraints
>>which can't be covered with this here.
>
> No, because addfb2 doesn't (or, rather, didn't) actually check any runtime constraints.
>
> The problem only appeared when the buffer is actually *used* in a modeset - otherwise I could do a (reasonably) cheap import/addfb/render on exporter/read out on importer dance to detect it.
>
> To be clear - this is trying to solve the problem “how can I tell if it's safe to addfb/pageflip rather than do a GL copy to a GPU-local buffer and flip from that?”.
>
> If I could guarantee that I'd only ever run on 4.13-or-later kernels (I think that's when the previous patches will land?), then this would indeed be mostly unnecessary. It would save me a bunch of addfb calls that would predictably fail, but they're cheap.

Yeah, the ABI is that AddFB2 should fail hard on something which can
never be used as a framebuffer. The fact it didn't is a bug rather
than a behavioural change per se ...

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux