On 2017年06月28日 04:50, Bas Nieuwenhuizen wrote:
On Tue, Jun 27, 2017 at 10:40 PM, Dave Airlie <airl...@gmail.com> wrote:
On 26 June 2017 at 19:10, zhoucm1 <david1.z...@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.
Thanks a lot for all your input.
Regards,
David Zhou
Dave.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
