Received: by 10.213.65.68 with SMTP id h4csp1956599imn; Thu, 5 Apr 2018 06:44:07 -0700 (PDT) X-Google-Smtp-Source: AIpwx49uP4SAwYP6I8oT+4eIz/XxUVLpWkxWCasQlpKBnTIES6YvxrCL+ZqnKbvxdXam6Yq3jqbF X-Received: by 10.99.135.199 with SMTP id i190mr14760617pge.2.1522935847890; Thu, 05 Apr 2018 06:44:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522935847; cv=none; d=google.com; s=arc-20160816; b=Zl/yLyStv1ZVGd6/P7dSZvVgx8nPdr4kCrzTfv2yhXlZFgK0Pn5uVCnWKod9xiBcDY DCVoTHd1kN0k+0h410QGd6AXUGRUma07XX6myq+KKDKIZH/zV2aFeLijgMqgultWmSGM RQHwD3wZkbZAYygqM41sXiLsoW8n2Z9NL5azPNHioni2MU4wr2F/8QpVvcemf15SMBX5 7KCblvrWHkPdrYUF0ymvZm49ZnwRtK1VkOuSNupZcZSPW5CZAWrRh6dPAGw7MjR5IJpN IapVmZ7T2lw70kaKaZ/DqI/xuWXhOSPS3VdipvtSpGsXVg+tjAVcs2NZ8LVRg7FwSNZN AGkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=0MHFv4LvLEYV4SE8dy37CZw8i4sml9eNgvshu3LJbFs=; b=pYxaNUpYKe72rs+qBike3B3oKjossj26TpgkgEb0HA6XPFGXPoAPAEbTvOP13qWXMY iKI9GmOMLgmfRobjjsnUFo3pErxUlv+0mbbCfFlZXugZ43k0RmhsMO+SPE6FF2Y4bozJ xR+FW4fiqCWPEWmzFJJ11ch2AIFPXUm5vXHxrDF96HkbkZFAf7Mxktrlk+a+fuu4MqFt kiu367pDY9b8oNzveeyGUUVKGMTeHKALOFb6WAhEtXcCgQqdJbljZ2xV3hPz+owVfaaL SO5wn3ct9BhHZP5vFEDe03gHTSGTdKnQqBmuK85uE5Rvp1btSXl8xuE4SJ5C+fwvSd9b 5cUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rDpbsOC/; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h188si5464661pgc.330.2018.04.05.06.43.53; Thu, 05 Apr 2018 06:44:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rDpbsOC/; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751460AbeDENmk (ORCPT + 99 others); Thu, 5 Apr 2018 09:42:40 -0400 Received: from mail-pl0-f53.google.com ([209.85.160.53]:43543 "EHLO mail-pl0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751165AbeDENmj (ORCPT ); Thu, 5 Apr 2018 09:42:39 -0400 Received: by mail-pl0-f53.google.com with SMTP id c21-v6so15534005plz.10 for ; Thu, 05 Apr 2018 06:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0MHFv4LvLEYV4SE8dy37CZw8i4sml9eNgvshu3LJbFs=; b=rDpbsOC/78J3pNqMMdpYS2oucndHmXdJWTe/uM5Jw+2AaVb2B3GmR5+u+Rq6sJs5VA EGnmHWZLmtd0VHS7WYJGfqMTYMczHA7hf3ACoLq0mpdb+Gw5KGqmojmh/VFiLH1V/QTh DxOF9Ugmaqo8CTgDB1CZr4ncIi4fdkkmK2wjgM/NNlZUX7nl1KysqF2RUWWsVkVx3Vdu 9msVRjEMYjGex1rmY5gUhs7gk9OEReHMcTidBF87uBpVzsMmBt1+TTmX8jr2MByP4Op/ mVkdLEYJ8pbME9ggRZErBQI6Sa/HsjJ3p1zOiWAobQtBKvTsbB6wuq3cH6jaVwXnlQj9 9HOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0MHFv4LvLEYV4SE8dy37CZw8i4sml9eNgvshu3LJbFs=; b=Ahnm+TuaScvSGhQsRrtuT7RHkIAknvyv0NAfh9/looaAZFVurddeq99YXy9tyfnXLx 3cgA2JKmPL4Y0jGc47ARFFW7f1BhcEPpAqS2TSIw7bJYDers8u4GyGzdG488jCNEb8g0 XvmpY2Qqltb3Hh99b0hMdTHbr1Oqs1HtGPtLFXqklj/L8kgDzqf7HIJoZeWIuyV6lah0 A/eFlL6T9WGOL4heaIiNmku9yyzBanbNHNVtnX6wFKlXbiTGA7C9QH/NOdHxSGbwDtz1 Fded25R2ei5AL+YSYAgHFgvCJBJpDTHOlgwCj3mVJ2Js2UK8XB5oGGaQ9u2NHuazd3W8 7i5w== X-Gm-Message-State: AElRT7HzjUm02uMWKGg2EUCMtmFOwDx36wd3CPbYFCxNwFCQGbd9Kq2d rH1M3M1jwmNlyaFQOiMsDyT8Y4iA7Ns+YKP7vQM= X-Received: by 10.99.165.66 with SMTP id r2mr14948150pgu.452.1522935758650; Thu, 05 Apr 2018 06:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.167.138 with HTTP; Thu, 5 Apr 2018 06:41:58 -0700 (PDT) In-Reply-To: References: <20180404223251.28449-1-eric@anholt.net> From: Nayan Deshmukh Date: Thu, 5 Apr 2018 19:11:58 +0530 Message-ID: Subject: Re: [PATCH] drm/sched: Extend the documentation. To: Daniel Vetter Cc: Alex Deucher , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , dri-devel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 5, 2018 at 6:59 PM, Daniel Vetter wrote: > On Thu, Apr 5, 2018 at 3:27 PM, Alex Deucher wrote: >> On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter wrote: >>> On Thu, Apr 5, 2018 at 12:32 AM, Eric Anholt wrote: >>>> These comments answer all the questions I had for myself when >>>> implementing a driver using the GPU scheduler. >>>> >>>> Signed-off-by: Eric Anholt >>> >>> Pulling all these comments into the generated kerneldoc would be >>> awesome, maybe as a new "GPU Scheduler" chapter at the end of >>> drm-mm.rst? Would mean a bit of busywork to convert the existing raw >>> comments into proper kerneldoc. Also has the benefit that 0day will >>> complain when you forget to update the comment when editing the >>> function prototype - kerneldoc which isn't included anywhere in .rst >>> won't be checked automatically. >> >> I was actually planning to do this myself, but Nayan wanted to do this >> a prep work for his proposed GSoC project so I was going to see how >> far he got first. It is still on my TODO list. Just got a bit busy with my coursework. I will try to look at it during the weekend. > > Awesome. I'm also happy to help out with any kerneldoc questions and > best practices. Technically ofc no clue about the scheduler :-) > I was thinking of adding a different rst for scheduler altogther. Will it be better to add it in drm-mm.rst itself? > Cheers, Daniel >> Alex >> >>> -Daniel >>> >>>> --- >>>> include/drm/gpu_scheduler.h | 46 +++++++++++++++++++++++++++++++++---- >>>> 1 file changed, 42 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h >>>> index dfd54fb94e10..c053a32341bf 100644 >>>> --- a/include/drm/gpu_scheduler.h >>>> +++ b/include/drm/gpu_scheduler.h >>>> @@ -43,10 +43,12 @@ enum drm_sched_priority { >>>> }; >>>> >>>> /** >>>> - * A scheduler entity is a wrapper around a job queue or a group >>>> - * of other entities. Entities take turns emitting jobs from their >>>> - * job queues to corresponding hardware ring based on scheduling >>>> - * policy. >>>> + * drm_sched_entity - A wrapper around a job queue (typically attached >>>> + * to the DRM file_priv). >>>> + * >>>> + * Entities will emit jobs in order to their corresponding hardware >>>> + * ring, and the scheduler will alternate between entities based on >>>> + * scheduling policy. >>>> */ >>>> struct drm_sched_entity { >>>> struct list_head list; >>>> @@ -78,7 +80,18 @@ struct drm_sched_rq { >>>> >>>> struct drm_sched_fence { >>>> struct dma_fence scheduled; >>>> + >>>> + /* This fence is what will be signaled by the scheduler when >>>> + * the job is completed. >>>> + * >>>> + * When setting up an out fence for the job, you should use >>>> + * this, since it's available immediately upon >>>> + * drm_sched_job_init(), and the fence returned by the driver >>>> + * from run_job() won't be created until the dependencies have >>>> + * resolved. >>>> + */ >>>> struct dma_fence finished; >>>> + >>>> struct dma_fence_cb cb; >>>> struct dma_fence *parent; >>>> struct drm_gpu_scheduler *sched; >>>> @@ -88,6 +101,13 @@ struct drm_sched_fence { >>>> >>>> struct drm_sched_fence *to_drm_sched_fence(struct dma_fence *f); >>>> >>>> +/** >>>> + * drm_sched_job - A job to be run by an entity. >>>> + * >>>> + * A job is created by the driver using drm_sched_job_init(), and >>>> + * should call drm_sched_entity_push_job() once it wants the scheduler >>>> + * to schedule the job. >>>> + */ >>>> struct drm_sched_job { >>>> struct spsc_node queue_node; >>>> struct drm_gpu_scheduler *sched; >>>> @@ -112,10 +132,28 @@ static inline bool drm_sched_invalidate_job(struct drm_sched_job *s_job, >>>> * these functions should be implemented in driver side >>>> */ >>>> struct drm_sched_backend_ops { >>>> + /* Called when the scheduler is considering scheduling this >>>> + * job next, to get another struct dma_fence for this job to >>>> + * block on. Once it returns NULL, run_job() may be called. >>>> + */ >>>> struct dma_fence *(*dependency)(struct drm_sched_job *sched_job, >>>> struct drm_sched_entity *s_entity); >>>> + >>>> + /* Called to execute the job once all of the dependencies have >>>> + * been resolved. This may be called multiple times, if >>>> + * timedout_job() has happened and drm_sched_job_recovery() >>>> + * decides to try it again. >>>> + */ >>>> struct dma_fence *(*run_job)(struct drm_sched_job *sched_job); >>>> + >>>> + /* Called when a job has taken too long to execute, to trigger >>>> + * GPU recovery. >>>> + */ >>>> void (*timedout_job)(struct drm_sched_job *sched_job); >>>> + >>>> + /* Called once the job's finished fence has been signaled and >>>> + * it's time to clean it up. >>>> + */ >>>> void (*free_job)(struct drm_sched_job *sched_job); >>>> }; >>>> >>>> -- >>>> 2.17.0 >>>> >>>> _______________________________________________ >>>> dri-devel mailing list >>>> dri-devel@lists.freedesktop.org >>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> >>> >>> -- >>> Daniel Vetter >>> Software Engineer, Intel Corporation >>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel