[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+55aFya2e4q9kJLTAasCtkFAmAuK1HqzbiEySAwgr6SFcwNcA@mail.gmail.com>
Date: Wed, 13 Jan 2016 10:45:22 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Chris Wilson <chris@...is-wilson.co.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirski <luto@...capital.net>,
"H. Peter Anvin" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ross Zwisler <ross.zwisler@...ux.intel.com>,
"H . Peter Anvin" <hpa@...ux.intel.com>,
Borislav Petkov <bp@...en8.de>,
Brian Gerst <brgerst@...il.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Imre Deak <imre.deak@...el.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
DRI <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] x86: Add an explicit barrier() to clflushopt()
On Wed, Jan 13, 2016 at 4:34 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
>
> Forgive me for being dense, but if we overwrite the GPU data in the
> backing struct page with the cacheline from the CPU, how do we see the
> results from the GPU afterwards?
Hmm. Good point.
Ok, all the symptoms just say "writes from GPU are delayed and out of order".
Do you have access to the GPU hardware people?
I thought that all the modern Intel GPU's are cache-coherent. If this
is some castrated chip where coherence is removed (perhaps because it
is not working? perhaps config setting?) maybe it needs some extra
ghardware setting to make the GPU "flush" operation actually do
something. In a cache-coherent model, a flush could/should be a noop,
so maybe the hardware is set for that kind of "flush does nothing"
behavior.
Or maybe the GPU is just a buggy pile of crap.
Linus
Powered by blists - more mailing lists