From: zhoucm1 <david1.zhou-5C7GfCeVMHo@public.gmane.org>
To: "Christian König"
<deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>,
axie <axie-5C7GfCeVMHo@public.gmane.org>,
"Marek Olšák" <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"Xie, AlexBin" <AlexBin.Xie-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 1/3] drm/amdgpu: fix a typo
Date: Fri, 23 Jun 2017 17:08:34 +0800 [thread overview]
Message-ID: <594CDA92.1060809@amd.com> (raw)
In-Reply-To: <594CD8E0.3080702-5C7GfCeVMHo@public.gmane.org>
On 2017年06月23日 17:01, zhoucm1 wrote:
>
>
> On 2017年06月23日 16:25, Christian König wrote:
>> Am 23.06.2017 um 09:09 schrieb zhoucm1:
>>>
>>>
>>> On 2017年06月23日 14:57, Christian König wrote:
>>>> But giving the CS IOCTL an option for directly specifying the BOs
>>>> instead of a BO list like Marek suggested would indeed save us some
>>>> time here.
>>> interesting, I always follow how to improve our cs ioctl, since UMD
>>> guys aften complain our command submission is slower than windows.
>>> Then how to directly specifying the BOs instead of a BO list? BO
>>> handle array from UMD? Could your guys describe more clear? Is it
>>> doable?
>>
>> Making the BO list part of the CS IOCTL wouldn't help at all for the
>> close source UMDs. To be precise we actually came up with the BO list
>> approach because of their requirement.
>>
>> The biggest bunch of work during CS is reserving all the buffers,
>> validating them and checking their VM status.
> Totally agree. Every time when I read code there, I often want to
> optimize them.
>
>> It doesn't matter if the BOs come from the BO list or directly in the
>> CS IOCTL.
>>
>> The key point is that CS overhead is pretty much irrelevant for the
>> open source stack, since Mesa does command submission from a separate
>> thread anyway.
> If irrelevant for the open stack, then how does open source stack
> handle "The biggest bunch of work during CS is reserving all the
> buffers, validating them and checking their VM status."?
> If open stack has a better way, I think closed stack can follow it, I
> don't know the history.
Do you not use bo list at all in mesa? radv as well?
Regards,
David Zhou
>
> Regards,
> David Zhou
>>
>> Regards,
>> Christian.
>>
>>>
>>> Regards,
>>> David Zhou
>>
>>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2017-06-23 9:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 2:42 [PATCH 1/3] drm/amdgpu: fix a typo Alex Xie
[not found] ` <1498099356-31332-1-git-send-email-AlexBin.Xie-5C7GfCeVMHo@public.gmane.org>
2017-06-22 2:42 ` [PATCH 2/3] drm/amdgpu: change a function to static function Alex Xie
[not found] ` <1498099356-31332-2-git-send-email-AlexBin.Xie-5C7GfCeVMHo@public.gmane.org>
2017-06-22 2:54 ` Michel Dänzer
2017-06-22 2:42 ` [PATCH 3/3] drm/amdgpu: optimize out a spin lock Use atomic instead of spin lock Alex Xie
2017-06-22 7:35 ` [PATCH 1/3] drm/amdgpu: fix a typo Christian König
[not found] ` <5ff65f82-9d15-4606-7e25-e4f75c172aed-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-22 15:33 ` Xie, AlexBin
[not found] ` <DM5PR12MB1257B1FCC981D29A6D4045CDF2DB0-2J9CzHegvk/NHlLGalgXawdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-06-22 16:24 ` Christian König
2017-06-22 16:27 ` Marek Olšák
[not found] ` <CAAxE2A7ic2YLmnkzM0Faa3bO9-GwWRTHRc0EUVej5UU7Yhs4Qg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-22 17:34 ` axie
[not found] ` <efc2289a-382d-8443-8419-da2d0cadfd77-5C7GfCeVMHo@public.gmane.org>
2017-06-22 18:19 ` axie
[not found] ` <e23f64c3-6abf-ff65-2300-5c44d242f4df-5C7GfCeVMHo@public.gmane.org>
2017-06-22 23:54 ` Marek Olšák
[not found] ` <CAAxE2A61KqM9gr=Zoo5PHFNb8gWp74RG9KOs=efWzf1dMKBwSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-23 2:23 ` axie
[not found] ` <7134d81f-a60f-7093-d2a3-70edde23cdb2-5C7GfCeVMHo@public.gmane.org>
2017-06-23 6:57 ` Christian König
[not found] ` <3436ae97-39b1-4a3f-bb73-2991adad5715-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-23 7:09 ` zhoucm1
[not found] ` <594CBEBC.5010703-5C7GfCeVMHo@public.gmane.org>
2017-06-23 8:25 ` Christian König
[not found] ` <0d847baf-8296-f3ce-7a8d-8823f33e392e-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-23 9:01 ` zhoucm1
2017-06-23 9:01 ` zhoucm1
[not found] ` <594CD8E0.3080702-5C7GfCeVMHo@public.gmane.org>
2017-06-23 9:08 ` zhoucm1 [this message]
[not found] ` <594CDA92.1060809-5C7GfCeVMHo@public.gmane.org>
2017-06-23 9:27 ` Christian König
[not found] ` <807f27d6-7e53-4066-c440-699bf66dd227-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-23 10:49 ` Marek Olšák
[not found] ` <CAAxE2A4vdV+QD55RAn+mrD92o39X_vPT6wLKCwkREx2=fpU2Vw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-23 11:55 ` Zhou, David(ChunMing)
[not found] ` <MWHPR1201MB02063CAC83DEEAB81EFA9A10B4D80-3iK1xFAIwjrUF/YbdlDdgWrFom/aUZj6nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2017-06-24 0:29 ` Marek Olšák
[not found] ` <CAAxE2A7jmhxC8SctSSxXhc7XRwSgzmPOOF5HmmtAPL7aYKE+Jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-24 20:49 ` Marek Olšák
2017-06-26 9:06 ` Michel Dänzer
2017-06-25 19:48 ` Dave Airlie
[not found] ` <CAPM=9tzXrih9qpkOY+OGC1TF8nD0ZmwNnxXiRbMtcO7tR1-m1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-26 9:10 ` zhoucm1
[not found] ` <5950CFA0.90906-5C7GfCeVMHo@public.gmane.org>
2017-06-27 20:40 ` Dave Airlie
[not found] ` <CAPM=9tw-E39oQ1gRPJs3oZBniALzgoa53ErF-trgxiN8Z9xyww-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-27 20:50 ` Bas Nieuwenhuizen
[not found] ` <CAP+8YyGouX0AeBxj+UNmb1Q7iwAzt0Z_hx__hf1Bb=YqC55J_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-28 2:00 ` zhoucm1
2017-06-23 11:37 ` Marek Olšák
[not found] ` <CAAxE2A6Tt1JzLCDr4vM1iKASpWGFncqrXkL75==1Zd5wJq8xTA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-23 13:01 ` Christian König
[not found] ` <963f4d3d-dc46-2279-509f-b475c5ec94ee-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-23 13:55 ` axie
[not found] ` <3d4f3204-6893-3d68-23ea-b309ace33740-5C7GfCeVMHo@public.gmane.org>
2017-06-23 14:30 ` Christian König
2017-06-24 0:27 ` Marek Olšák
[not found] ` <CAAxE2A7kFusP3=-FcVWdSnGRvaFwL8kZ17BH4uKJ3z044S9XFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-24 18:27 ` Christian König
2017-06-23 13:45 ` axie
[not found] ` <94b20fb6-3f81-da3c-eb44-7d2e49ff5c8b-5C7GfCeVMHo@public.gmane.org>
2017-06-24 0:46 ` Marek Olšák
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=594CDA92.1060809@amd.com \
--to=david1.zhou-5c7gfcevmho@public.gmane.org \
--cc=AlexBin.Xie-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=axie-5C7GfCeVMHo@public.gmane.org \
--cc=deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org \
--cc=maraeo-Re5JQEeQqe8AvxtiuMwx3w@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.