[Mesa-stable] [PATCH 3/3] i965/gen6/blorp: Remove too heavy HiZ workaround

[Chad Versace]

On Tue, Jan 07, 2014 at 06:01:57AM -0800, Paul Berry wrote:
> On 6 January 2014 17:05, Chad Versace <chad.versace at linux.intel.com> wrote:
> 
>     Commit 1a92881 added extra flushes to fix a HiZ hang in
>     WebGL Google Maps. With the extra flushes emitted by the previous two
>     patches, the flushes added by 1a92881 are redundant.
> 
>     Tested with the same criteria as in 1a92881: by zooming in and out
>     continuously for 2 hours on Sandybridge Chrome OS (codename
>     Stumpy) without a hang.
> 
>     CC: mesa-stable at lists.freedesktop.org
>     CC: Kenneth Graunke <kenneth at whitecape.org>
>     CC: Paul Berry <stereotype441 at gmail.com>
>     CC: Stéphane Marchesin <marcheu at chromium.org>
>     Signed-off-by: Chad Versace <chad.versace at linux.intel.com>
>     ---
>      src/mesa/drivers/dri/i965/gen6_blorp.cpp | 14 --------------
>      1 file changed, 14 deletions(-)
> 
> 
> I'm baffled by this.  My understanding of patches 1 and 2 is that they both set
> need_workaround_flush redundantly, so they should have no effect on what is
> sent to the hardware.  Therefore, it seems like this patch puts us back in the
> buggy state we were in before commit 1a92881.  Have I missed something in my
> analysis?

Please read the commit message to patch 2, v2. That should clarify your
misunderstanding. Patch 2 does not set need_workaround_flush
redundantly.

> What was the previous MTBF on your system before commit 1a92881?  Is it
> possible that 2 hours isn't a long enoug test?  (For example, if the MTBF was
> 40 minutes, and the failures were Poisson-distributed, then I believe that 2
> hours without a failure only confirms the bug fix at 95% confidence.)

I haven't calculated the MTBF. IIRC, it was around 20 or 30 minutes.
But, to be honest, I did those experiments the first week of December,
so my memory may be inaccurate.

With the clarification on patch 2, do you still require a calculation of
MTBF?