Re: [PATCH 18/32] drm/i915: Use HWS for seqno tracking everywhere

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 04, 2016 at 06:11:56PM +0000, Dave Gordon wrote:
> So previously, we wrote the seqno and other dummy data into the
> SCRATCH page, whereas now it's going to the HWSP. Does that make the
> scratch page redundant? Or are there other bits of code that write
> other stuff into it?

The scratch page is used on gen6+ for workaround flushes, and gen8+ for
per-bb workarounds.

> Then, the new code not only writes in dword I915_GEM_HWS_INDEX of
> the HWSP, but also at multiple cache lines above this address. Do
> those write have to be to the same page as the seqno, or could they
> still go to the scratch page?

The writes only exist to act as a flush of the pipecontrols themselves,
what they write and where is irrelevant. Afaik, writing to separate
cachelines is paranoia, but does not complicate the code too much.
 
> If the latter, I think we'd need to flag this in a big comment above
> the definition of I915_GEM_HWS_INDEX, because it's not just defining
> a single word as it appears, but rather a large block that will be
> scribbled on.
>
> (Note: TDR and the preemption code each require some extra locations
> in the HWSP; they mustn't be scribbled over with dummy data).

Sure. But on gen5 only the first 20 dwords are reserved for use by the
hw, the rest of the page is our to use. And since the removal of DRI1,
there is no other use.
 
> Finally, we seem to have lost the
> PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE bits; was that deliberate? And
> should it have been in a separate patch?

It is the wrong flag. Separate patch would be that we don't need the
pipecontrols anyway, which was sent last year.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux