public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Goel, Akash" <akash.goel@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/vlv: Added/removed Render specific Hw Workarounds for VLV
Date: Mon, 20 Jan 2014 10:19:48 +0200	[thread overview]
Message-ID: <87r4836p5n.fsf@intel.com> (raw)
In-Reply-To: <8BF5CF93467D8C498F250C96583BC09CC59765@BGSMSX103.gar.corp.intel.com>

On Sun, 19 Jan 2014, "Goel, Akash" <akash.goel@intel.com> wrote:
>>> Frankly, I don't know much about these particular workarounds, but
>>> for bisecting any regressions it would probably be a good idea to
>>> split the patch per workaround touched.

> Sorry for late response on this, actually we have done sufficient
> testing for this patch.

I'm happy to hear that. However no reasonable amount of testing will
cover the astonishing variety of conditions this code will run under out
there in the real world, and if something blows up, we might never be
able reproduce it ourselves.

> Moreover these workarounds are applicable to VLV only & will not
> affect any other platforms.

Really? WaReadAfterWriteHazard in intel_ring_flush_all_caches() and
WaTlbInvalidateStoreDataBefore in intel_ring_invalidate_all_caches()?

Btw our convention is to append the affected platforms to the w/a names
in the code; please look around for examples.

> So probably it can be pushed as it is without splitting. 

My opinion still stands. I think all workarounds are fragile by
definition, and should be separate patches.

Quoting Daniel, "if a regression would bisect to this, and the bisect is
the only useful piece of evidence, would I stand a chance to understand
it?"


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

  reply	other threads:[~2014-01-20  8:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 11:51 [PATCH] drm/i915/vlv: Added/removed Render specific Hw Workarounds for VLV akash.goel
2014-01-09 12:26 ` Jani Nikula
2014-01-19 15:48   ` Goel, Akash
2014-01-20  8:19     ` Jani Nikula [this message]
2014-01-20  8:21       ` Goel, Akash
2014-01-09 16:05 ` Ville Syrjälä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r4836p5n.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=akash.goel@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox