On Thu, 2017-07-20 at 12:39 +0300, Jani Nikula wrote: > For future reference, please post new versions of the entire series as > new threads. When posting new versions of just some individual > patches, > in-reply-to each patch being replaced is fine. I think this is more > clear, and also gives patchwork a better chance to apply the right > patches for testing (not that it does igt CI, but that might change). Quoting Lyude from an earlier exchange: * When you're doing a new revision of a patch series, it's helpful to keep it in the same email thread as the original v1 so it's easier to keep track of in people's mail clients (as well as avoiding accidentally reviewing older patch versions. I actually prefer it your way (posting as new threads), so I suppose I'll do that in the future, if Lyude doesn't have any strong objection about it. Cheers, Paul > On Wed, 19 Jul 2017, Paul Kocialkowski <paul.kocialkowski@linux.intel. > com> wrote: > > Changes since v4: > > * Moved igt_get_cairo_surface out of the thread function to properly > > handle assert failure > > * Rebased on top of current master > > > > Changes since v3: > > * Renamed structure used by async crc calculation for more clarity > > * Used const qualifier for untouched buffer when hashing > > * Split actual calculation to a dedicated function > > * Reworked async functions names for more clarity > > * Reworked descriptions for better accuracy > > * Exported framebuffer cairo surface and use it directly instead of > > (unused) png dumping > > * Fix how the framebuffer cairo surface is obtained to avoid > > destroying > > it too early > > > > * Made CRC checking logic common > > * Added a check for the same number of words > > * Made frame dumping configuration and helpers common > > * Added an extended crc to string helper > > * Added a chamelium helper for crc checking and frame dumping > > * Split the merging of crc functions to a separate patch > > * Added support for frame dump path global variable > > * Added listing the dumped images in a file, possibly identified > > with > > an id global variable > > > > The latter allows having one "dump report" file per run, possibly > > identified with the id global variable, that indicates which files > > are the output, while keeping the possibility to have the same files > > for different runs. This allows saving significant disk space when > > the images are identified with e.g. their crc, so that duplicate > > results > > only lead to duplicate dump reports and not duplicate images. > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxxxxxx> Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
