[PATCH 1/3] drm/amdgpu: fix a typo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 27, 2017 at 10:40 PM, Dave Airlie <airlied at gmail.com> wrote:
> On 26 June 2017 at 19:10, zhoucm1 <david1.zhou at amd.com> wrote:
>>
>>
>> On 2017å¹´06æ??26æ?¥ 03:48, Dave Airlie wrote:
>>>>
>>>> Do you not use bo list at all in mesa? radv as well?
>>>
>>> Currently radv is creating a bo list per command submission. radv does
>>> not use an offload thread to do command submission, as it seems pretty
>>> un-vulkan to use a thread for the queue submission thread the game
>>> uses.
>>>
>>> I have considered investigating this, but with vulkan it's probably
>>> optimising for the single threaded case which isn't where apps should
>>> really be.
>>>
>>> At the moment we regenerate the bo list on every CS ioctl, we probably
>>> can do a lot better, I know Bas has looked into this area a bit more
>>> than I.
>>
>> Thanks Dave for inputting.
>>
>> Could I ask more about radv? How does radv make bo list for every cs ioctl?
>> Adding filter in every operation, any related bo will be add to bo list
>> during make command submission?
>
> When we create command buffers we add each bo to a list for it, but we
> don't call the kernel ioctl.
>
> When we get a QueueSubmit, we usually submit two IBs to the kernel,
> one with some cache flushes and one with the main IB in it, however as
> we have to give the kernel one bo list we have to combine the two
> lists (even if the cache flush list only has one ib in it, itself), so
> we can't call create bo list early, we have to do it just before
> command submission. However I don't think we've had any problems with
> this being our slow path yet, but this may change in the future.

Yeah. IIRC the bo list create is typically < 10% of our kernel time for radv.
>
> Dave.


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux