little and big cores on mobile as well as frequency scaling can muddy the waters and you have no info on core affinity. What I described would give you a rather imperfect metric as you wouldn't know which cores are doing what. I was mostly trying to gauge what info exactly you wanted to see here and get a better understanding of the underlying problem you'd like to solve. The documentation pages I linked to and related pages do contain some samples though and we'll look at extending those.Īlso, we do not have any hardware counters yet, so we can't give percentages of how much unity is utilizing the maximum possible computing power of all the cores and the GPU in the same way as a system monitor would show, in percentages. There is indeed not a single comprehensive sample script that would encompass all of what I've outlined above. Once you know how many threads there were in total, (through the Recorder handles or other means), you can record "Idle" across all threads, divide it by the thread count and thereby get the inverse: how busy the threads were on average. You can use ProfilerRecorderHandle.GetAvailable() to get all of these names too and with that, check which threads are actually around and under which name. The same Worker thread would then just have less time in the following frame since it flipped over later. if there was a job at the end of the frame, it might have lapsed more into the next frame. but, really, what that is gonna give you is only how long each worker thread was around for until it got flipped to the next frame, roughly in sync with "Main Thread", so really, this will be the frame time, give or take some if. Now besides starting a Recorder in a Job, you CAN record "Job.Worker 0" "Job.Worker 1". You can also potentially subtract (or track separately) "Gfx.Present" Then you can use the measurements from the second one to calculate the However, the Render Main Camera sample usually also occurs on the Main Thread so you'll likely want to have 2 ProfilerRecorders recording that sample: one recording all threads, one recording the Main Thread only. You can Record "Render Thread" but it might be more meaningful to record some of the other root level samples such as the Render Main Camera samples (check the correct name depending on the render pipeline you are using in the Profiler). You can Record "Main Thread", "PlayerLoop", "EditorLoop". How exactly would you like to Profile the different threads? Just the time they were busy for? What if there are more threads than cores (or even virtual, hyper threaded cores)? Are you more interested in how active the different cores were or how active the different threads were? However, I have a feeling that, what you are interested in could possibly be gathered in a different way. That would mostly allow you to specifically record data on the Main Thread, a custom C# threads or a Job Thread (with admittedly little control over which Worker thread this would happen on because you can't specify that for the Job that would start the Recorder), but not the Render Thread, unless you want to modify code in an SRP I guess, or any other Unity threads like the background and loading threads. You can limit it to only record the data for the current thread, i.e. ProfilerRecorder already allows you to record ms timings from any thread so I'd like to know what exactly you'd like to do here.īy default, ProfilerRecorder will record data for a sample across all threads. That means that: Yes, we are working towards supporting GPU timings to be recorded with ProfilerRecorder as well. Unfortunately, as explained over here too, we built yourselves into a bit of a corner with this old API which we'll sadly have to abandon once ProfilerRecorder covers all Use Cases that it covered so far. Currently, GPU Timings can only be recorder with the old Recorder via the gpuElapsedNanoseconds API that was added in 2020.1.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |