Frame buffer access performance
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. > > h! > > nekrad at 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
Frame buffer access performance
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. h! nekrad at 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
Frame buffer access performance
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
Frame buffer access performance
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
