-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show task performance #445
base: master
Are you sure you want to change the base?
Conversation
Looks like my "meshgen" was just more lighting under the hood. Updated to reflect that. |
It crashes with division by zero error when I try it:
|
Is my divFloor different from yours? |
I don't know. Maybe you didn't test it in debug mode? |
Building in debug mode takes extra steps because zig ld crashes. |
Does it crash in release mode? |
Could you send me the issue link? Then we can add it to #308 |
It also crashes in release, looking at gdb it seems to be the same issue: Thread 1 "Cubyzig" received signal SIGFPE, Arithmetic exception.
0x000000000110878c in windows.debug.render () at /home/mint/Downloads/Cubyz/src/gui/windows/debug.zig:52
52 draw.print(" " ++ name ++ " time: {} ms ({} µs/task)", .{@divFloor(perf.utime[i], 1000), @divFloor(perf.utime[i], perf.tasks[i])}, 0, y, 8, .left); |
Resolved both complaints. |
It's really hard to read anything here. The numbers seem to get reset every frame: video-2024-06-06_08.17.52.mp4 |
In my defense, it is quite legible at 10 fps. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of ideas how to improve it. Also zig reported a memory leak:
memory address 0x7fa9aed53040 leaked:
/home/mint/Downloads/Cubyz/src/utils.zig:627:31: 0x13250c2 in create__anon_13927 (Cubyzig)
return self.allocator.create(T) catch unreachable;
^
/home/mint/Downloads/Cubyz/src/utils.zig:1040:35: 0x13152e5 in init (Cubyzig)
.performance = allocator.create(Performance),
^
/home/mint/Downloads/Cubyz/src/main.zig:356:36: 0x1313028 in main (Cubyzig)
threadPool = utils.ThreadPool.init(globalAllocator, @max(1, (std.Thread.getCpuCount() catch 4) -| 1));
^
/home/mint/Cubyz/compiler/zig/lib/std/start.zig:501:22: 0x1312b49 in main (Cubyzig)
root.main();
^
const perf = main.threadPool.getPerformance(); | ||
const values = comptime std.enums.values(TaskType); | ||
inline for(values) |t| { | ||
const name = switch (t) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just use @tagName
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To separate source code and rendering options. Suppose we added localization?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Debug info does not need to be translated, since it shouldn't be used by the majority of players.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose that will be a secondary concern after we get any localization in place.
chunkgen, | ||
lighting, | ||
misc, | ||
taskTypes, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of having a C-style enum length field, I think it would be better to use std.enums.directEnumArrayLen
to determine the length instead.
This would also make it possible to use @tagName
above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sometimes I wonder if Zig devs have a naming scheme.
taskType: TaskType = .misc, | ||
}; | ||
pub const Performance = struct { | ||
mutex: std.Thread.Mutex = .{}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would be a great place to use atomics with monotonic ordering instead of locking.
@@ -633,6 +633,7 @@ pub const ChunkMesh = struct { | |||
.isStillNeeded = @ptrCast(&isStillNeeded), | |||
.run = @ptrCast(&run), | |||
.clean = @ptrCast(&clean), | |||
.taskType = .lighting, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I just noticed you have three .lighting tasks, but they do completely different things.
Having multiple tasks with the same tag can hide performance problems. For example, this LightRefreshTask is relatively fast, which can skew the average mesh generation time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wouldn't be hard to change. Is there a better classification? I literally just classified it based on my impressions of the performance problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would just put the LightRefreshTaks and the LightMapLoadTask under .misc, they shouldn't take much performance.
Notes:
.misc
if the task doesn't take a significant amount of time