From: Daniel Vetter <daniel@ffwll.ch>
To: "Enrico Weigelt, metux IT consult" <enrico.weigelt@gr13.net>
Cc: dri devel <dri-devel@lists.freedesktop.org>
Subject: Re: Frame buffer access performance
Date: Fri, 5 Aug 2016 11:23:48 +0200 [thread overview]
Message-ID: <20160805092348.GC6232@phenom.ffwll.local> (raw)
In-Reply-To: <57A45695.9060804@gr13.net>
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
prev parent reply other threads:[~2016-08-05 9:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-05 2:35 Frame buffer access performance Enrico Weigelt, metux IT consult
2016-08-05 8:15 ` Daniel Vetter
2016-08-05 9:04 ` Enrico Weigelt, metux IT consult
2016-08-05 9:23 ` Daniel Vetter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160805092348.GC6232@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=enrico.weigelt@gr13.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.