In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
write the fence from each cpu taking care to serialise memory accesses
on each. The usual mb(), or even a mb() on each CPU is not enough to
ensure that access
In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
write the fence from each cpu taking care to serialise memory accesses
on each. The usual mb(), or even a mb() on each CPU is not enough to
ensure that access
In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
write the fence from each cpu taking care to serialise memory accesses
on each. The usual mb(), or even a mb() on each CPU is not enough to
ensure that access
In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
write the fence from each cpu taking care to serialise memory accesses
on each. The usual mb(), or even a mb() on each CPU is not enough to
ensure that access
In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
write the fence from each cpu taking care to serialise memory accesses
on each. The usual mb(), or even a mb() on each CPU is not enough to
ensure that access
In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
manually flush writes to memory prior to writing the fence register in
conjunction with the memory barriers placed around the register write.
Fixes i-g-t/gem_f
On Thu, Mar 21, 2013 at 03:30:19PM +, Chris Wilson wrote:
> In order to fully serialize access to the fenced region and the update
> to the fence register we need to take extreme measures on SNB+, and
> write the fence from each cpu taking care to serialise memory accesses
> on each. The usual
On Thu, 4 Apr 2013 21:31:03 +0100
Chris Wilson wrote:
> In order to fully serialize access to the fenced region and the update
> to the fence register we need to take extreme measures on SNB+, and
> manually flush writes to memory prior to writing the fence register in
> conjunction with the mem
On Fri, Apr 05, 2013 at 09:03:27AM -0700, Jesse Barnes wrote:
> On Thu, 4 Apr 2013 21:31:03 +0100
> Chris Wilson wrote:
>
> > In order to fully serialize access to the fenced region and the update
> > to the fence register we need to take extreme measures on SNB+, and
> > manually flush writes t
On 04/08/2013 11:54 AM, Daniel Vetter wrote:
On Fri, Apr 05, 2013 at 09:03:27AM -0700, Jesse Barnes wrote:
On Thu, 4 Apr 2013 21:31:03 +0100
Chris Wilson wrote:
In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SN
On Sat, Jun 8, 2013 at 10:41 PM, Carsten Emde wrote:
> On 04/08/2013 11:54 AM, Daniel Vetter wrote:
>>
>> On Fri, Apr 05, 2013 at 09:03:27AM -0700, Jesse Barnes wrote:
>>>
>>> On Thu, 4 Apr 2013 21:31:03 +0100
>>> Chris Wilson wrote:
>>>
In order to fully serialize access to the fenced regi
edt; Christoph Mathys; stable
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Workaround incoherence
> between fences and LLC across multiple CPUs
>
> On Sat, Jun 8, 2013 at 10:41 PM, Carsten Emde wrote:
> > On 04/08/2013 11:54 AM, Daniel Vetter wrote:
> >>
> >> On
edt; Christoph Mathys; stable
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Workaround incoherence
> between fences and LLC across multiple CPUs
>
> On Mon, Jun 10, 2013 at 3:17 PM, Bloomfield, Jon
> wrote:
> >> -Original Message-
> >> From: daniel.vet...@ffwl
Wilson; Jesse Barnes; Intel Graphics Development; Bloomfield, Jon;
>> Steven Rostedt; Christoph Mathys; stable
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Workaround incoherence
>> between fences and LLC across multiple CPUs
>>
>> On Sat, Jun 8, 2013 at 10:41 PM, Car
On Mon, Jun 10, 2013 at 4:47 PM, Bloomfield, Jon
wrote:
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the se
15 matches
Mail list logo
