Chris,
I am sorry that I didn't tell you about GPU that
I am working on. It is GEN9LP. Our target is APL-I.
So no LLC is available.
On Wed, Apr 19, 2017 at 07:26:29PM +0100, Chris Wilson wrote:
> On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote:
> > Chris,
> >
> > Just to make sure,
Chris,
I think my assumption was not correct. I took out write_domain
check but it is still failing. However, here are couple of
observation points. I did some experiments.. One of them is
to take out even cache_dirty check from eb_move_to_gpu.
With this, all sample tests were passing but as you
On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote:
> Chris,
>
> Just to make sure, you want to just remove write_domain check from
> if statement before clflush in execbuffer_move_to_gpu. Am I right?
> I will try both (cache_dirty only vs cache_dirty & !cache_coherent)
> and get back to
Chris,
Just to make sure, you want to just remove write_domain check from
if statement before clflush in execbuffer_move_to_gpu. Am I right?
I will try both (cache_dirty only vs cache_dirty & !cache_coherent)
and get back to you shortly.
On Wed, Apr 19, 2017 at 07:08:33PM +0100, Chris Wilson wr
On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote:
> I tried your patch but it didn't fix the original
> problem. I think it is somehow related to the flushing condition
> here:
>
> @@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct
> drm_i915_gem_request *req,
> if (v
On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote:
> I tried your patch but it didn't fix the original
> problem. I think it is somehow related to the flushing condition
> here:
I don't think I actually checked what GPU you observed it on - I was
assuming llc, since that was the last bu
On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote:
> I tried your patch but it didn't fix the original
> problem. I think it is somehow related to the flushing condition
> here:
>
> @@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct
> drm_i915_gem_request *req,
> if (v
I tried your patch but it didn't fix the original
problem. I think it is somehow related to the flushing condition
here:
@@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct
drm_i915_gem_request *req,
if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
continue;
Currently, we only mark the CPU cache as dirty if we skip a clflush.
This leads to some confusion where we have to ask if the object is in
the write domain or missed a clflush. If we always mark the cache as
dirty, this becomes a much simply question to answer.
The goal remains to do as few clflus
