i915_gem_evict_something in sysprof trace using VBOs

i915_gem_evict_something in sysprof trace using VBOs

[Peter Clifton]

I was playing with my VBO code, and noticed this sysprof trace
(non-interesting stuff pruned):

drm_ioctl                                         0.13%  56.08%
  i915_gem_execbuffer2                            0.00%  32.50%
    i915_gem_do_execbuffer                        0.08%  32.50%
      i915_gem_object_pin                         0.00%  17.47%
        i915_gem_object_bind_to_gtt               0.03%  17.44%
          i915_gem_evict_something                0.00%  15.54%
            i915_gem_object_unbind                0.00%  15.31%
              i915_gem_object_set_to_cpu_domain   0.00%  13.33%
                i915_gem_clflush_object           0.00%  13.33%
      i915_gem_clflush_object                     0.00%  14.29%
  i915_gem_mmap_gtt_ioctl                         0.00%  10.74%
  i915_gem_set_domain_ioctl                       0.00%   4.98%


The i915_gem_evict_something has me curious. Presumably I have too many
pages of data actively being used by the GPU (or mapped).

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

Re: i915_gem_evict_something in sysprof trace using VBOs

[Chris Wilson]

On Fri, 05 Nov 2010 10:21:07 +0000, Peter Clifton <pcjc2@cam.ac.uk> wrote:
> I was playing with my VBO code, and noticed this sysprof trace
> (non-interesting stuff pruned):
> 
> drm_ioctl                                         0.13%  56.08%
>   i915_gem_execbuffer2                            0.00%  32.50%
>     i915_gem_do_execbuffer                        0.08%  32.50%
>       i915_gem_object_pin                         0.00%  17.47%
>         i915_gem_object_bind_to_gtt               0.03%  17.44%
>           i915_gem_evict_something                0.00%  15.54%
>             i915_gem_object_unbind                0.00%  15.31%
>               i915_gem_object_set_to_cpu_domain   0.00%  13.33%
>                 i915_gem_clflush_object           0.00%  13.33%
>       i915_gem_clflush_object                     0.00%  14.29%
>   i915_gem_mmap_gtt_ioctl                         0.00%  10.74%
>   i915_gem_set_domain_ioctl                       0.00%   4.98%
> 
> 
> The i915_gem_evict_something has me curious. Presumably I have too many
> pages of data actively being used by the GPU (or mapped).

Yes, you are suffering from aperture thrashing. There are a few ways to
workaround this (1) decrease the size of your working set (reduce texture
sizes, reuse as many buffers within the aperture as possible), (2)
increase the size of the aperture (check your BIOS AGP size and apply
drm-intel-next to get the benefit of the full-GTT), (3) add an uncached
page cache to avoid those costly clflushes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: i915_gem_evict_something in sysprof trace using VBOs

[Peter Clifton]

On Fri, 2010-11-05 at 10:35 +0000, Chris Wilson wrote:
> On Fri, 05 Nov 2010 10:21:07 +0000, Peter Clifton <pcjc2@cam.ac.uk> wrote:
> > I was playing with my VBO code, and noticed this sysprof trace
> > (non-interesting stuff pruned):
> > 
> > drm_ioctl                                         0.13%  56.08%
> >   i915_gem_execbuffer2                            0.00%  32.50%
> >     i915_gem_do_execbuffer                        0.08%  32.50%
> >       i915_gem_object_pin                         0.00%  17.47%
> >         i915_gem_object_bind_to_gtt               0.03%  17.44%
> >           i915_gem_evict_something                0.00%  15.54%
> >             i915_gem_object_unbind                0.00%  15.31%
> >               i915_gem_object_set_to_cpu_domain   0.00%  13.33%
> >                 i915_gem_clflush_object           0.00%  13.33%
> >       i915_gem_clflush_object                     0.00%  14.29%
> >   i915_gem_mmap_gtt_ioctl                         0.00%  10.74%
> >   i915_gem_set_domain_ioctl                       0.00%   4.98%
> > 
> > 
> > The i915_gem_evict_something has me curious. Presumably I have too many
> > pages of data actively being used by the GPU (or mapped).
> 
> Yes, you are suffering from aperture thrashing. There are a few ways to
> workaround this (1) decrease the size of your working set (reduce texture
> sizes, reuse as many buffers within the aperture as possible)

All VBOs. (One 1.7M VBO actually), but it appears the driver / card is
hanging on to it for a while, so every time I glBufferData (...,
NULL, ...); and glMapBuffer - I get more memory usage. I was expecting
the card to use (say), a handful of copies, but no more.

I guess the CPU got ahead of the GPU in terms of rendering, and it used
up all the aperture space in doing so. In truth, my buffers are RARELY
full, but due to some other (bad) code, needed to be large enough to fit
a particularly complex object in some rare cases.

Having thought about it all now (and read some of the implementation
details in mesa / kernel), I think glBufferSubData should work MUCH
better for my needs.

I take bets its "something I've done wrong", as usually seems to be the
way, but for now - if I just use glBufferSubData to upload changed data
only, I get rendering corruption. It works fine with
LIBGL_ALWAYS_SOFTWARE=1 though, so there is perhaps a small possibility
of a driver bug?

Similarly, if I call glBufferData(..., NULL, ...) before the
glBufferSubData, I get back to bad performance (expected), but rendering
corruption is gone.

Thinking of stupid things I might have done wrong... yes, I did call
glBufferData(..., NULL, ...) once in the case where I re-upload
subsequent times with glBufferSubData(). *Turns out when you
accidentally miss this out, "bad" things happen ;).


All this said, I've discovered docs for glMapBufferRange. With a bit of
extra work to my code (to ensure I use as much of a buffer as possible
before scrapping the whole thing), I think this could be my friend for
getting decent performance out of VBOs without having to glBufferSubData
each set of new data.


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

Re: i915_gem_evict_something in sysprof trace using VBOs

[Peter Clifton]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Fri, 2010-11-05 at 11:44 +0000, Peter Clifton wrote:

> I take bets its "something I've done wrong", as usually seems to be the
> way, but for now - if I just use glBufferSubData to upload changed data
> only, I get rendering corruption. It works fine with
> LIBGL_ALWAYS_SOFTWARE=1 though, so there is perhaps a small possibility
> of a driver bug?

Does this look correct? Forcing the Gen6 fallback for BufferSubData
fixes my corruption. Seems as if the blit is going wrong. The PRM
suggests the pitch needs to be DWORD aligned,


The attached patch fixes it. What I can't quite fathom is how this has
escaped until now.. am I doing something unusual by calling
glBufferSubData with large buffers?

Could someone with access to MESA repositories review and commit it
please?


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

[-- Attachment #2: 0001-intel-Fix-emit_linear_blit-to-use-DWORD-aligned-widt.patch --]
[-- Type: text/x-patch, Size: 1479 bytes --]

>From 055cd27dbdf225c084f4bc2254763dba016edd50 Mon Sep 17 00:00:00 2001
From: Peter Clifton <pcjc2@cam.ac.uk>
Date: Fri, 5 Nov 2010 14:26:24 +0000
Subject: [PATCH] intel: Fix emit_linear_blit to use DWORD aligned width blits

The width of the 2D blits used to copy the data is defined as a 16-bit
signed integer, but the pitch must be DWORD aligned. Limit to an integral
number of DWORDs, (1 << 15 - 4) rather than (1 << 15 -1).

Fixes corruption to data uploaded with glBufferSubData.

Signed-off-by: Peter Clifton <pcjc2@cam.ac.uk>
---
 src/mesa/drivers/dri/intel/intel_blit.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_blit.c b/src/mesa/drivers/dri/intel/intel_blit.c
index a74e217..4dc8888 100644
--- a/src/mesa/drivers/dri/intel/intel_blit.c
+++ b/src/mesa/drivers/dri/intel/intel_blit.c
@@ -483,8 +483,11 @@ intel_emit_linear_blit(struct intel_context *intel,
    /* Blits are in a different ringbuffer so we don't use them. */
    assert(intel->gen < 6);
 
-   /* The pitch is a signed value. */
-   pitch = MIN2(size, (1 << 15) - 1);
+   /* The pitch hits the GPU as a is a signed value, IN DWORDs.
+    * But we want width to match pitch. Max width is (1 << 15 -1),
+    * rounding that down to the nearest DWORD is 1 << 15 - 3
+    */
+   pitch = MIN2(size, (1 << 15) - 4);
    height = size / pitch;
    ok = intelEmitCopyBlit(intel, 1,
 			  pitch, src_bo, src_offset, I915_TILING_NONE,
-- 
1.7.1


[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx