Frame buffer access performance

Frame buffer access performance

[Enrico Weigelt, metux IT consult]

Hi folks,


when putting pixels into an DRM framebuffer, should I do that in
bursts/blocks instead of byte-per-byte ? (eg. explicitly using
aligned 32bit ops).


--mtx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Frame buffer access performance

[Daniel Vetter]

On Fri, Aug 05, 2016 at 04:35:25AM +0200, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
> 
> 
> when putting pixels into an DRM framebuffer, should I do that in
> bursts/blocks instead of byte-per-byte ? (eg. explicitly using
> aligned 32bit ops).

There's a driver cap DRM_CAP_DUMB_PREFER_SHADOW for this. If set, render
into a shadow buffer and copy over in bursts, otherwise you can assume
that the memory is fully cpu cached and fast with random access. Note that
this is just for dumb buffers, which are explicitly not meant as the
fastest memory, but the most convenient (i.e. untiled).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Frame buffer access performance

[Enrico Weigelt, metux IT consult]

On 05.08.2016 10:15, Daniel Vetter wrote:

Hi,

> There's a driver cap DRM_CAP_DUMB_PREFER_SHADOW for this. If set,
> render into a shadow buffer and copy over in bursts, otherwise you
> can assume that the memory is fully cpu cached and fast with random
> access.

aaaah!

nekrad@orion:~/src/linux$ git grep prefer_shadow drivers/gpu/drm/i915
drivers/gpu/drm/i915/intel_display.c:   dev->mode_config.prefer_shadow = 1;

IOW: i915 driver (my notebook here has an i915) sets that flag, so
it seems my guess is right.

Do we already have some suitable double-buffer helpers, which can detect
changed regions and copy over in bursts, so userland doesn't
need extra logic for that ? (hmm, maybe some cow + pagefault magic?)

... seems I need to give it some further thoughts ...


--mtx

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

Re: Frame buffer access performance

[Daniel Vetter]

On Fri, Aug 05, 2016 at 11:04:21AM +0200, Enrico Weigelt, metux IT consult wrote:
> On 05.08.2016 10:15, Daniel Vetter wrote:
> 
> Hi,
> 
> > There's a driver cap DRM_CAP_DUMB_PREFER_SHADOW for this. If set,
> > render into a shadow buffer and copy over in bursts, otherwise you
> > can assume that the memory is fully cpu cached and fast with random
> > access.
> 
> aaaah!
> 
> nekrad@orion:~/src/linux$ git grep prefer_shadow drivers/gpu/drm/i915
> drivers/gpu/drm/i915/intel_display.c:   dev->mode_config.prefer_shadow = 1;
> 
> IOW: i915 driver (my notebook here has an i915) sets that flag, so
> it seems my guess is right.
> 
> Do we already have some suitable double-buffer helpers, which can detect
> changed regions and copy over in bursts, so userland doesn't
> need extra logic for that ? (hmm, maybe some cow + pagefault magic?)
> 
> ... seems I need to give it some further thoughts ...

DIRTY_FB ioctl. But that's for other manual uplaod displays and similar
things.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel