All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhang, Jerry (Junwei)" <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
To: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>,
	"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>
Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH] drm/amdgpu: Reserve fence slots for command submission
Date: Wed, 4 Jul 2018 17:23:29 +0800	[thread overview]
Message-ID: <5B3C9211.3040303@amd.com> (raw)
In-Reply-To: <6a23190d-dafe-956d-793e-c0100f3d405c-otUistvHUpPR7s880joybQ@public.gmane.org>

On 07/04/2018 05:15 PM, Michel Dänzer wrote:
> On 2018-07-04 11:01 AM, Christian König wrote:
>> Am 04.07.2018 um 09:57 schrieb Zhang, Jerry (Junwei):
>>> On 07/04/2018 03:21 PM, Michel Dänzer wrote:
>>>> On 2018-07-04 08:55 AM, Zhang, Jerry (Junwei) wrote:
>>>>> On 07/04/2018 02:34 PM, Christian König wrote:
>>>>>> Am 04.07.2018 um 05:02 schrieb Junwei Zhang:
>>>>>>> From: Michel Dänzer <michel.daenzer@amd.com>
>>>>>>>
>>>>>>> Without this, there could not be enough slots, which could trigger
>>>>>>> the
>>>>>>> BUG_ON in reservation_object_add_shared_fence.
>>>>>>>
>>>>>>> v2:
>>>>>>> * Jump to the error label instead of returning directly (Jerry Zhang)
>>>>>>> v3:
>>>>>>> * Reserve slots for command submission after VM updates (Christian
>>>>>>> König)
>>>>>>>
>>>>>>> Cc: stable@vger.kernel.org
>>>>>>> Bugzilla: https://bugs.freedesktop.org/106418
>>>>>>> Reported-by: mikhail.v.gavrilov@gmail.com
>>>>>>> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
>>>>>>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
>>>>>>
>>>>>> I would put that at the end of amdgpu_bo_vm_update_pte(), but that is
>>>>>> only a minor nit pick.
>>>>>
>>>>> At first, I really put it at the end of amdgpu_bo_vm_update_pte().
>>>>> On the 2nd thought, that func may be called by others(although it's not
>>>>> for now), so I move it out of there to the caller.
>>
>> Well that is exactly the reason I wanted to have it in
>> amdgpu_bo_vm_update_pte() :)
>>
>> But you are right, there are good arguments for both approach and as
>> long as we don't have a second user it doesn't matter.
>
> In general, I think it's better to keep the
> reservation_object_reserve_shared calls as close as possible to the
> corresponding reservation_object_add_shared_fence calls, otherwise it's
> hard to keep track of whether or not a slot is reserved at any given point.

Agree, I also consider that previously, just before the command submission.
while I think 2 more things then:

1) amdgpu_cs_ib_vm_chunk() is unique func during cs ioctl,
in another word, it's a MUST part of that, so it will not impact others.
Additionally it also checks if vm used, otherwise, the reserve is not needed either.

2) adding the reserve with vm checking in amdgpu_cs_submit() looks not so good as well.
IMO. so I decide to insert that in amdgpu_cs_ib_vm_chunk() vm existing case.

BTW, we may add some comments in code as well to better reference in the future.

Jerry

>
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2018-07-04  9:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-04  3:02 [PATCH] drm/amdgpu: Reserve fence slots for command submission Junwei Zhang
2018-07-04  3:02 ` Junwei Zhang
2018-07-04  6:34 ` Christian König
2018-07-04  6:55   ` Zhang, Jerry (Junwei)
2018-07-04  6:55     ` Zhang, Jerry (Junwei)
     [not found]     ` <5B3C6F7B.80901-5C7GfCeVMHo@public.gmane.org>
2018-07-04  7:21       ` Michel Dänzer
     [not found]         ` <9fd5d981-3725-289b-94ff-73da521e3061-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-04  7:57           ` Zhang, Jerry (Junwei)
     [not found]             ` <5B3C7DE6.3020405-5C7GfCeVMHo@public.gmane.org>
2018-07-04  9:01               ` Christian König
     [not found]                 ` <9211988c-b543-e0b1-7598-59cad147fb28-5C7GfCeVMHo@public.gmane.org>
2018-07-04  9:15                   ` Michel Dänzer
     [not found]                     ` <6a23190d-dafe-956d-793e-c0100f3d405c-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-04  9:23                       ` Zhang, Jerry (Junwei) [this message]
2018-07-04 14:00               ` Michel Dänzer
2018-07-04  9:02           ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5B3C9211.3040303@amd.com \
    --to=jerry.zhang-5c7gfcevmho@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
    --cc=michel-otUistvHUpPR7s880joybQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.