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 the
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 from
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 the
On Thu, Dec 4, 2014 at 12:29 PM, Chris Wilson ch...@chris-wilson.co.uk 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
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
