Heya,
I'm doing some open-source hobby research on neurological rendering, i.e. rendering exploiting the quirks of human vision, and the experimental code targets macos on Apple Silicon. As the rendering is very FPS-sensitive, I'm collecting GPU performance results from various Apple Silicon macos devices for the performance table here:
github.com
If you have access to a 120Hz (or higher!) macos desktop with Xcode on Apple Silicon, and you have the spare machine and human cycles to build and run some tests, your results would be welcome!
In that table I'm looking for the largest resolution that runs stably at the device's max desktop refresh rate. In order to tell that the observer (you) should run a full timeline sequence which takes approx 166 seconds from start to finish, and watch for performance warnings in the terminal output. If none are observed, then the test is considered a success, and we can peg that in the table.
Controlling the resolution and refresh rate is done via CLI option -screen, and the test duration via CLI option -frames, so a test run looks like this:
$ /usr/bin/time -p ./problem_7 -screen "width heigh Hz" -frames Hz_dependent_number_of_frames_to_run
where width should be a multiple of 32, and heigh multiple of 16, as the default threadgroup geometry of the employed compute kernel is 32x16, and it's generally preferred to stay at that. As implied, the Hz-dependent number of frames is a function of the Hz that we specify and what portion of the timeline we want to see. At 60 Hz the full timeline would be 10000 frames; at 120 Hz that would be 20000 frames. You can compute the exact number as 166.667 * Hz, e.g. 166.667 * 60 = 10000, 166.667 * 120 = 20000, etc. Naturally, the time duration of the test should be between 166.667 and 167 seconds. If it's outside of that span and/or the app spat out performance warnings, the test swamped the machine and results are not useful. Naturally, for meaningful results your GPU should be idle before running the test.
A basic tactic for quickly reaching the best performance result would be to set the intended resolution & Hz on a few seconds run, say 10, see if that goes well, then run the full timeline to verify it's actually good.
Ok, that's it. Thank you for reading up to this point!
Needless to say, I'll be monitoring this thread for any contributions.
Regards,
Martin
I'm doing some open-source hobby research on neurological rendering, i.e. rendering exploiting the quirks of human vision, and the experimental code targets macos on Apple Silicon. As the rendering is very FPS-sensitive, I'm collecting GPU performance results from various Apple Silicon macos devices for the performance table here:
GitHub - blu/metal_prob_7: Musings in neurological rendering
Musings in neurological rendering. Contribute to blu/metal_prob_7 development by creating an account on GitHub.
github.com
If you have access to a 120Hz (or higher!) macos desktop with Xcode on Apple Silicon, and you have the spare machine and human cycles to build and run some tests, your results would be welcome!
In that table I'm looking for the largest resolution that runs stably at the device's max desktop refresh rate. In order to tell that the observer (you) should run a full timeline sequence which takes approx 166 seconds from start to finish, and watch for performance warnings in the terminal output. If none are observed, then the test is considered a success, and we can peg that in the table.
Controlling the resolution and refresh rate is done via CLI option -screen, and the test duration via CLI option -frames, so a test run looks like this:
$ /usr/bin/time -p ./problem_7 -screen "width heigh Hz" -frames Hz_dependent_number_of_frames_to_run
where width should be a multiple of 32, and heigh multiple of 16, as the default threadgroup geometry of the employed compute kernel is 32x16, and it's generally preferred to stay at that. As implied, the Hz-dependent number of frames is a function of the Hz that we specify and what portion of the timeline we want to see. At 60 Hz the full timeline would be 10000 frames; at 120 Hz that would be 20000 frames. You can compute the exact number as 166.667 * Hz, e.g. 166.667 * 60 = 10000, 166.667 * 120 = 20000, etc. Naturally, the time duration of the test should be between 166.667 and 167 seconds. If it's outside of that span and/or the app spat out performance warnings, the test swamped the machine and results are not useful. Naturally, for meaningful results your GPU should be idle before running the test.
A basic tactic for quickly reaching the best performance result would be to set the intended resolution & Hz on a few seconds run, say 10, see if that goes well, then run the full timeline to verify it's actually good.
Ok, that's it. Thank you for reading up to this point!
Needless to say, I'll be monitoring this thread for any contributions.
Regards,
Martin
Last edited:
