Re: [RFC v2 1/8] drm/fb-helper: Add fb_deferred_io support

[Daniel Vetter <daniel@ffwll.ch>]

On Thu, Apr 21, 2016 at 12:29 AM, Dave Airlie <airlied@gmail.com> wrote:
> On 19 April 2016 at 01:15, Noralf Trønnes <noralf@tronnes.org> wrote:
>>
>> Den 13.04.2016 13:09, skrev Daniel Vetter:
>>>
>>> On Fri, Apr 08, 2016 at 07:05:03PM +0200, Noralf Trønnes wrote:
>>>>
>>>> This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
>>>> Accumulated fbdev framebuffer changes are signaled using the callback
>>>> (struct drm_framebuffer_funcs *)->dirty()
>>>>
>>>> The drm_fb_helper_sys_*() functions will accumulate changes and
>>>> schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
>>>> This worker is used by the deferred io mmap code to signal that it
>>>> has been collecting page faults. The page faults and/or other changes
>>>> are then merged into a drm_clip_rect and passed to the framebuffer
>>>> dirty() function.
>>>>
>>>> The driver is responsible for setting up the fb_info.fbdefio structure
>>>> and calling fb_deferred_io_init() using the provided callback:
>>>> (struct fb_info *)->fbdefio->deferred_io = drm_fb_helper_deferred_io;
>>>>
>>>> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
>>>
>>> For this one it'd be awesome to throw patches for qxl/udl on top to remove
>>> their own hand-rolled implementations. Just to maximize the testing
>>> coverage of this new code. Should be doable to set up a qxl virtual
>>> machine quickly, but even without that we should be able to pull it in
>>> (since it's mostly just about removing code from these two drivers).
>>
>>
>> There are three fb_deferred_io users in drivers/gpu/drm: qxl, udl and
>> vmwgfx.
>
> So I'm a bit confused. For me fb defio is a thing which userspace users,
> without an ioctl.
>
> So we keep track in the kernel of dirty pages in the fb and then flush those
> pages. Now the thing is that last time I tried this it interacted badly with
> gem/ttm as defio wanted to do something to the same pages etc.
>
> So I disabled it in udl for that reasons.
>
> if we are talking about just having some damage tracking and not doing
> the page level tracking then ignore me.

Yeah I read through the code, and with shmem it'll die because shmem
and fb defio will fight over the page lru. But if you have your pages
backed by cma, or the fbdev mmap pointing at an mmio range I think it
should all work (and seems to at least for Noralf).

Either way it's all optional opt-in code (just shared) and drivers can
still opt to only do defio for in-kernel rendering and either have
broken fbdev mmap support (like udl today), or implement their own
defio mmap support compatible with shmem (not that hard either, but
meh). And Noralf's conversion patches should result in bug-for-bug
compatibility.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel