From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chad Versace Subject: Re: [RFC/Draft] Testing requirements for upstream drm/i915 patches Date: Wed, 30 Oct 2013 13:32:44 -0700 Message-ID: <52716CEC.6000102@linux.intel.com> References: <52712D37.6050701@intel.com> <52714BCF.6050203@freedesktop.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by gabe.freedesktop.org (Postfix) with ESMTP id AAC68EEFE6 for ; Wed, 30 Oct 2013 13:32:48 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Daniel Vetter , Ian Romanick Cc: "Nikkanen, Kimmo" , "intel-gfx@lists.freedesktop.org" , "gfx-internal-devel@linux.intel.com" , "Hindman, Gavin" , "Barnes, Jesse" , Daniel Vetter , "Parenteau, Paul A" List-Id: intel-gfx@lists.freedesktop.org On 10/30/2013 12:05 PM, Daniel Vetter wrote: > On Wed, Oct 30, 2013 at 7:11 PM, Ian Romanick wrote: >>> test coverage of the existing code _before_ starting a feature instead >>> of when the patches are ready for merging should help a lot, before >>> everyone is invested into patches already and mounting rebase pain looms >>> large. > Yeah, that would be a great way to bring up new people. The problem is > a bit that on the kernel side we have a few disadvantages compared to > mesa: We don't have a nice spec and we also don't have a fairly decent > reference implementation (the nvidia blob). So ime writing kernel > tests is much more open-ended than reading a gl extension spec and > just nocking off all the new enums and api interface points. Writing *meaningful* GL tests is much more open-ended than reading a gl spec and knocking off each item. To really test some GL features, you must be exceedingly clever and even have an understanding of the underlying hardware implementation to test the significant corner cases. In that sense, it's not too different from writing a kernel test case. My comment is intended to be positive rather than a negative correction. The Mesa team frequently succeeds at creating good test coverage of new GL features despite the difficulty. That fact hopefully confirms it will be possible for the kernel team too.