| Message ID | 1343220704-4210-2-git-send-email-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Daniel Vetter <daniel.vetter@ffwll.ch> writes: > Since we don't guarantee that objects stay at the same gtt offset, > userspace needs to reload all indirect state anyway, even with hw > contexts. The hw provides a little pipe_control flag to disable at > least some these indirect state pointers and hence avoid to > save/restore them at context switch time. > > Seems to improve hw context switch throughput as measured by running > glxgears by about 0.5%, barely above the noise on my ivb gt2 here. I'd like to see some better testing than picking an fps number out of glxgears. I'm dubious of there being any measurable effect here. But then, I haven't even been able to figure out from the specs what exactly is considered to be "indirect state".
On Thu, Jul 26, 2012 at 7:33 PM, Eric Anholt <eric@anholt.net> wrote: > Daniel Vetter <daniel.vetter@ffwll.ch> writes: > >> Since we don't guarantee that objects stay at the same gtt offset, >> userspace needs to reload all indirect state anyway, even with hw >> contexts. The hw provides a little pipe_control flag to disable at >> least some these indirect state pointers and hence avoid to >> save/restore them at context switch time. >> >> Seems to improve hw context switch throughput as measured by running >> glxgears by about 0.5%, barely above the noise on my ivb gt2 here. > > I'd like to see some better testing than picking an fps number out of > glxgears. I'm dubious of there being any measurable effect here. But > then, I haven't even been able to figure out from the specs what exactly > is considered to be "indirect state". I admit that the the glxgears number is rather pointless - it's meant more as a quick sanity test that things don't go slower. The motivation why I've done this is more that this could help in catching mesa bugs, where for some odd reason some indirect state doesn't get re-emitted (now with hw contexts that's harder to detect than just running 2 drm clients in parallel). If the hw gives us a bit to clean (at least parts) of that state out, I think we should use it to improve testing coverage. -Daniel
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index f52778f..bc95142 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -228,6 +228,7 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring, flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE; flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE; flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE; + flags |= PIPE_CONTROL_INDIRECT_STATE_DISABLE; if (IS_GEN7(ring->dev)) flags |= PIPE_CONTROL_DC_CACHE_FLUSH; /*
Since we don't guarantee that objects stay at the same gtt offset, userspace needs to reload all indirect state anyway, even with hw contexts. The hw provides a little pipe_control flag to disable at least some these indirect state pointers and hence avoid to save/restore them at context switch time. Seems to improve hw context switch throughput as measured by running glxgears by about 0.5%, barely above the noise on my ivb gt2 here. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + 1 file changed, 1 insertion(+)