[Intel-gfx] [PATCH] Revert "drm/i915: Kill GTT mappings when moving from GTT domain"

[Eric Anholt]

On Sun, 19 Jun 2011 18:14:11 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Sun, 19 Jun 2011 10:01:23 -0700, Eric Anholt <eric at anholt.net> wrote:
> > On Sun, 19 Jun 2011 17:28:11 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > For lack of a better mechanism. Even using anholt/gtt-revert, I question
> > > the value of caching the GTT mapping in drm_intel_bo. For the cairo-gl and
> > > pts benchmarks I've run, the efficacy of the cached vma is very small and
> > > there is a very slight improvement by unmapping the vma after use. (The
> > > difference is so small, that it will take a lot more runs to determine if
> > > it is statistically significant.)
> > 
> > I'm confused.  You've measured a 5% impact from removing this part of
> > the caching, and I've measured 12-19%, so what are you planning that
> > doesn't involve caching the mapping that's faster than caching the
> > mapping?
> 
> As I pointed out, cairo-gl is using fallback code and not spans. Once that
> is corrected, cairo-gl no longer continually recreating textures and so
> unaffected by the patch. Removing the cached vma is then arguably
> beneficial, though the difference looks to be in the noise.

So you don't actually want us to fix the performance regression in
texture uploads, and instead want to just tell applications not to
upload textures?

What about applications where we're not the authors, and where they
don't have a choice but to upload textures (media players)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20110619/4a4eff1d/attachment.sig>