On Tue, Jan 07, 2014 at 06:01:57AM -0800, Paul Berry wrote: > On 6 January 2014 17:05, Chad Versace <chad.vers...@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-sta...@lists.freedesktop.org > CC: Kenneth Graunke <kenn...@whitecape.org> > CC: Paul Berry <stereotype...@gmail.com> > CC: Stéphane Marchesin <marc...@chromium.org> > Signed-off-by: Chad Versace <chad.vers...@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? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
