From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BDD88C433ED for ; Thu, 29 Apr 2021 17:14:38 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 635E661447 for ; Thu, 29 Apr 2021 17:14:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 635E661447 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 962F26F3FB; Thu, 29 Apr 2021 17:14:37 +0000 (UTC) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by gabe.freedesktop.org (Postfix) with ESMTPS id DA7266F3FA for ; Thu, 29 Apr 2021 17:14:36 +0000 (UTC) Received: by mail-wm1-x336.google.com with SMTP id k4-20020a7bc4040000b02901331d89fb83so148545wmi.5 for ; Thu, 29 Apr 2021 10:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ajSsHKNDfAVymEMJqR7ymQUX9YPKW+a1e9VmpgXluJQ=; b=lIOzAAmYLhP0pRWITkkfcUlWWQ8LaLokYdC8+ffMWHGz4La0qdP5YYT4kknaYtlylm t8DmV3dNclZckq9jOlyjIR6GXHyyMso23DUPuLQNe5k+2/6RVdQM30pnhtgtd76bVNT4 Dy2OBsNJMG/qDb6+ECgU9xQuAPwzfUgHfYljI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ajSsHKNDfAVymEMJqR7ymQUX9YPKW+a1e9VmpgXluJQ=; b=QVVlS41noVxMLV015rAstqdnFc6lu5MpLWJjUdTHfqjDHbxNudd0QP1uyBEFfoKGVf Nk2M1qsuLtktcf0jyMAmgfrArA2jvXa10zam6pcIhf/1Y5cmKe2LjiHOKeaXf0tqWONS AESbBBxWoNJ0ey1s1FgygiRTPMWvjn53shas8UR5cZfBzxXMQJvWdXxoEDJWCK1z4bje UmTR6BXrPkN/ppImP3JnBMZzgw6yYDLBnjSu+jZAji0XmyFE0rVyT8VlxUcDiWvHwEcO WTP0s2rWdxgIgCUyIQ9p9onLp4Lli/hzxYimyvO/L4PXk+Ukq+Kx3IBObw+nKYoKB/aD uSYQ== X-Gm-Message-State: AOAM531L6plNScYV4uNYTCC8DQzt/t+qqOpUlQA9cOr7kanllT5VBpR7 eCCz49TFKqZA66nLxC6cImybig== X-Google-Smtp-Source: ABdhPJwblmiMexgOUPvvzUBmVsVohdyAPzQ4enULEwTvHimn0bVZntX/GEFJfixDEXzLIrkPjjT0fQ== X-Received: by 2002:a1c:7516:: with SMTP id o22mr11609002wmc.91.1619716475549; Thu, 29 Apr 2021 10:14:35 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id g10sm9349381wmq.25.2021.04.29.10.14.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Apr 2021 10:14:35 -0700 (PDT) Date: Thu, 29 Apr 2021 19:14:33 +0200 From: Daniel Vetter To: Jason Ekstrand Subject: Re: [PATCH 08/21] drm/i915/gem: Disallow bonding of virtual engines Message-ID: References: <20210423223131.879208-1-jason@jlekstrand.net> <20210423223131.879208-9-jason@jlekstrand.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.10.32scarlett+ X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Matthew Brost , Intel GFX , Maling list - DRI developers Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Apr 29, 2021 at 11:02:27AM -0500, Jason Ekstrand wrote: > On Thu, Apr 29, 2021 at 7:16 AM Daniel Vetter wrote: > > > > On Wed, Apr 28, 2021 at 01:58:17PM -0500, Jason Ekstrand wrote: > > > On Wed, Apr 28, 2021 at 12:18 PM Jason Ekstrand wrote: > > > > > > > > On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote: > > > > > > > > > > On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote: > > > > > > I sent a v2 of this patch because it turns out I deleted a bit too > > > > > > much code. This function in particular, has to stay, unfortunately. > > > > > > When a batch is submitted with a SUBMIT_FENCE, this is used to push > > > > > > the work onto a different engine than than the one it's supposed to > > > > > > run in parallel with. This means we can't dead-code this function or > > > > > > the bond_execution function pointer and related stuff. > > > > > > > > > > Uh that's disappointing, since if I understand your point correctly, the > > > > > sibling engines should all be singletons, not load balancing virtual ones. > > > > > So there really should not be any need to pick the right one at execution > > > > > time. > > > > > > > > The media driver itself seems to work fine if I delete all the code. > > > > It's just an IGT testcase that blows up. I'll do more digging to see > > > > if I can better isolate why. > > > > > > I did more digging and I figured out why this test hangs. The test > > > looks at an engine class where there's more than one of that class > > > (currently only vcs) and creates a context where engine[0] is all of > > > the engines of that class bonded together and engine[1-N] is each of > > > those engines individually. It then tests that you can submit a batch > > > to one of the individual engines and then submit with > > > EXEC_FENCE_SUBMIT to the balanced engine and the kernel will sort it > > > out. This doesn't seem like a use-case we care about. > > > > > > If we cared about anything, I would expect it to be submitting to two > > > balanced contexts and expecting "pick any two" behavior. But that's > > > not what the test is testing for. > > > > Yeah ditch it. > > > > Instead make sure that the bonded setparam/ctx validation makes sure that > > 1) no virtual engines are used > > 2) no engine used twice > > 3) anything else stupid you can come up with that we should make sure is > > blocked. > > I've re-introduced the deletion and I'll add nuking that test to my > IGT series. I did it as a separate patch as the FENCE_SUBMIT logic > and the bonding are somewhat separate concerns. > > As far as validation goes, I don't think we need any more for this > case. You used FENCE_SUBMIT and didn't properly isolate things such > that the two run on different engines. Not our problem. Oh I just meant validating the bonded ctx extension thing. Not validating submit fence, that's rather hopeless since it really allows anything you can think of, by design. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel