[Intel-gfx] Corruption in glxgears with Compiz

Peter Clifton pcjc2 at cam.ac.uk
Sat Oct 23 13:42:05 CEST 2010


On Sat, 2010-10-23 at 10:10 +0100, Chris Wilson wrote:
> On Sat, 23 Oct 2010 05:07:57 +0100, Peter Clifton <pcjc2 at cam.ac.uk> wrote:
> > Although I don't doubt that it is incorrect for some reason. My logic
> > was this.. the mm.flush_rings is supposed to be |='d with the object's
> > ring->id if the ring is set on a given object.
> 
> Well the whole inter-ring flushing is decidedly suspect since we have no
> synchronisation between rings, yet. However in this scenario, you are just
> using one ring...
> 
> If an object is in a GPU domain and so requires a flush, it is attached to
> a ring. However, if the object needs an invalidation it may not yet be
> attached to the ring (and in any event the invalidation needs to be
> performed on the pending ring). Ahah.
> 
> Note to self: flushes must be done on the from-ring before the semaphore
> and invalidations on the to-ring after the semaphore.
> 
> Can you try this patch?

Your patch works a treat.. I knew mine was really only a band-aid which
forced a flush on the pending indiscriminately, and was glad to see the
proper fix. 

Really difficult to get your head round all this flush / invalidate
stuff. I get the idea, but in practice it is very confusing due to the
fact it is all deferred / scheduled work, and both subtly different
concepts (flush / invalidate) concepts are handled by the same action on
the GPU, and very similar code! Very easy to muddle current / pending
ring in my head, for example.

You replied to Alexey that the patch is only a stop gap, and inter-ring
synchronisation is the real challenge. I guess that is something you'll
be forced to look at with the new Sandybridge chipset having a separate
ring for BLT operations?

I'm just looking for fps with my circuit board rendering GL code at the
moment.. that's why I'm following git HEAD stuff, to see if the drivers
can unlock some performance in the code I'm writing. I'm struggling to
profile just what the bottleneck is!

-- 
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)




More information about the Intel-gfx mailing list