On Thu, Dec 4, 2014 at 12:29 PM, Chris Wilson wrote:
> It uses locked atomic operations, which are unnecessary for the very
> frequent is-complete checks (due to the nice ordering constraints of x86).
So let's look at the fastpaths:
- fence already signaled: Just a test_bit which amounts to a nor
On Thu, Dec 04, 2014 at 12:05:34PM +0100, Daniel Vetter wrote:
> On Thu, Dec 04, 2014 at 09:13:21AM +, Chris Wilson wrote:
> > On Wed, Dec 03, 2014 at 11:49:07AM -0800, Jesse Barnes wrote:
> > > This simplifies the sync code quite a bit. I don't think we'll be able
> > > to get away with using
On Thu, Dec 04, 2014 at 09:13:21AM +, Chris Wilson wrote:
> On Wed, Dec 03, 2014 at 11:49:07AM -0800, Jesse Barnes wrote:
> > This simplifies the sync code quite a bit. I don't think we'll be able
> > to get away with using the core fence code's seqno support, since we'll
> > be moving away fr
On Wed, Dec 03, 2014 at 11:49:07AM -0800, Jesse Barnes wrote:
> This simplifies the sync code quite a bit. I don't think we'll be able
> to get away with using the core fence code's seqno support, since we'll
> be moving away from simple seqno comparisions with the scheduler and
> preemption, but
This simplifies the sync code quite a bit. I don't think we'll be able
to get away with using the core fence code's seqno support, since we'll
be moving away from simple seqno comparisions with the scheduler and
preemption, but the additional code is pretty minimal anyway, and lets
us add addition
