Search Issue Tracker

By Design

Votes

1

Found in

5.4.0b21

Issue ID

805310

Regression

No

[Graphics.DrawMesh] triggering "String.memcpy" for massive slowdowns

Graphics - General

-

Reproduction steps:
1. Open attached "stripped" project.
2. Open "EditorMap.scene".
3. Open "Window > Profiler" tab.
4. Enable "Deep Profile".
5. Expand "BehaviourUpdate->VirtualizeScene.Update()->VirtualizeScene.Draw()->Graphics.DrawMesh()" and notice the "String.memcpy"(Picture attached).

  1. Resolution Note (5.3.7):

    Using the last expansion of DrawMesh will result in a performance improvement. Additionally, in 5.4 you can use Standard Surface Shader (Instanced) in order to benefit even more.

Log in to vote on this issue

Comments (3)

  1. Arycama

    Sep 11, 2019 02:51

    This is not fixed in 2019.2.0f1. Most variants of Graphics.DrawMesh call other overloads of Graphics.DrawMesh, which finally calls Graphics.DrawMeshInternal. This causes a string.memcpy to be called for every call, which ends up with 3-4 string.memcpys per frame.

  2. holoben22

    Jan 02, 2019 21:06

    Is there an explanation posted somewhere for why this is by design? Is it an artifact of running the deep profiler? Or does it have something to do with copying data to the GPU in the Graphics.DrawMesh function?

  3. Selmar

    Jul 09, 2016 02:40

    The memcpy and memset together are approximately 80% of the cost for me.

    I tried to work around it using CommandBuffers, but I can't get them to work properly, so I'm not even sure if that works with instancing.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.

Latest issues

See all new issues