School of Computing: assessment brief
Module title Computer Graphics
Module code COMP3811
Assignment title Coursework 1
Assignment type
and description
Programming assignment: Graphics fundamentals
Rationale
The coursework revolves around fundamental graphics
operations and data types. These include images and the
manipulation thereof, drawing primitives such as lines
and triangles, and blitting images.
Page limit and guidance
Report:
 8 A4 pages with 2cm or larger margins, 10pt
font size (including ffgures). You are allowed to use a
double-column layout. Code: no limit. Please read
the submission instructions carefully!
Weighting 50%
Submission deadline
2024-1**07
 14:00
Submission method Gradescope: code and report
Feedback provision Written notes
Learning outcomes
assessed
Understanding, description and utilization of standard
methods to programmatically create and manipulate
images. Understanding, description, application and
evaluation of fundamental algorithms and methods in
computer graphics.
Module lead Markus Billeter
i1. Assignment guidance
In the first coursework, you are tasked with implementing several drawing functions
for primitive graphics operations. These include drawing lines, triangles and blitting
images. You will verify that these functions work correctly and analyze their behaviour.
Before starting your work, please study the coursework document in its entirety. Pay
special attention to the requirements and submission information. Plan your work. It
might be better to focus on a subset of tasks and commit to these fully than to attempt
everything in a superficial way.
2. Assessment tasks
Please see detailed instructions in the document following the standardized assessment
brief (pages i-iv). The work is split into several tasks, accounting for 50% of the total
module grade.
3. General guidance and study support
Please refer to materials handed out during the module, specifically the tutorial-style
exercises for 2D graphics and maths.
Support is primarily provided during scheduled lab hours. Support for general issues
may be provided through the module’s “Teams” channel. Do not expect answers
outside of scheduled hours. Do not post specific issues relating to your code in the
public Teams channels. Do not crosspost across multiple channels.
4. Assessment criteria and marking process
Submissions take place through Gradescope. Valid submissions will be marked
primarily based on the report and secondarily based on the submitted code. See
following sections for details on submission requirements and on requirements on
the report. Marks and feedback will be provided through Minerva (and not through
Gradescope - Gradescope is only used for submissions!).
5. Submission requirements
Your coursework will be graded once you have
(a) Submitted required files (code and report) through Gradescope.
(b) If deemed necessary, participated in an extended interview with the instructor(s)
where you explain your submission in detail.
Your submission will consist of source code and a report (≲ 8 pages). The report is
the basis for assessment. The source code is supporting evidence for claims made in
the report. Tasks/results without supporting code will receive zero marks.
Submissions are made through Gradescope (do not send your solutions by email!).
You can use any of Gradescope’s mechanisms for uploading the complete solution
and report. In particular, Gradescope accepts .zip archives (you should see the
iicontents of them when uploading to Gradescope). Do not use other archive formats
(Gradescope must be able to unpack them!). Gradescope will run preliminary checks
on your submission and indicate whether it is considered a valid submission.
The source code must compile and run as submitted on the standard SoC machines
found in the UG teaching lab (2.05 in Bragg). Your code must compile cleanly, i.e.,
it should not produce any warnings. If there are singular warnings that you cannot
resolve or believe are in error, you must list these in your report and provide an
explanation of what the warning means and why it is acceptable in your case. This is
not applicable for easily fixed problems and other bulk warnings (for example, type
conversions) – you are always expected to correct the underlying issues for such. Do
not change the warning level defined in the handed-out code. Disabling individual
warnings through various means will still require documenting them in the report.
Your submission must not include any “extra” files that are not required to build
or run your submission (aside from the report). In particular, you must not include
build artifacts (e.g. final binaries, .o files, ...), temporary files generated by your IDE
or other tools (e.g. .vs directory and contents) or files used by version control (e.g.
.git directory and related files). Note that some of these files may be hidden by
default, but they are almost always visible when inspecting the archive with various
tools. Do not submit unused code (e.g. created for testing). Submitting unnecessary
files may result in a deduction of marks.
While you are encouraged to use version control software/source code management
software (such as git or subversion), you must not make your solutions publicly
available. In particular, if you wish to use Github, you must use a private repository.
You should be the only user with access to that repository.
6. Presentation and referencing
Your report must be a single PDF file called report.pdf. In the report, you must list
all tasks that you have attempted and describe your solutions for each task. Include
screenshots for each task unless otherwise noted in the task description! You may
refer to your code in the descriptions, but descriptions that just say “see source
code” are not sufficient. Do not reproduce bulk code in your report. If you wish to
highlight a particularly clever method, a short snippet of code is acceptable. Never
show screenshots/images of code - if you wish to include code, make sure it is rendered
as text in the PDF using appropriate formatting and layout. Screenshots must be
of good quality (keep the resolution at 1280×720 or higher, but scale them down
in the PDF). Don’t compress the screenshots overly much (e.g., visible compression
artifacts).
Apply good report writing practices. Structure your report appropriately. Use whole
English sentences. Use appropriate grammar, punctuation and spelling. Provide figure
captions to figures/screenshots, explaining what the figure/screenshot is showing and
what the reader should pay attention to. Refer to figures from your main text. Cite
external references appropriately.
iiiFurthermore, the UoL standard practices apply:
The quality of written English will be assessed in this work. As a minimum, you must
ensure:
• Paragraphs are used
• There are links between and within paragraphs although these may be ineffective
at times
• There are (at least) attempts at referencing
• Word choice and grammar do not seriously undermine the meaning and comprehensibility
of the argument
• Word choice and grammar are generally appropriate to an academic text
These are pass/ fail criteria. So irrespective of marks awarded elsewhere, if you do
not meet these criteria you will fail overall.
7. Academic misconduct and plagiarism
You are encouraged to research solutions and use third-party resources. If you find
such, you must provide a reference to them in your report (include information about
the source and original author(s)). Never “copy-paste” code from elsewhere – all code
must be written yourself. If the solution is based on third party code, make sure to
indicate this in comments surrounding your implementation in your code, in addition
to including a reference in your report. It is expected that you fully understand all
code that you hand in as part of your submission. You may be asked to explain any
such code as part of the marking process. If deemed necessary, you may be asked
to attend a short individual interview with the instructor(s), where you are asked to
explain specific parts of your submission.
Furthermore, the UoL standard practices apply:
Academic integrity means engaging in good academic practice. This involves essential
academic skills, such as keeping track of where you find ideas and information and
referencing these accurately in your work.
By submitting this assignment you are confirming that the work is a true expression
of your own work and ideas and that you have given credit to others where their work
has contributed to yours.
8. Assessment/marking criteria grid
(See separate document.)
ivCOMP3811
Coursework 1
Contents
1 Tasks 1
1.1 Setting Pixels . . . . . . . 2
1.2 Drawing Lines . . . . . . 2
1.3 2D Rotation . . . . . . . 3
1.4 Drawing triangles . . . . 4
1.5 Blitting images . . . . . . 4
1.6 Testing: lines . . . . . . . 4
1.7 Testing: triangles . . . . 5
1.8 Benchmark: Blitting . . . 5
1.9 Benchmark: Line drawing 6
1.10 Your own space ship . . 6
Coursework 1 focuses on basic graphics operations in 2D, including manipulating images, drawing lines and
triangles, and blitting images. Coursework 1 is to be solved individually and determines 50% of the total
mark for COMP3811.
Before starting work on the tasks below, study this document in its entirety. Plan your work. It is likely better
to focus on a subset of tasks and commit to these fully than to attempt everything in a superficial way. For the
purpose of planning, you may consider tasks in Sections 1.6 to 1.9 to be (more) advanced tasks. You may want
to hold off on these until you have completed other tasks.
While you are encouraged to use version control software/source code management software (such as git or subversion),
you must not make your solutions publicly available. In particular, if you wish to use Github, you must use a private
repository. You should be the only user with access to that repository.
You are allowed to discuss ideas with your colleagues. However, do not share your code with anybody else.
You must program independently and not base your submission on any code other than what has been provided
with the coursework and/or in the exercises for COMP3811. As a special exception, you may reuse code
from COMP3811 exercises that was handed out (including briefs) or that you are the sole author of.
Use good commenting practices to explain your approach and solution. Good, thoughtful and well-written
comments will help you show that you understand your code. It will also decrease the chances of accidentally
ending up with submissions similar to other’s work.
Coursework 1 will not require you to use any third-party software outside of what is included in the handedout
code. You are therefore not allowed to use additional third-party libraries.
1 Tasks
Start by downloading the Coursework 1 base code. Make sure you are able to build it. If necessary, refer to the
first exercise handed out in COMP3811. It uses the same base structure and includes detailed instructions to
get you started.
The Coursework 1 base code includes several subprojects. Some of them you will have already encountered
in exercises. Others are specific to the coursework.2 COMP3811 - Coursework 1
• main, a program which combines elements from all tasks to draw a game-like 2D environment.
• draw2d, a library where you implement the various drawing functions.
• vmlib, a library for linear algebra/math-related functions.
• support, a library with some helper functions relating to setup and on-screen display.
• lines-sandbox, a simple graphical program that only draws lines. Use it for quick visual testing.
• lines-test, a program for automated tests relating to line drawing.
• lines-benchmark, a program for automated benchmarks relating to line drawing.
• triangles-sandbox, a graphical program that only draws triangles. Use it for quick visual testing.
• triangles-test, a program for automated tests relating to triangle drawing.
• blit-benchmark, a program for automated benchmarks relating to image blitting.
• x-*, which correspond to the various third-party libraries. Unlike the other subprojects, these are not
defined in the main premake5.lua, but rather in third party/premake5.lua.
Although the teaser image looks somewhat like a screenshot from a game, quite a few things that make a
game are missing. This includes functionality like collision detection, sound, game logic, AI, networking, etc
etc. However, most importantly for COMP3811, there are several graphics subroutines whose implementations
are missing as well. Each task that you complete will progress you from the initial empty black screen towards
the teaser image shown on the first page in this document.
Coursework 1 includes tasks for a maximum of 50 marks. Each of the tasks below indicates the maximum
number of marks that you can receive for it. Grading of each task is assessed based on the descriptions and
analysis in your report and further assessed based on: code quality, including correctness, clarity, commenting
and efficiency. Your code must work in both debug and release modes.
1.1 Setting Pixels
2 marks
Drawing anything on screen ultimately requires you to set a specific pixel to a specific color. In this first task,
you will implement helper functions to do so. Any drawing from here on out will use these helpers, specifically
the Surface:set_pixel_srgb method.
Consider the Surface::set_pixel_srgb and Surface::get_linear_index methods. These are declared in
the Surface class in draw2d/surface.hpp and defined in draw2d/surface.inl. Implement the two
functions in draw2d/surface.inl.
The pixel coordinate (0, 0) must correspond to the bottom-left corner in the window.
The Surface class uses a RGBx image format, where each color component is stored in a single 8-bit unsigned
integer (std::uint8_t). You may set the fourth component (“x”) to zero. It is included to pad each pixel to be
**-bits but otherwise ignored. The image is stored in row-major order.
Important:
• You are not allowed to change the draw2d/surface.hpp header (and, consequently, you may not
change the interface of the Surface class).
• You must keep the assert()-line as the first line of the Surface::set_pixel_srgb function definition.
Only add new code below it.
These methods are used to draw the background particle field. Refer to Figure 1 for possible results. You can
move around by first tapping space to enter piloting mode (your mouse cursor should turn into a crosshair),
moving the mouse cursor in the direction you wish to accelerate, and then pressing and holding the right
mouse button to accelerate. Tapping space bar a second time will exit the piloting mode.
In your report: Include a screenshot of the particle field. Make sure that the particles are visible (if necessary,
add a scaled-up cut-out image).
1.2 Drawing Lines
8 marks
Next, consider the function draw_line_solid. The function is declared in the draw2d/draw.hpp header
and defined in the draw2d/draw.cpp source file. The function is supposed to draw a solid single-color line
between the points aBegin and aEnd. The color of the line is specified by the function’s final argument.
Implement the draw_line_solid function. The goal is to produce a line that is as thin as possible (single pixel
width) and that does not have any holes (i.e., each pixel should connect to another pixel either by nearest
neighbours or by diagonals). Recall the parametrised version of a line as a starting point. You should ensureCOMP3811 - Coursework 1 3
(a) Background “starfield” (b) Magnified view
Figure 1: Task 1. You might need to zoom in to the left image in your PDF viewer to see the individual points. The right
image shows a magnified view of the top-left region.
that the function produces correct results with all inputs, including cases where the line extends off-screen (so,
you must include clipping). You may pick any drawing method, but it should scale with O (N) with respect to
the number of drawn pixels (N). You should not make any dynamic allocations (nor any system calls) in the
line drawing method.
The handed-out code contains two additional programs related to your line drawing. Use lines-sandbox
to visually verify your results in isolation. It includes a small number of examples already. You can switch
between the examples using the number keys. See source code comments for more information. You are free
to add additional examples.
The second program, lines-test, runs a few automated tests on the line drawing. It uses the Catch2
testing library. Ensure that your implementation passes the existing tests. Refer to the source code for more
information on the tests.
Note: You must not change the prototype of the draw_line_solid function, and you must use Surface::▽
▷ set_pixel_srgb to draw pixels.
With the line drawing in place, you should now be able to see a space ship (Figure 2a).
In your report: Explain your line drawing method (as a reminder: do not just dump code into your report).
Document your handling of lines extending off-screen. Include a screenshot of the drawn ship.
1.3 2D Rotation
2 marks
The space ship initially always faces to the right. To make it turn, you must implement a few functions related
to the 2 × 2 matrices:
• Matrix-matrix multiplication: Mat22f operator*( Mat22f const&, Mat22f const& ) noexcept
• Matrix-vector multiplication: Vec2f operator*( Mat22f const&, Vec2f const& ) noexcept
• Creation of a rotation matrix: Mat22f make_rotation_2d( float aAngleInRadians ) noexcept
The functions are both declared and defined in vmlib/mat22.hpp. Provide implementations for these functions/operators.
With the implementations in place, the ship should now always face the mouse cursor when
in piloting mode (compare to Figure 2b – the spaceship is facing to the bottom right in this example).
In your report: Include a screenshot of the rotated ship.
(a) Section 1.2 (b) Section 1.3
Figure 2: (a) Space ship without rotation, facing the default direction (right). (b) Space ship with rotation, always facing
the mouse cursor when in piloting mode.4 COMP3811 - Coursework 1
Figure 3: Approaching the earth (lithobraking not yet implemented!).
1.4 Drawing triangles
8 marks
Consider the function draw_triangle_interp. It is also declared in the draw2d/draw.hpp header and defined
in draw2d/draw.cpp. This function draws a single triangle defined by its three vertices (aP0, aP1 and
aP2). Each vertex is assigned a color (aC0, aC1 and aC2, respectively). These colors should be interpolated
across the triangle with barycentric interpolation. Implement this function. Make sure that the function works
correctly with all (reasonable) inputs.
Unlike earlier examples, the colors are specified in linear RGB (ColorF). You should perform the interpolation
in linear RGB space and only convert to the 8-bit sRGB representation when writing the color value to the
surface.
You can pick any method, but it should be reasonably efficient (e.g., simply testing all pixels in the screen is
not sufficient). You should not make any dynamic allocations or system calls in the triangle drawing method.
Use the triangles-sandbox to visually experiment with your triangle drawing in isolation. Run the tests in
triangles-test and ensure that they pass. When you have implemented the triangle drawing, you should
also be able to see the asteroids in the main program (see teaser image).
Note: You must not change the prototype of the draw_line_solid function, and you must use Surface::▽
▷ set_pixel_srgb to draw pixels.
In your report: Explain your method. Document any special handing that you perform. Include a screenshot
of the main program, with the asteroids visible.
1.5 Blitting images
4 marks
In this task, you will implement image blitting with alpha masking. Consider the blit_masked function
declared in draw2d/image.hpp and defined in draw2d/image.cpp. You will also need to implement a
few helper functions in draw2d/image.inl. Search for lines containing the string // TODO.
You should blit the input image (aImage of type ImageRGBA) to the position specified by aPosition. The
position is relative to the center of the input image. Input pixels with an alpha value (a component of the
Color_sRGB_Alpha color struct) less than 128 should be discarded. Consider efficiency in your implementation
and do not make any dynamic allocations/syscalls (etc etc.).
If you have implemented the method correctly, you should find the earth after flying a bit to the right – it will
be off-screen initially (see teaser image and Figure 3).
Note: You must not change the prototype of the blit_masked function. You must not change the ImageRGBA
class and the load_image function.
In your report: Describe your implementation of the blit. Discuss the efficiency of your implementation. Focus
specifically on choices in your implementation that benefit efficiency and the impact of clipping/culling.
1.6 Testing: lines
8 marks
Consider the lines-test program. It contains a few example tests that verify expected behaviour. However,
the tests are far from exhaustive.
Implement tests for the following four scenarios:
1. Consider a line from p0 to p1. It should be identical to the line from p1 to p0.COMP3811 - Coursework 1 5
2. Consider lines with one point inside the surface and one outside.
3. Consider lines with both points outside of the surface.
4. Consider two lines. The first starts at p0 and extends to p1. The second starts at p1 and extends to p2.
When both are drawn, there should be no gap between the two lines. Extend this to multiple lines - what
happens if the lines are very short?
Each scenario must be implemented in a separate TEST_CASE in the corresponding source file (e.g., Scenario 1
is in scenario-1.cpp and so on). Each scenario is expected to test multiple different representative lines, for
which you are required to make informed choices. It is likely you will need multiple assertions per test.
If your line drawing implementation fails some of the tests, you should tag the corresponding TEST_CASE with
[!mayfail]. Mention this in your report.
In your report: Document which tests you have added. Describe how you have implemented the test (what
do you actually test?). List what representative lines you have chosen to include in your tests and motivate
the choice of these. Where possible, sketches and/or screenshots (e.g. from lines-sandbox) that show your
representative lines.
1.7 Testing: triangles
4 marks
Add at least two (2) more distinct test cases to the triangles-test program. Refer to Section 1.6 for details –
the same requirements/guidelines apply here. Use the provided scenario-N.cpp files. Make sure the tests
that you add are meaningful.
In your report: Document the tests that you have added. Explain the purpose of each test and why you
included it. No marks will be awarded for tests that lack an explanation and solid reasoning. If possible,
visualize the test case using sketches and/or screenshots (e.g., from triangles-sandbox).
1.8 Benchmark: Blitting
6 marks
Compare the performance of your blit (blit_masked) to two more blit variants under different conditions.
For this task, use blit-benchmark which in turn uses Google’s microbenchmarking library to allow you
to implement these benchmarks. Study the documentation and examples at the provided link. The provided
code implements a simple example that measures the performance for a simple blit operation.
Important: You should only ever benchmark code built in the release configuration. The debug configuration
disables many compiler optimizations (including code inlining!) to aid debugging and is therefore not representative
of the final performance. Hence, when running benchmarks, make sure you only ever use release
builds.
Modern CPUs and operating systems also adjust clock rates of the processor based on work load.
Many CPUs can additionally boost to higher clock rates for short periods of time. These features are
obviously desirable under normal conditions, but make life during benchmarking more difficult.
Refer to Benchmarking details below for additional discussion on this topic.
You should first implement the additional blit variants in draw-ex.cpp:
• blit_ex_solid: A blit without alpha masking, where you just copy over the target image pixel by pixel.
Implement this yourself using loops in C++.
• blit_ex_memcpy: A blit without alpha masking, but implement this using std::memcpy, one for each
line in the image.
These “extended” functions take a SurfaceEx argument instead of the Surface. The main difference is that
SurfaceEx gives out a raw pointer to the image data; you will need this for (minimally) the std::memcpy▽
▷ -based variant. Study the declaration of SurfaceEx for details.
Before performing any benchmarks, you should ensure that the variants work correctly. There is no point in
benchmarking incorrect code.
Benchmark the performance under different conditions. Perform comparisons with a smaller (e.g., 128×128)
and a larger (e.g.,1024×1024) input image. Perform comparisons on a smaller framebuffer (**0×240), the
default size (1280×720), full HD (1920×1080) and an 8k framebuffer (7680×4**0). Vary only one variable at a
time. (However, the benchmark program should run all variants automatically.)6 COMP3811 - Coursework 1
Analyze your results. Do they seem realistic/reasonable? What are your observations? Can you explain what
you see?
In your report: Mention what CPU you are running on. If you know, include information about your system
RAM (amount and speed) and CPU caches. Present your results using graphs/plots (do not dump output
from the terminal or -worse- screenshots of the terminal output in the report!). What are your observations?
Try to explain what you have seen.
Marks are mainly awarded for a solid analysis and discussion of the results. No marks are awarded for just
showing the results. Do not forget to include units on axes/reported numbers.
1.9 Benchmark: Line drawing
7 marks
Use the lines-benchmark program. Refer to Section 1.8 for details on the benchmarking application.
For this task, implement a second line drawing algorithm in draw_ex_line_solid() (in draw-ex.cpp). You
can chose from the following options for this:
• Research an optimized line drawing method. It should be based on existing (technical) literature that
you can reference.
• If you previously implemented a method like DDA (with floating point), aim for an integer-only method
(e.g. Bresenham). If you already implemented an integer-only method, then implement a standard DDA
with floats1
.
• Come up with a potential optimization yourself? It must be non-trivial. If you opt for this, your choice
must be approved by the module leader - discuss your choice with the module leader during one of the
labs. You will be required to provide a solid theoretical reason why this optimization would improve
performance. This should also be included in the report.
Your improved method may use the SurfaceEx class.
Next, identify a few (3-4) different representative lines to benchmark. You are fairly free in your choices here,
but you are expected to motivate your choices later. The cases should differ from each other conceptually. Also
perform the tests with different framebuffer sizes (see Section 1.8). Again, vary only one variable at a time.
Use the tests to verify that your line drawing performs like O (N) with respect to visible pixels.
In your report: Mention which line drawing algorithms you compare and highlight their differences. Document
your representative lines and explain why you have picked these cases. Highlight what you believe
distinguishes them from each other. Present your results using graphs/plots (do not dump output from the
terminal or -worse- screenshots of the terminal output in the report!) Evaluate and analyze these. Discuss
them and try to explain what you have seen. What are your conclusions? Marks are mainly awarded for a
solid analysis and discussion of the results.
If you haven’t already (Section 1.8), mention what CPU you are running on. If you know, include information
about your system RAM (amount and speed) and CPU caches.
Marks are mainly awarded for a solid analysis and discussion of the results. No marks are awarded for just
showing the results. Do not forget to include units on axes/reported numbers.
1.10 Your own space ship
1 mark
The default space ship shape is defined in main/spaceship.cpp. It consists of a number of points that are
connected by lines.
Define your own custom space ship (see instructions in the source code). You must not use more than **
points. The ship shape must show some amount of complexity and creativity. In your report, indicate if you
have created a custom design and include a screenshot of your custom ship.
Please indicate in the source code (see comments) whether you would allow us to use your ship shape in
future iterations of the COMP3811 module (for example as non-player ships). Your choice here does not affect
the marking of this task.
1
In real-time graphics, we typically avoid doubles. They cost twice as much storage, may be significantly slower to compute, and the
extra precision is seldom needed. In fact, there are often better methods to improve precision than just reaching for a more expensive type.COMP3811 - Coursework 1 7
In your report: Include a screenshot of your ship. Briefly explain your design and mention the number of
lines/points you used.
Wrapping up
Please double-check the submission requirements and ensure that your submission conforms to these. In
particular, pay attention to file types (archive format and report format) and ensure that you have not included
any unnecessary files in the submission. Make sure that you have tested your code (compile and run) in both
debug and release modes.
Acknowledgements
The document uses icons from https://icons8.com: , , . . The “free” license requires attribution in documents that use the icons.
Note that each icon is a link to the original source thereof.
Benchmarking details
As mentioned previously in this document, CPU frequency scaling can make benchmarking results less reliable.
There are some tricks that may help.
A common workaround is to “warm up the CPU” by running a computationally heavy task for a short while
before starting measurements. The computational load will cause the OS to transition the CPU to a higher
clock rate. The main measurements should only take place after this warm up.
Google Benchmark seems to run benchmarks in the order they are declared (at least when using a single file).
You can try to add a dummy benchmark at the start, whose results you discard, before running the main
benchmarks. You can also try reordering individual benchmarks. If the results stay the same or very close, it
is a good sign.
A better way would be to disable the CPU frequency scaling temporarily. Unfortunately, this is not always
possible (it requires superuser privilege, which you probably shouldn’t have on the SoC computers).
Nevertheless, if you have your own Linux machine, you can run the following (it requires the cpupower tool):
$ cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
...
available cpufreq governors: ondemand userspace powersave performance schedutil
current policy: frequency should be within 2.20 GHz and 3.70 GHz.
The governor "schedutil" may decide which speed to use
within this range.
...
This lists the current CPU frequency governor (here: shedutil) and available governors. We’re interested in
the performance governor, which simply runs at the max clock rate the CPU supports. You can activate it
with (this probably requires superuser access):
$ sudo cpupower frequency-set -g performance
Password: hunter2
Setting cpu: 0
...
Setting cpu: 11
Following CPUs are offline:
12-15
cpupower set operation was not performed on them
(The exact output will depend on your CPU. If you have them, don’t worry about the “offline” CPUs, these
likely correspond to cores that were disabled at the factory.)
Run the tests with the “performance” governor.
After you complete the tests, you will want to switch back to your default governor (here: “schedutil”). Using
the “performance” governor for an extended time will likely make your CPU waste power and may cause
devices like laptops to run hot.

請加QQ：99515681  郵箱：99515681@qq.com   WX：codinghelp