path: root/html/feed.xml

<?xml version='1.0' encoding='UTF-8'?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Fryzek Concepts</title><atom:link href="https://fryzekconcepts.com/feed.xml" rel="self" type="application/rss+xml"/><link>https://fryzekconcepts.com</link><description>Lucas is a developer working on cool things</description><lastBuildDate>Sat, 28 Dec 2024 13:41:16 -0000</lastBuildDate><item><title>Generating Video</title><link>https://fryzekconcepts.com/notes/generating-video.html</link><description>&lt;p&gt;One thing I’m very interested in is computer graphics. This could be
complex 3D graphics or simple 2D graphics. The idea of getting a
computer to display visual data fascinates me. One fundamental part of
showing visual data is interfacing with a computer monitor. This can be
accomplished by generating a video signal that the monitor understands.
Below I have written instructions on how an FPGA can be used to generate
a video signal. I have specifically worked with the iCEBreaker FPGA but
the theory contained within this should work with any FPGA or device
that you can generate the appropriate timings for.&lt;/p&gt;
&lt;h3 id="tools"&gt;Tools&lt;/h3&gt;
&lt;p&gt;Hardware used (&lt;a
href="https://www.crowdsupply.com/1bitsquared/icebreaker-fpga"&gt;link for
board&lt;/a&gt;):&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;iCEBreaker FPGA&lt;/li&gt;
&lt;li&gt;iCEBreaker 12-Bit DVI Pmod&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Software Used:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;IceStorm FPGA toolchain (&lt;a
href="https://github.com/esden/summon-fpga-tools"&gt;follow install
instructions here&lt;/a&gt;)&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="theory"&gt;Theory&lt;/h3&gt;
&lt;p&gt;A video signal is composed of several parts, primarily the colour
signals and the sync signals. For this DVI Pmod, there is also a data
enable signal for the visible screen area. For the example here we are
going to be generating a 640x480 60 Hz video signal. Below is a table
describing the important data for our video signal.&lt;/p&gt;
&lt;table&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;
Pixel Clock
&lt;/td&gt;
&lt;td&gt;
25.175 MHz
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Pixels Per Line
&lt;/td&gt;
&lt;td&gt;
800 Pixels
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Pixels Visible Per Line
&lt;/td&gt;
&lt;td&gt;
640 Pixels
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Horizontal Sync Front Porch Length
&lt;/td&gt;
&lt;td&gt;
16 Pixels
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Horizontal Sync Length
&lt;/td&gt;
&lt;td&gt;
96 Pixels
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Horizontal Sync Back Porch Length
&lt;/td&gt;
&lt;td&gt;
48 Pixels
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Lines Per Frame
&lt;/td&gt;
&lt;td&gt;
525 Lines
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Lines Visible Per Frame
&lt;/td&gt;
&lt;td&gt;
480 Lines
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Vertical Front Porch Length
&lt;/td&gt;
&lt;td&gt;
10 Lines
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Vertical Sync Length
&lt;/td&gt;
&lt;td&gt;
2 Lines
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Vertical Back Porch Length
&lt;/td&gt;
&lt;td&gt;
33 Lines
&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;Sourced from http://www.tinyvga.com/vga-timing/640x480@60Hz&lt;/p&gt;
&lt;p&gt;The data from this table raises a few questions:&lt;/p&gt;
&lt;ol type="1"&gt;
&lt;li&gt;What is the Pixel Clock?&lt;/li&gt;
&lt;li&gt;What is the difference between “Pixels/Lines” and “Visible
Pixels/Lines”?&lt;/li&gt;
&lt;li&gt;What is “Front Porch”, “Sync”, and “Back Porch”?&lt;/li&gt;
&lt;/ol&gt;
&lt;h4 id="pixel-clock"&gt;Pixel Clock&lt;/h4&gt;
&lt;p&gt;The pixel clock is a fairly straightforward idea; this is the rate at
which we generate pixels. For video signal generation, the “pixel” is a
fundamental building block and we count things in the number of pixels
it takes up. Every time the pixel clock “ticks” we have incremented the
number of pixels we have processed. So for a 640x480 video signal, a
full line is 800 pixels, or 800 clock ticks. For the full 800x525 frame
there is 800 ticks x 525 lines, or 420000 clock ticks. If we are running
the display at 60 Hz, 420000 pixels per frame are generated 60 times per
second. Therefore, 25200000 pixels or clock ticks will pass in one
second. From this we can see the pixel clock frequency of 25.175 MHz is
roughly equal to 25200000 clock ticks. There is a small deviance from
the “true” values here, but monitors are flexible enough to accept this
video signal (my monitor reports it as 640x480@60Hz), and all
information I can find online says that 25.175 MHz is the value you want
to use. Later on we will see that the pixel clock is not required to be
exactly 25.175 Mhz.&lt;/p&gt;
&lt;h4 id="visible-area-vs-invisible-area"&gt;Visible Area vs Invisible
Area&lt;/h4&gt;
&lt;p&gt;&lt;img
src="/assets/2020-04-07-generating-video/visible_invisible.png" /&gt;&lt;/p&gt;
&lt;p&gt;From the above image we can see that a 640x480 video signal actually
generates a resolution larger than 640x480. The true resolution we
generate is 800x525, but only a 640x480 portion of that signal is
visible. The area that is not visible is where we generate the sync
signal. In other words, every part of the above image that is black is
where a sync signal is being generated.&lt;/p&gt;
&lt;h4 id="front-porch-back-porch-sync"&gt;Front Porch, Back Porch &amp;amp;
Sync&lt;/h4&gt;
&lt;p&gt;To better understand the front porch, back porch and sync signal,
let’s look at what the horizontal sync signal looks like during the
duration of a line:&lt;/p&gt;
&lt;p&gt;&lt;img src="/assets/2020-04-07-generating-video/sync.png" /&gt;&lt;/p&gt;
&lt;p&gt;From this we can see that the “Front Porch” is the invisible pixels
between the visible pixels and the sync pixels, and is represented by a
logical one or high signal. The “Sync” is the invisible pixels between
the front porch and back porch, and is represented by a logical zero or
low signal. The “Back Porch” is the invisible pixels after the sync
signal, and is represented by a logical one. For the case of 640x480
video, the visible pixel section lasts for 640 pixels. The front porch
section lasts for 16 pixels, after which the sync signal will become a
logical zero. This logical zero sync will last for 96 pixels, after
which the sync signal will become a logical one again. The back porch
will then last for 48 pixels. If you do a quick calculation right now of
640 + 16 + 96 + 48, we get 800 pixels which represents the full
horizontal resolution of the display. The vertical sync signal works
almost exactly the same, except the vertical sync signal acts on
lines.&lt;/p&gt;
&lt;h3 id="implementation"&gt;Implementation&lt;/h3&gt;
&lt;p&gt;The first thing we can do that is going to simplify a lot of the
following logic is to keep track of which pixel, and which line we are
on. The below code block creates two registers to keep track of the
current pixel on the line (column) and the current line (line):&lt;/p&gt;
&lt;div class="sourceCode" id="cb1"&gt;&lt;pre
class="sourceCode verilog"&gt;&lt;code class="sourceCode verilog"&gt;&lt;span id="cb1-1"&gt;&lt;a href="#cb1-1" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;9&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; line&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-2"&gt;&lt;a href="#cb1-2" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;9&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; column&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-3"&gt;&lt;a href="#cb1-3" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb1-4"&gt;&lt;a href="#cb1-4" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;always&lt;/span&gt; &lt;span class="op"&gt;@(&lt;/span&gt;&lt;span class="kw"&gt;posedge&lt;/span&gt; clk &lt;span class="dt"&gt;or&lt;/span&gt; &lt;span class="kw"&gt;posedge&lt;/span&gt; reset&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-5"&gt;&lt;a href="#cb1-5" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="kw"&gt;if&lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;reset &lt;span class="op"&gt;==&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-6"&gt;&lt;a href="#cb1-6" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        line &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-7"&gt;&lt;a href="#cb1-7" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        column &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-8"&gt;&lt;a href="#cb1-8" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-9"&gt;&lt;a href="#cb1-9" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="kw"&gt;else&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-10"&gt;&lt;a href="#cb1-10" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;if&lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;column &lt;span class="op"&gt;==&lt;/span&gt; &lt;span class="dv"&gt;799&lt;/span&gt; &lt;span class="op"&gt;&amp;amp;&amp;amp;&lt;/span&gt; line &lt;span class="op"&gt;==&lt;/span&gt; &lt;span class="dv"&gt;524&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-11"&gt;&lt;a href="#cb1-11" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            line &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-12"&gt;&lt;a href="#cb1-12" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            column &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-13"&gt;&lt;a href="#cb1-13" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-14"&gt;&lt;a href="#cb1-14" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;else&lt;/span&gt; &lt;span class="kw"&gt;if&lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;column &lt;span class="op"&gt;==&lt;/span&gt; &lt;span class="dv"&gt;799&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-15"&gt;&lt;a href="#cb1-15" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            line &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; line &lt;span class="op"&gt;+&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-16"&gt;&lt;a href="#cb1-16" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            column &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-17"&gt;&lt;a href="#cb1-17" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-18"&gt;&lt;a href="#cb1-18" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;else&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-19"&gt;&lt;a href="#cb1-19" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            column &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; column &lt;span class="op"&gt;+&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-20"&gt;&lt;a href="#cb1-20" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-21"&gt;&lt;a href="#cb1-21" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-22"&gt;&lt;a href="#cb1-22" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;This block of Verilog works by first initializing the line and column
register to zero on a reset. This is important to make sure that we
start from known values, otherwise the line and column register could
contain any value and our logic would not work. Next, we check if we are
at the bottom of the screen by comparing the current column to 799 (the
last pixel in the line) and the current line is 524 (the last line in
the frame). If these conditions are both true then we reset the line and
column back to zero to signify that we are starting a new frame. The
next block checks if the current column equals 799. Because the above if
statement failed,we know that we are at the end of the line but not the
end of the frame. If this is true we increment the current line count
and set the column back to zero to signify that we are starting a new
line. The final block simply increments the current pixel count. If we
reach this block ,we are neither at the end of the line or the end of
the frame so we can simply increment to the next pixel.&lt;/p&gt;
&lt;p&gt;Now that we are keeping track of the current column and current line,
we can use this information to generate the horizontal and vertical sync
signals. From the theory above we know that the sync signal is only low
when we are between the front and back porch, at all other times the
signal is high. From this we can generate the sync signal with an OR and
two compares.&lt;/p&gt;
&lt;div class="sourceCode" id="cb2"&gt;&lt;pre
class="sourceCode verilog"&gt;&lt;code class="sourceCode verilog"&gt;&lt;span id="cb2-1"&gt;&lt;a href="#cb2-1" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic horizontal_sync&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-2"&gt;&lt;a href="#cb2-2" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic vertical_sync&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-3"&gt;&lt;a href="#cb2-3" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; horizontal_sync &lt;span class="op"&gt;=&lt;/span&gt; column &lt;span class="op"&gt;&amp;lt;&lt;/span&gt; &lt;span class="dv"&gt;656&lt;/span&gt; &lt;span class="op"&gt;||&lt;/span&gt; column &lt;span class="op"&gt;&amp;gt;=&lt;/span&gt; &lt;span class="dv"&gt;752&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-4"&gt;&lt;a href="#cb2-4" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; vertical_sync &lt;span class="op"&gt;=&lt;/span&gt; line &lt;span class="op"&gt;&amp;lt;&lt;/span&gt; &lt;span class="dv"&gt;490&lt;/span&gt; &lt;span class="op"&gt;||&lt;/span&gt; line &lt;span class="op"&gt;&amp;gt;=&lt;/span&gt; &lt;span class="dv"&gt;492&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Let’s examine the horizontal sync signal more closely. This statement
will evaluate to true if the current column is less than 656 or the
current column is greater than or equal to 752. This means that the
horizontal sync signal will be true except for when the current column
is between 656 and 751 inclusively. That is starting on column 656 the
horizontal sync signal will become false (low) and will remain that way
for the next 96 pixels until we reach pixel 752 where it will return to
being true (high). The vertical sync signal will work in the same way
except it is turned on based on the current line. Therefore, the signal
will remain high when the line is less than 490 and greater than or
equal to 492, and will remain low between lines 490 and 491
inclusive.&lt;/p&gt;
&lt;h4 id="putting-it-all-together"&gt;Putting It All Together&lt;/h4&gt;
&lt;p&gt;Now that we have generated the video signal, we need to route it
towards the video output connectors on the iCEBreaker 12-bit DVI Pmod.
We also need to configure the iCEBreaker FPGA to have the appropriate
pixel clock frequency. First to get the correct pixel clock we are going
to use the following block of code:&lt;/p&gt;
&lt;div class="sourceCode" id="cb3"&gt;&lt;pre
class="sourceCode verilog"&gt;&lt;code class="sourceCode verilog"&gt;&lt;span id="cb3-1"&gt;&lt;a href="#cb3-1" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;SB_PLL40_PAD #&lt;span class="op"&gt;(&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-2"&gt;&lt;a href="#cb3-2" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DIVR&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-3"&gt;&lt;a href="#cb3-3" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DIVF&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;7&amp;#39;b1000010&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-4"&gt;&lt;a href="#cb3-4" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DIVQ&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;3&amp;#39;b101&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-5"&gt;&lt;a href="#cb3-5" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .FILTER_RANGE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;3&amp;#39;b001&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-6"&gt;&lt;a href="#cb3-6" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .FEEDBACK_PATH&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;SIMPLE&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-7"&gt;&lt;a href="#cb3-7" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DELAY_ADJUSTMENT_MODE_FEEDBACK&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;FIXED&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-8"&gt;&lt;a href="#cb3-8" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .FDA_FEEDBACK&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-9"&gt;&lt;a href="#cb3-9" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DELAY_ADJUSTMENT_MODE_RELATIVE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;FIXED&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-10"&gt;&lt;a href="#cb3-10" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .FDA_RELATIVE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-11"&gt;&lt;a href="#cb3-11" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .SHIFTREG_DIV_MODE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;2&amp;#39;b00&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-12"&gt;&lt;a href="#cb3-12" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .PLLOUT_SELECT&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;GENCLK&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-13"&gt;&lt;a href="#cb3-13" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .ENABLE_ICEGATE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;1&amp;#39;b0&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-14"&gt;&lt;a href="#cb3-14" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;)&lt;/span&gt; usb_pll_inst &lt;span class="op"&gt;(&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-15"&gt;&lt;a href="#cb3-15" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .PACKAGEPIN&lt;span class="op"&gt;(&lt;/span&gt;CLK&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-16"&gt;&lt;a href="#cb3-16" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .PLLOUTCORE&lt;span class="op"&gt;(&lt;/span&gt;pixel_clock&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-17"&gt;&lt;a href="#cb3-17" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .EXTFEEDBACK&lt;span class="op"&gt;(),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-18"&gt;&lt;a href="#cb3-18" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DYNAMICDELAY&lt;span class="op"&gt;(),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-19"&gt;&lt;a href="#cb3-19" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .RESETB&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;1&amp;#39;b1&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-20"&gt;&lt;a href="#cb3-20" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .BYPASS&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;1&amp;#39;b0&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-21"&gt;&lt;a href="#cb3-21" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .LATCHINPUTVALUE&lt;span class="op"&gt;(),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-22"&gt;&lt;a href="#cb3-22" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;This block is mainly a copy paste of the PLL setup code from the
iCEBreaker examples, but with a few important changes. The DIVR, DIVF,
and DIVQ values are changed to create a 25.125 MHz. This is not exactly
25.175 MHz, but it is close enough that the monitor is happy enough and
recognizes it as a 640x480@60 Hz signal. These values were found through
the “icepll” utility, below is an example of calling this utility from
the command line:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;$ icepll -i 12 -o 25.175

F_PLLIN:    12.000 MHz (given)
F_PLLOUT:   25.175 MHz (requested)
F_PLLOUT:   25.125 MHz (achieved)

FEEDBACK: SIMPLE
F_PFD:   12.000 MHz
F_VCO:  804.000 MHz

DIVR:  0 (4&amp;#39;b0000)
DIVF: 66 (7&amp;#39;b1000010)
DIVQ:  5 (3&amp;#39;b101)

FILTER_RANGE: 1 (3&amp;#39;b001)&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;From here we can see we had an input clock of 12 MHz (This comes from
the FTDI chip on the iCEBreaker board), and we wanted to get a 25.175
MHz output clock. The closest the PLL could generate was a 25.125 MHz
clock with the settings provided for the DIVR, DIVF, and DIVQ
values.&lt;/p&gt;
&lt;p&gt;Now that we have a pixel clock we can wire up the necessary signals
for the DVI video out. The DVI Pmod has the following mapping for all of
its connectors:&lt;/p&gt;
&lt;table&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;
PMOD 1
&lt;/td&gt;
&lt;td&gt;
&lt;/td&gt;
&lt;td&gt;
PMOD 2
&lt;/td&gt;
&lt;td&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;strong&gt;P1A1&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Red bit 4
&lt;/td&gt;
&lt;td&gt;
&lt;strong&gt;P1B1&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Blue bit 4
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;strong&gt;P1A2&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Red bit 3
&lt;/td&gt;
&lt;td&gt;
&lt;strong&gt;P1B2&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Pixel clock
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;strong&gt;P1A3&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Green bit 4
&lt;/td&gt;
&lt;td&gt;
&lt;strong&gt;P1B3&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Blue bit 3
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;strong&gt;P1A4&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Green bit 3
&lt;/td&gt;
&lt;td&gt;
&lt;strong&gt;P1B4&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Horizontal Sync
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;strong&gt;P1A7&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Red bit 2
&lt;/td&gt;
&lt;td&gt;
&lt;strong&gt;P1B7&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Blue bit 2
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;strong&gt;P1A8&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Red bit 1
&lt;/td&gt;
&lt;td&gt;
&lt;strong&gt;P1B8&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Blue bit 1
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;strong&gt;P1A9&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Green bit 2
&lt;/td&gt;
&lt;td&gt;
&lt;strong&gt;P1B9&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Data Enable
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;strong&gt;P1A10&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Green bit 1
&lt;/td&gt;
&lt;td&gt;
&lt;strong&gt;P1B10&lt;/strong&gt;
&lt;/td&gt;
&lt;td&gt;
Vertical Sync
&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;From this we can see that we need 4 bits for each colour channel, a
horizontal sync signal, a vertical sync signal, and additionally a data
enable signal. The data enable signal is not part of a standard video
signal and is just used by the DVI transmitter chip on the Pmod to
signify when we are in visible pixel area or invisible pixel area.
Therefore we will set the Date enable line when the current column is
less than 640 and the current line is less than 480. Based on this we
can connect the outputs like so:&lt;/p&gt;
&lt;div class="sourceCode" id="cb5"&gt;&lt;pre
class="sourceCode verilog"&gt;&lt;code class="sourceCode verilog"&gt;&lt;span id="cb5-1"&gt;&lt;a href="#cb5-1" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; r&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb5-2"&gt;&lt;a href="#cb5-2" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; g&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb5-3"&gt;&lt;a href="#cb5-3" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; b&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb5-4"&gt;&lt;a href="#cb5-4" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic data_enable&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb5-5"&gt;&lt;a href="#cb5-5" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; data_enable &lt;span class="op"&gt;=&lt;/span&gt; column &lt;span class="op"&gt;&amp;lt;&lt;/span&gt; &lt;span class="dv"&gt;640&lt;/span&gt; &lt;span class="op"&gt;&amp;amp;&amp;amp;&lt;/span&gt; line &lt;span class="op"&gt;&amp;lt;&lt;/span&gt; &lt;span class="dv"&gt;480&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb5-6"&gt;&lt;a href="#cb5-6" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; &lt;span class="op"&gt;{&lt;/span&gt;P1A1&lt;span class="op"&gt;,&lt;/span&gt;   P1A2&lt;span class="op"&gt;,&lt;/span&gt;   P1A3&lt;span class="op"&gt;,&lt;/span&gt;   P1A4&lt;span class="op"&gt;,&lt;/span&gt;   P1A7&lt;span class="op"&gt;,&lt;/span&gt;   P1A8&lt;span class="op"&gt;,&lt;/span&gt;   P1A9&lt;span class="op"&gt;,&lt;/span&gt;   P1A10&lt;span class="op"&gt;}&lt;/span&gt; &lt;span class="op"&gt;=&lt;/span&gt; &lt;/span&gt;
&lt;span id="cb5-7"&gt;&lt;a href="#cb5-7" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;       &lt;span class="op"&gt;{&lt;/span&gt;r&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   r&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;2&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   g&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   g&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;2&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   r&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   r&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   g&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   g&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]};&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb5-8"&gt;&lt;a href="#cb5-8" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; &lt;span class="op"&gt;{&lt;/span&gt;P1B1&lt;span class="op"&gt;,&lt;/span&gt;   P1B2&lt;span class="op"&gt;,&lt;/span&gt;   P1B3&lt;span class="op"&gt;,&lt;/span&gt;   P1B4&lt;span class="op"&gt;,&lt;/span&gt;   P1B7&lt;span class="op"&gt;,&lt;/span&gt;   P1B8&lt;span class="op"&gt;,&lt;/span&gt;   P1B9&lt;span class="op"&gt;,&lt;/span&gt;   P1B10&lt;span class="op"&gt;}&lt;/span&gt; &lt;span class="op"&gt;=&lt;/span&gt; &lt;/span&gt;
&lt;span id="cb5-9"&gt;&lt;a href="#cb5-9" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;       &lt;span class="op"&gt;{&lt;/span&gt;b&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   pixel_clock&lt;span class="op"&gt;,&lt;/span&gt; b&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;2&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   horizontal_sync&lt;span class="op"&gt;,&lt;/span&gt; b&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   b&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   data_enable&lt;span class="op"&gt;,&lt;/span&gt; vertical_sync&lt;span class="op"&gt;};&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Now for testing purposes we are going to set the output colour to be
fixed to pure red so additional logic to pick a pixel colour is not
required for this example. We can do this as shown below:&lt;/p&gt;
&lt;div class="sourceCode" id="cb6"&gt;&lt;pre
class="sourceCode verilog"&gt;&lt;code class="sourceCode verilog"&gt;&lt;span id="cb6-1"&gt;&lt;a href="#cb6-1" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; r &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="bn"&gt;4&amp;#39;b1111&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb6-2"&gt;&lt;a href="#cb6-2" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; g &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb6-3"&gt;&lt;a href="#cb6-3" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; b &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Putting all of the above code together with whatever additional
inputs are required for the iCEBreaker FPGA gives us the following block
of code:&lt;/p&gt;
&lt;div class="sourceCode" id="cb7"&gt;&lt;pre
class="sourceCode verilog"&gt;&lt;code class="sourceCode verilog"&gt;&lt;span id="cb7-1"&gt;&lt;a href="#cb7-1" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;module&lt;/span&gt; top&lt;/span&gt;
&lt;span id="cb7-2"&gt;&lt;a href="#cb7-2" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;(&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-3"&gt;&lt;a href="#cb7-3" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;input&lt;/span&gt; CLK&lt;span class="op"&gt;,&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-4"&gt;&lt;a href="#cb7-4" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;output&lt;/span&gt; LEDR_N&lt;span class="op"&gt;,&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-5"&gt;&lt;a href="#cb7-5" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;output&lt;/span&gt; LEDG_N&lt;span class="op"&gt;,&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-6"&gt;&lt;a href="#cb7-6" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;input&lt;/span&gt; BTN_N&lt;span class="op"&gt;,&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-7"&gt;&lt;a href="#cb7-7" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;output&lt;/span&gt; P1A1&lt;span class="op"&gt;,&lt;/span&gt; P1A2&lt;span class="op"&gt;,&lt;/span&gt; P1A3&lt;span class="op"&gt;,&lt;/span&gt; P1A4&lt;span class="op"&gt;,&lt;/span&gt; P1A7&lt;span class="op"&gt;,&lt;/span&gt; P1A8&lt;span class="op"&gt;,&lt;/span&gt; P1A9&lt;span class="op"&gt;,&lt;/span&gt; P1A10&lt;span class="op"&gt;,&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-8"&gt;&lt;a href="#cb7-8" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;output&lt;/span&gt; P1B1&lt;span class="op"&gt;,&lt;/span&gt; P1B2&lt;span class="op"&gt;,&lt;/span&gt; P1B3&lt;span class="op"&gt;,&lt;/span&gt; P1B4&lt;span class="op"&gt;,&lt;/span&gt; P1B7&lt;span class="op"&gt;,&lt;/span&gt; P1B8&lt;span class="op"&gt;,&lt;/span&gt; P1B9&lt;span class="op"&gt;,&lt;/span&gt; P1B10&lt;/span&gt;
&lt;span id="cb7-9"&gt;&lt;a href="#cb7-9" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-10"&gt;&lt;a href="#cb7-10" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-11"&gt;&lt;a href="#cb7-11" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="ot"&gt;`define PIXELS_PER_LINE 10&amp;#39;d800&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-12"&gt;&lt;a href="#cb7-12" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="ot"&gt;`define PIXELS_VISIBLE_PER_LINE 10&amp;#39;d640&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-13"&gt;&lt;a href="#cb7-13" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="ot"&gt;`define LINES_PER_FRAME 10&amp;#39;d525&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-14"&gt;&lt;a href="#cb7-14" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="ot"&gt;`define LINES_VISIBLE_PER_FRAME 10&amp;#39;d480&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-15"&gt;&lt;a href="#cb7-15" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="ot"&gt;`define HORIZONTAL_FRONTPORCH 10&amp;#39;d656&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-16"&gt;&lt;a href="#cb7-16" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="ot"&gt;`define HORIZONTAL_BACKPORCH 10&amp;#39;d752&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-17"&gt;&lt;a href="#cb7-17" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="ot"&gt;`define VERTICAL_FRONTPORCH 10&amp;#39;d490&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-18"&gt;&lt;a href="#cb7-18" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="ot"&gt;`define VERTICAL_BACKPORCH 10&amp;#39;d492&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-19"&gt;&lt;a href="#cb7-19" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-20"&gt;&lt;a href="#cb7-20" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;9&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; line&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-21"&gt;&lt;a href="#cb7-21" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;9&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; column&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-22"&gt;&lt;a href="#cb7-22" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic horizontal_sync&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-23"&gt;&lt;a href="#cb7-23" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic vertical_sync&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-24"&gt;&lt;a href="#cb7-24" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic data_enable&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-25"&gt;&lt;a href="#cb7-25" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic pixel_clock&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-26"&gt;&lt;a href="#cb7-26" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic reset&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-27"&gt;&lt;a href="#cb7-27" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-28"&gt;&lt;a href="#cb7-28" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; r&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-29"&gt;&lt;a href="#cb7-29" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; g&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-30"&gt;&lt;a href="#cb7-30" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;logic &lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;:&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; b&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-31"&gt;&lt;a href="#cb7-31" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-32"&gt;&lt;a href="#cb7-32" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; horizontal_sync &lt;span class="op"&gt;=&lt;/span&gt; column &lt;span class="op"&gt;&amp;lt;&lt;/span&gt; &lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="ot"&gt;`HORIZONTAL_FRONTPORCH&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="op"&gt;||&lt;/span&gt; column &lt;span class="op"&gt;&amp;gt;=&lt;/span&gt; &lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="ot"&gt;`HORIZONTAL_BACKPORCH&lt;/span&gt;&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-33"&gt;&lt;a href="#cb7-33" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; vertical_sync &lt;span class="op"&gt;=&lt;/span&gt; line &lt;span class="op"&gt;&amp;lt;&lt;/span&gt; &lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="ot"&gt;`VERTICAL_FRONTPORCH&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="op"&gt;||&lt;/span&gt; line &lt;span class="op"&gt;&amp;gt;=&lt;/span&gt; &lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="ot"&gt;`VERTICAL_BACKPORCH&lt;/span&gt;&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-34"&gt;&lt;a href="#cb7-34" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; data_enable &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="op"&gt;(&lt;/span&gt;column &lt;span class="op"&gt;&amp;lt;&lt;/span&gt; &lt;span class="ot"&gt;`PIXELS_VISIBLE_PER_LINE&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="op"&gt;&amp;amp;&amp;amp;&lt;/span&gt; &lt;span class="op"&gt;(&lt;/span&gt;line &lt;span class="op"&gt;&amp;lt;&lt;/span&gt; &lt;span class="ot"&gt;`LINES_VISIBLE_PER_FRAME&lt;/span&gt;&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-35"&gt;&lt;a href="#cb7-35" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-36"&gt;&lt;a href="#cb7-36" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; reset &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="op"&gt;~&lt;/span&gt;BTN_N&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-37"&gt;&lt;a href="#cb7-37" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; LEDR_N &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-38"&gt;&lt;a href="#cb7-38" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; LEDG_N &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-39"&gt;&lt;a href="#cb7-39" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-40"&gt;&lt;a href="#cb7-40" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; r &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="bn"&gt;4&amp;#39;b1111&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-41"&gt;&lt;a href="#cb7-41" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; g &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-42"&gt;&lt;a href="#cb7-42" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; b &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-43"&gt;&lt;a href="#cb7-43" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-44"&gt;&lt;a href="#cb7-44" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; &lt;span class="op"&gt;{&lt;/span&gt;P1A1&lt;span class="op"&gt;,&lt;/span&gt;   P1A2&lt;span class="op"&gt;,&lt;/span&gt;   P1A3&lt;span class="op"&gt;,&lt;/span&gt;   P1A4&lt;span class="op"&gt;,&lt;/span&gt;   P1A7&lt;span class="op"&gt;,&lt;/span&gt;   P1A8&lt;span class="op"&gt;,&lt;/span&gt;   P1A9&lt;span class="op"&gt;,&lt;/span&gt;   P1A10&lt;span class="op"&gt;}&lt;/span&gt; &lt;span class="op"&gt;=&lt;/span&gt; &lt;/span&gt;
&lt;span id="cb7-45"&gt;&lt;a href="#cb7-45" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;       &lt;span class="op"&gt;{&lt;/span&gt;r&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   r&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;2&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   g&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   g&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;2&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   r&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   r&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   g&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   g&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]};&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-46"&gt;&lt;a href="#cb7-46" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;assign&lt;/span&gt; &lt;span class="op"&gt;{&lt;/span&gt;P1B1&lt;span class="op"&gt;,&lt;/span&gt;   P1B2&lt;span class="op"&gt;,&lt;/span&gt;   P1B3&lt;span class="op"&gt;,&lt;/span&gt;   P1B4&lt;span class="op"&gt;,&lt;/span&gt;   P1B7&lt;span class="op"&gt;,&lt;/span&gt;   P1B8&lt;span class="op"&gt;,&lt;/span&gt;   P1B9&lt;span class="op"&gt;,&lt;/span&gt;   P1B10&lt;span class="op"&gt;}&lt;/span&gt; &lt;span class="op"&gt;=&lt;/span&gt; &lt;/span&gt;
&lt;span id="cb7-47"&gt;&lt;a href="#cb7-47" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;       &lt;span class="op"&gt;{&lt;/span&gt;b&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;3&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   pixel_clock&lt;span class="op"&gt;,&lt;/span&gt; b&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;2&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   horizontal_sync&lt;span class="op"&gt;,&lt;/span&gt; b&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   b&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;],&lt;/span&gt;   data_enable&lt;span class="op"&gt;,&lt;/span&gt; vertical_sync&lt;span class="op"&gt;};&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-48"&gt;&lt;a href="#cb7-48" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-49"&gt;&lt;a href="#cb7-49" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="co"&gt;// Pixel and line counter&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-50"&gt;&lt;a href="#cb7-50" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;always&lt;/span&gt; &lt;span class="op"&gt;@(&lt;/span&gt;&lt;span class="kw"&gt;posedge&lt;/span&gt; pixel_clock &lt;span class="dt"&gt;or&lt;/span&gt; &lt;span class="kw"&gt;posedge&lt;/span&gt; reset&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-51"&gt;&lt;a href="#cb7-51" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="kw"&gt;if&lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;reset &lt;span class="op"&gt;==&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-52"&gt;&lt;a href="#cb7-52" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        line &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="ot"&gt;`LINES_PER_FRAME&lt;/span&gt; &lt;span class="op"&gt;-&lt;/span&gt; &lt;span class="dv"&gt;2&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-53"&gt;&lt;a href="#cb7-53" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        column &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="ot"&gt;`PIXELS_PER_LINE&lt;/span&gt; &lt;span class="op"&gt;-&lt;/span&gt; &lt;span class="dv"&gt;16&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-54"&gt;&lt;a href="#cb7-54" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-55"&gt;&lt;a href="#cb7-55" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="kw"&gt;else&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-56"&gt;&lt;a href="#cb7-56" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;if&lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;column &lt;span class="op"&gt;==&lt;/span&gt; &lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="ot"&gt;`PIXELS_PER_LINE&lt;/span&gt; &lt;span class="op"&gt;-&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="op"&gt;&amp;amp;&amp;amp;&lt;/span&gt; line &lt;span class="op"&gt;==&lt;/span&gt; &lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="ot"&gt;`LINES_PER_FRAME&lt;/span&gt; &lt;span class="op"&gt;-&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;))&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-57"&gt;&lt;a href="#cb7-57" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            line &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-58"&gt;&lt;a href="#cb7-58" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            column &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-59"&gt;&lt;a href="#cb7-59" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-60"&gt;&lt;a href="#cb7-60" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;else&lt;/span&gt; &lt;span class="kw"&gt;if&lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;column &lt;span class="op"&gt;==&lt;/span&gt; &lt;span class="ot"&gt;`PIXELS_PER_LINE&lt;/span&gt; &lt;span class="op"&gt;-&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-61"&gt;&lt;a href="#cb7-61" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            line &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; line &lt;span class="op"&gt;+&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-62"&gt;&lt;a href="#cb7-62" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            column &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; &lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-63"&gt;&lt;a href="#cb7-63" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-64"&gt;&lt;a href="#cb7-64" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;else&lt;/span&gt; &lt;span class="kw"&gt;begin&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-65"&gt;&lt;a href="#cb7-65" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;            column &lt;span class="op"&gt;&amp;lt;=&lt;/span&gt; column &lt;span class="op"&gt;+&lt;/span&gt; &lt;span class="dv"&gt;1&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-66"&gt;&lt;a href="#cb7-66" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-67"&gt;&lt;a href="#cb7-67" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-68"&gt;&lt;a href="#cb7-68" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;end&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-69"&gt;&lt;a href="#cb7-69" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-70"&gt;&lt;a href="#cb7-70" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;SB_PLL40_PAD #&lt;span class="op"&gt;(&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-71"&gt;&lt;a href="#cb7-71" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DIVR&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-72"&gt;&lt;a href="#cb7-72" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DIVF&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;7&amp;#39;b1000010&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-73"&gt;&lt;a href="#cb7-73" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DIVQ&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;3&amp;#39;b101&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-74"&gt;&lt;a href="#cb7-74" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .FILTER_RANGE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;3&amp;#39;b001&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-75"&gt;&lt;a href="#cb7-75" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .FEEDBACK_PATH&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;SIMPLE&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-76"&gt;&lt;a href="#cb7-76" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DELAY_ADJUSTMENT_MODE_FEEDBACK&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;FIXED&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-77"&gt;&lt;a href="#cb7-77" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .FDA_FEEDBACK&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-78"&gt;&lt;a href="#cb7-78" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DELAY_ADJUSTMENT_MODE_RELATIVE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;FIXED&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-79"&gt;&lt;a href="#cb7-79" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .FDA_RELATIVE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;4&amp;#39;b0000&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-80"&gt;&lt;a href="#cb7-80" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .SHIFTREG_DIV_MODE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;2&amp;#39;b00&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-81"&gt;&lt;a href="#cb7-81" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .PLLOUT_SELECT&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;GENCLK&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-82"&gt;&lt;a href="#cb7-82" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .ENABLE_ICEGATE&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;1&amp;#39;b0&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-83"&gt;&lt;a href="#cb7-83" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;)&lt;/span&gt; usb_pll_inst &lt;span class="op"&gt;(&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-84"&gt;&lt;a href="#cb7-84" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .PACKAGEPIN&lt;span class="op"&gt;(&lt;/span&gt;CLK&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-85"&gt;&lt;a href="#cb7-85" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .PLLOUTCORE&lt;span class="op"&gt;(&lt;/span&gt;pixel_clock&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-86"&gt;&lt;a href="#cb7-86" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .EXTFEEDBACK&lt;span class="op"&gt;(),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-87"&gt;&lt;a href="#cb7-87" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .DYNAMICDELAY&lt;span class="op"&gt;(),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-88"&gt;&lt;a href="#cb7-88" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .RESETB&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;1&amp;#39;b1&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-89"&gt;&lt;a href="#cb7-89" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .BYPASS&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="bn"&gt;1&amp;#39;b0&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-90"&gt;&lt;a href="#cb7-90" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;  .LATCHINPUTVALUE&lt;span class="op"&gt;(),&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-91"&gt;&lt;a href="#cb7-91" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb7-92"&gt;&lt;a href="#cb7-92" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb7-93"&gt;&lt;a href="#cb7-93" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="kw"&gt;endmodule&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;To build this, you will require a .pcf file describing the pin
mapping of the iCEBreaker board. I grabbed mine from the iCEBreaker
examples &lt;a
href="https://raw.githubusercontent.com/icebreaker-fpga/icebreaker-examples/master/icebreaker.pcf"&gt;here&lt;/a&gt;.
Grab that file and put it in the same folder as the file for the code
provided above. We can the run the following commands to generate a
binary to program onto the FPGA:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;yosys -ql out.log  -p &amp;#39;synth_ice40 -top top -json out.json&amp;#39; top.sv
nextpnr-ice40 --up5k   --json out.json --pcf icebreaker.pcf --asc out.asc
icetime  -d up5k -mtr out.rpt out.asc
icepack out.asc out.bin&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This will generate an out.bin file that we will need to flash onto
the board. Make sure your iCEBreaker FPGA is connected via USB to your
computer and you can program it with the following commands.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;iceprog out.bin&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Now connect up a video cable (my DVI Pmod has an HDMI connector, but
it only carries the DVI video signal) to the board and monitor and you
should get results like this:&lt;/p&gt;
&lt;p&gt;&lt;img
src="/assets/2020-04-07-generating-video/IMG_20200407_172119-1-1024x768.jpg" /&gt;&lt;/p&gt;
&lt;p&gt;You can also see from the monitor settings menu that the video signal
was recognized as 640x480@60 Hz. Now the code presented in this post is
specific to the iCEBreaker board and the DVI Pmod, but the theory can be
applied to any FPGA and any connector that uses a video signal like
this. For example you could wire up a DAC with a resistor ladder to
generate a VGA signal. The logic for the timings here would be exactly
the same if you wanted a 640x480@60 Hz VGA signal.&lt;/p&gt;
</description><pubDate>Tue, 07 Apr 2020 04:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/generating-video.html</guid></item><item><title>N64Brew GameJam 2021</title><link>https://fryzekconcepts.com/notes/n64brew-gamejam-2021.html</link><description>&lt;p&gt;So this year, myself and two others decided to participate together
in the N64Brew homebrew GameJam, where we were supposed to build a
homebrew game that would run on a real Nintendo 64. The game jam took
place from October 8th until December 8th and was the second GameJam in
N64Brew history. Unfortunately, we never ended up finishing the game,
but we did build a really cool tech demo. Our project was called
“Bug Game”, and if you want to check it out you can find it &lt;a
href="https://hazematman.itch.io/bug-game"&gt;here&lt;/a&gt;. To play the game
you’ll need a flash cart to load it on a real Nintendo 64, or you can
use an accurate emulator such as &lt;a
href="https://ares.dev/"&gt;ares&lt;/a&gt; or &lt;a
href="https://github.com/n64dev/cen64"&gt;cen64&lt;/a&gt;. The reason an accurate
emulator is required is that we made use of this new open source 3D
microcode for N64 called “&lt;a
href="https://github.com/snacchus/libdragon/tree/ugfx"&gt;ugfx&lt;/a&gt;”,
created by the user Snacchus. This microcode is part of the Libdragon
project, which is trying to build a completely open source library and
toolchain to build N64 games, instead of relying on the official SDK
that has been leaked to the public through liquidation auctions of game
companies that have shut down over the years.&lt;/p&gt;
&lt;div class="gallery"&gt;
&lt;p&gt;&lt;img src="/assets/2021-12-10-n64brew-gamejam-2021/bug_1.png" /&gt; &lt;img
src="/assets/2021-12-10-n64brew-gamejam-2021/bug_2.png" /&gt; &lt;img
src="/assets/2021-12-10-n64brew-gamejam-2021/bug_4.png" /&gt; &lt;img
src="/assets/2021-12-10-n64brew-gamejam-2021/bug_5.png" /&gt; &lt;img
src="/assets/2021-12-10-n64brew-gamejam-2021/bug_3.png" /&gt;&lt;/p&gt;
&lt;p&gt;Screenshots of Bug Game&lt;/p&gt;
&lt;/div&gt;
&lt;h2 id="libdragon-and-ugfx"&gt;Libdragon and UGFX&lt;/h2&gt;
&lt;p&gt;Ugfx was a brand new development in the N64 homebrew scene. By
complete coincidence, Snacchus happened to release it on September 21st,
just weeks before the GameJam was announced. There have been many
attempts to create an open source 3D microcode for the N64 (my &lt;a
href="https://github.com/Hazematman/libhfx"&gt;libhfx&lt;/a&gt; project
included), but ugfx was the first project to complete with easily usable
documentation and examples. This was an exciting development for the
open source N64 brew community, as for the first time we could build 3D
games that ran on the N64 without using the legally questionable
official SDK. I jumped at the opportunity to use this and be one of the
first fully 3D games running on Libdragon.&lt;/p&gt;
&lt;p&gt;One of the “drawbacks” of ufgx was that it tried to follow a lot of
the design decisions the official 3D microcode for Nintendo used. This
made it easier for people familiar with the official SDK to jump ship
over to libdragon, but also went against the philosophy of the libdragon
project to provide simple easy to use APIs. The Nintendo 64 was
notoriously difficult to develop for, and one of the reasons for that
was because of the extremely low level interface that the official 3D
microcodes provided. Honestly writing 3D graphics code on the N64
reminds me more of writing a 3D OpenGL graphics driver (like I do in my
day job), than building a graphics application. Unnecessarily increasing
the burden of entry to developing 3D games on the Nintendo 64. Now that
ugfx has been released, there is an ongoing effort in the community to
revamp it and build a more user friendly API to access the 3D
functionality of the N64.&lt;/p&gt;
&lt;h2 id="ease-of-development"&gt;Ease of development&lt;/h2&gt;
&lt;p&gt;One of the major selling points of libdragon is that it tries to
provide a standard toolchain with access to things like the c standard
library as well as the c++ standard library. To save time on the
development of bug game, I decided to put that claim to test. When
building a 3D game from scratch two things that can be extremely time
consuming are implementing linear algebra operations, and implementing
physics that work in 3D. Luckily for modern developers, there are many
open source libraries you can use instead of building these from
scratch, like &lt;a href="https://glm.g-truc.net/0.9.9/"&gt;GLM&lt;/a&gt; for math
operations and &lt;a
href="https://github.com/bulletphysics/bullet3"&gt;Bullet&lt;/a&gt; for physics.
I don’t believe anyone has tried to do this before, but knowing that
libdragon provides a pretty standard c++ development environment I tried
to build GLM and Bullet to run on the Nintendo 64 and I was successful!
Both GLM and Bullet were able to run on real N64 hardware. This saved
time during development as we were no longer concerned with having to
build our own physics or math libraries. There were some tricks I needed
to do to get bullet running on the hardware.&lt;/p&gt;
&lt;p&gt;First bullet will allocate more memory for its internal pools than is
available on the N64. This is an easy fix as you can adjust the heap
sizes when you go to initialize Bullet using the below code:&lt;/p&gt;
&lt;div class="sourceCode" id="cb1"&gt;&lt;pre
class="sourceCode cpp"&gt;&lt;code class="sourceCode cpp"&gt;&lt;span id="cb1-1"&gt;&lt;a href="#cb1-1" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;btDefaultCollisionConstructionInfo constructionInfo &lt;span class="op"&gt;=&lt;/span&gt; btDefaultCollisionConstructionInfo&lt;span class="op"&gt;();&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-2"&gt;&lt;a href="#cb1-2" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;constructionInfo&lt;span class="op"&gt;.&lt;/span&gt;&lt;span class="va"&gt;m_defaultMaxCollisionAlgorithmPoolSize&lt;/span&gt; &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="dv"&gt;512&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-3"&gt;&lt;a href="#cb1-3" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;constructionInfo&lt;span class="op"&gt;.&lt;/span&gt;&lt;span class="va"&gt;m_defaultMaxPersistentManifoldPoolSize&lt;/span&gt; &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="dv"&gt;512&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb1-4"&gt;&lt;a href="#cb1-4" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;btDefaultCollisionConfiguration&lt;span class="op"&gt;*&lt;/span&gt; collisionConfiguration &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="kw"&gt;new&lt;/span&gt; btDefaultCollisionConfiguration&lt;span class="op"&gt;(&lt;/span&gt;constructionInfo&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;This lets you modify the memory pools and specify a size in KB for
the pools to use. The above code will limit the internal pools to 1MB,
allowing us to easily run within the 4MB of RAM that is available on the
N64 without the expansion pak (an accessory to the N64 that increases
the available RAM to 8MB).&lt;/p&gt;
&lt;p&gt;The second issue I ran into with bullet was that the N64 floating
point unit does not implement de-normalized floating point numbers. Now
I’m not an expert in floating point numbers, but from my understanding,
de-normalized numbers are a way to represent values between the smallest
normal floating point number and zero. This allows floating point
calculations to slowly fall towards zero in a more accurate way instead
of rounding directly to zero. Since the N64 CPU does not implement
de-normalized floats, if any calculations would have generated
de-normalized float on the N64 they would instead cause a floating point
exception. Because of the way the physics engine works, when two objects
got very close together this would cause de-normalized floats to be
generated and crash the FPU. This was a problem that had me stumped for
a bit, I was concerned I would have to go into bullet’s source code and
modify and calculations to round to zero if the result would be small
enough. This would have been a monumental effort! Thankfully after
digging through the NEC VR4300 programmer’s manual I was able to
discover that there is a mode you can set the FPU to, which forces
rounding towards zero if a de-normalized float would be generated. I
enabled this mode and tested it out, and all my floating point troubles
were resolved! I submitted a &lt;a
href="https://github.com/DragonMinded/libdragon/pull/195"&gt;pull
request&lt;/a&gt; (that was accepted) to the libdragon project to have this
implemented by default, so no one else will run into the same annoying
problems I ran into.&lt;/p&gt;
&lt;h2 id="whats-next"&gt;What’s next?&lt;/h2&gt;
&lt;p&gt;If you decided to play our game you probably would have noticed that
it’s not very much of a game. Even though this is the case I’m very
happy with how the project turned out, as it’s one of the first 3D
libdragon projects to be released. It also easily makes use of amazing
open technologies like bullet physics, showcasing just how easy
libdragon is to integrate with modern tools and libraries. As I
mentioned before in this post there is an effort to take Snacchus’s work
and build an easier to use graphics API that feels more like building
graphics applications and less like building a graphics driver. The
effort for that has already started and I plan to contribute to it. Some
of the cool features this effort is bringing are:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;A standard interface for display lists and microcode overlays.
Easily allowing multiple different microcodes to seamless run on the RSP
and swap out with display list commands. This will be valuable for using
the RSP for audio and graphics at the same time.&lt;/li&gt;
&lt;li&gt;A new 3D microcode that takes some lessons learned from ugfx to
build a more powerful and easier to use interface.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Overall this is an exciting time for Nintendo 64 homebrew
development! It’s easier than ever to build homebrew on the N64 without
knowing about the arcane innards of the console. I hope that this
continued development of libdragon will bring more people to the scene
and allow us to see new and novel games running on the N64. One project
I would be excited to start working on is using the serial port on
modern N64 Flashcarts for networking, allowing the N64 to have online
multiplayer through a computer connected over USB. I feel that projects
like this could really elevate the kind of content that is available on
the N64 and bring it into the modern era.&lt;/p&gt;
</description><pubDate>Fri, 10 Dec 2021 05:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/n64brew-gamejam-2021.html</guid></item><item><title>Rasterizing Triangles</title><link>https://fryzekconcepts.com/notes/rasterizing-triangles.html</link><description>&lt;p&gt;Lately I’ve been trying to implement a software renderer &lt;a
href="https://www.cs.drexel.edu/~david/Classes/Papers/comp175-06-pineda.pdf"&gt;following
the algorithm described by Juan Pineda in “A Parallel Algorithm for
Polygon Rasterization”&lt;/a&gt;. For those unfamiliar with the paper, it
describes an algorithm to rasterize triangles that has an extremely nice
quality, that you simply need to preform a few additions per pixel to
see if the next pixel is inside the triangle. It achieves this quality
by defining an edge function that has the following property:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;E(x+1,y) = E(x,y) + dY
E(x,y+1) = E(x,y) - dX&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This property is extremely nice for a rasterizer as additions are
quite cheap to preform and with this method we limit the amount of work
we have to do per pixel. One frustrating quality of this paper is that
it suggest that you can calculate more properties than just if a pixel
is inside the triangle with simple addition, but provides no explanation
for how to do that. In this blog I would like to explore how you
implement a Pineda style rasterizer that can calculate per pixel values
using simple addition.&lt;/p&gt;
&lt;figure&gt;
&lt;img
src="/assets/2022-04-03-rasterizing-triangles/Screenshot-from-2022-04-03-13-43-13.png"
alt="Triangle rasterized using code in this post" /&gt;
&lt;figcaption aria-hidden="true"&gt;Triangle rasterized using code in this
post&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;In order to figure out how build this rasterizer &lt;a
href="https://www.reddit.com/r/GraphicsProgramming/comments/tqxxmu/interpolating_values_in_a_pineda_style_rasterizer/"&gt;I
reached out to the internet&lt;/a&gt; to help build some more intuition on how
the properties of this rasterizer. From this reddit post I gained more
intuition on how we can use the edge function values to linear
interpolate values on the triangle. Here is there relevant comment that
gave me all the information I needed&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Think about the edge function’s key property:&lt;/p&gt;
&lt;p&gt;&lt;em&gt;recognize that the formula given for E(x,y) is the same as the
formula for the magnitude of the cross product between the vector from
(X,Y) to (X+dX, Y+dY), and the vector from (X,Y) to (x,y). By the well
known property of cross products, the magnitude is zero if the vectors
are colinear, and changes sign as the vectors cross from one side to the
other.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;The magnitude of the edge distance is the area of the parallelogram
formed by &lt;code&gt;(X,Y)-&amp;gt;(X+dX,Y+dY)&lt;/code&gt; and
&lt;code&gt;(X,Y)-&amp;gt;(x,y)&lt;/code&gt;. If you normalize by the parallelogram area
at the &lt;em&gt;other&lt;/em&gt; point in the triangle you get a barycentric
coordinate that’s 0 along the &lt;code&gt;(X,Y)-&amp;gt;(X+dX,Y+dY)&lt;/code&gt; edge
and 1 at the other point. You can precompute each interpolated triangle
parameter normalized by this area at setup time, and in fact most
hardware computes per-pixel step values (pre 1/w correction) so that all
the parameters are computed as a simple addition as you walk along each
raster.&lt;/p&gt;
&lt;p&gt;Note that when you’re implementing all of this it’s critical to keep
all the math in the integer domain (snapping coordinates to some integer
sub-pixel precision, I’d recommend at least 4 bits) and using a
tie-breaking function (typically top-left) for pixels exactly on the
edge to avoid pixel double-hits or gaps in adjacent triangles.&lt;/p&gt;
&lt;p&gt;https://www.reddit.com/r/GraphicsProgramming/comments/tqxxmu/interpolating_values_in_a_pineda_style_rasterizer/i2krwxj/&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;From this comment you can see that it is trivial to calculate to
calculate the barycentric coordinates of the triangle from the edge
function. You simply need to divide the the calculated edge function
value by the area of parallelogram. Now what is the area of triangle?
Well this is where some &lt;a
href="https://www.scratchapixel.com/lessons/3d-basic-rendering/ray-tracing-rendering-a-triangle/barycentric-coordinates"&gt;more
research&lt;/a&gt; online helped. If the edge function defines the area of a
parallelogram (2 times the area of the triangle) of
&lt;code&gt;(X,Y)-&amp;gt;(X+dX,Y+dY)&lt;/code&gt; and &lt;code&gt;(X,Y)-&amp;gt;(x,y)&lt;/code&gt;, and
we calculate three edge function values (one for each edge), then we
have 2 times the area of each of the sub triangles that are defined by
our point.&lt;/p&gt;
&lt;figure&gt;
&lt;img
src="https://www.scratchapixel.com/images/ray-triangle/barycentric.png?"
alt="Triangle barycentric coordinates from scratchpixel tutorial" /&gt;
&lt;figcaption aria-hidden="true"&gt;Triangle barycentric coordinates from
scratchpixel tutorial&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;From this its trivial to see that we can calculate 2 times the area
of the triangle just by adding up all the individual areas of the sub
triangles (I used triangles here, but really we are adding the area of
sub parallelograms to get the area of the whole parallelogram that has 2
times the area of the triangle we are drawing), that is adding the value
of all the edge functions together. From this we can see to linear
interpolate any value on the triangle we can use the following
equation&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;Value(x,y) = (e0*v0 + e1*v1 + e2*v2) / (e0 + e1 + e2)
Value(x,y) = (e0*v0 + e1*v1 + e2*v2) / area&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Where &lt;code&gt;e0, e1, e2&lt;/code&gt; are the edge function values and
&lt;code&gt;v0, v1, v2&lt;/code&gt; are the per vertex values we want to
interpolate.&lt;/p&gt;
&lt;p&gt;This is great for the calculating the per vertex values, but we still
haven’t achieved the property of calculating the interpolate value per
pixel with simple addition. To do that we need to use the property of
the edge function I described above&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;Value(x+1, y) = (E0(x+1, y)*v0 + E1(x+1, y)*v1 + E2(x+1, y)*v2) / area
Value(x+1, y) = ((e0+dY0)*v0 + (e1+dY1)*v1 + (e2+dY2)*v2) / area
Value(x+1, y) = (e0*v0 + dY0*v0 + e1*v1+dY1*v1 + e2*v2 + dY2*v2) / area
Value(x+1, y) = (e0*v0 + e1*v1 + e2*v2)/area + (dY0*v0 + dY1*v1 + dY2*v2)/area
Value(x+1, y) = Value(x,y) + (dY0*v0 + dY1*v1 + dY2*v2)/area&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;From here we can see that if we work through all the math, we can
find this same property where the interpolated value is equal to the
previous interpolated value plus some number. Therefore if we
pre-compute this addition value, when we iterate over the pixels we only
need to add this pre-computed number to the interpolated value of the
previous pixel. We can repeat this process again to figure out the
equation of the pre-computed value for &lt;code&gt;Value(x, y+1)&lt;/code&gt; but
I’ll save you the time and provide both equations below&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;dYV = (dY0*v0 + dY1*v1 + dY2*v2)/area
dXV = (dX0*v0 + dX1*v1 + dX2*v2)/area
Value(x+1, y) = Value(x,y) + dYV
Value(x, y+1) = Value(x,y) - dXV&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Where &lt;code&gt;dY0, dY1, dY2&lt;/code&gt; are the differences between y
coordinates as described in Pineda’s paper, &lt;code&gt;dX0, dX1, dX2&lt;/code&gt;
are the differences in x coordinates as described in Pineda’s paper, and
the area is the pre-calculated sum of the edge functions&lt;/p&gt;
&lt;p&gt;Now you should be able to build a Pineda style rasterizer that can
calculate per pixel interpolated values using simple addition, by
following pseudo code like this:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;func edge(x, y, xi, yi, dXi, dYi)
    return (x - xi)*dYi - (y-yi)*dXi

func draw_triangle(x0, y0, x1, y1, x2, y2, v0, v1, v2):
    dX0 = x0 - x2
    dX1 = x1 - x0
    dX2 = x2 - x1
    dY0 = y0 - y2
    dY1 = y1 - y0
    dY2 = y2 - y1
    start_x = 0
    start_y = 0
    e0 = edge(start_x, start_y, x0, y0, dX0, dY0)
    e1 = edge(start_x, start_y, x1, y1, dX1, dY1)
    e2 = edge(start_x, start_y, x2, y2, dX2, dY2)
    area = e0 + e1 + e2
    dYV = (dY0*v0 + dY1*v1 + dY2*v2) / area
    dXV = (dX0*v0 + dX1*v1 + dX2*v2) / area

    v = (e0*v0 + e1*v1 + e2*v2) / area

    starting_e0 = e0
    starting_e1 = e1
    starting_e2 = e2
    starting_v = v

    for y = 0 to screen_height:
        for x = 0 to screen_width:
            if(e0 &amp;gt;= 0 &amp;amp;&amp;amp; e1 &amp;gt;= 0 &amp;amp;&amp;amp; e2 &amp;gt;= 0)
                draw_pixel(x, y, v)
            e0 = e0 + dY0
            e1 = e1 + dY1
            e2 = e2 + dY2
            v = v + dYV

        e0 = starting_e0 - dX0
        e1 = starting_e1 - dX1
        e2 = starting_e2 - dX2
        v = starting_v - dXV

        starting_e0 = e0
        starting_e1 = e1
        starting_e2 = e2
        starting_v = v&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Now this pseudo code is not the most efficient as it will iterate
over the entire screen to draw one triangle, but it provides a starting
basis to show how to use these Pineda properties to calculate per vertex
values. One thing to note if you do implement this is, if you use fixed
point arithmetic, be careful to insure you have enough precision to
calculate all of these values with overflow or underflow. This was an
issue I ran into running out of precision when I did the divide by the
area.&lt;/p&gt;
</description><pubDate>Sun, 03 Apr 2022 04:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/rasterizing-triangles.html</guid></item><item><title>Baremetal RISC-V</title><link>https://fryzekconcepts.com/notes/baremetal-risc-v.html</link><description>&lt;p&gt;After re-watching suckerpinch’s &lt;a
href="https://www.youtube.com/watch?v=ar9WRwCiSr0"&gt;“Reverse
Emulation”&lt;/a&gt; video I got inspired to try and replicate what he did,
but instead do it on an N64. Now my idea here is not to preform reverse
emulation on the N64 itself but instead to use the SBC as a cheap way to
make a dev focused flash cart. Seeing that sukerpinch was able to meet
the timings of the NES bus made me think it might be possible to meet
the N64 bus timings taking an approach similar to his.&lt;/p&gt;
&lt;h2 id="why-risc-v-baremetal"&gt;Why RISC-V Baremetal?&lt;/h2&gt;
&lt;p&gt;The answer here is more utilitarian then idealistic, I originally
wanted to use a Raspberry Pi since I thought that board may be more
accessible if other people want to try and replicate this project.
Instead what I found is that it is impossible to procure a Raspberry Pi.
Not to be deterred I purchased a &lt;a
href="https://linux-sunxi.org/Allwinner_Nezha"&gt;“Allwinner Nezha”&lt;/a&gt; a
while back and its just been collecting dust in my storage. I figured
this would be a good project to test the board out on since it has a
large amount of RAM (1GB on my board), a fast processor (1 GHz), and
accessible GPIO. As for why baremetal? Well one of the big problems
suckerpinch ran into was being interrupted by the Linux kernel while his
software was running. The board was fast enough to respond to the bus
timings but Linux would throw off those timings with preemption. This is
why I’m taking the approach to do everything baremetal. Giving 100% of
the CPU time to my program emulating the CPU bus.&lt;/p&gt;
&lt;h2 id="risc-v-baremetal-development"&gt;RISC-V Baremetal Development&lt;/h2&gt;
&lt;p&gt;Below I’ll document how I got a baremetal program running on the
Nezha board, to provide guidance to anyone who wants to try doing
something like this themselves.&lt;/p&gt;
&lt;h3 id="toolchain-setup"&gt;Toolchain Setup&lt;/h3&gt;
&lt;p&gt;In order to do any RISC-V development we will need to setup a RISC-V
toolchain that isn’t tied to a specific OS like linux. Thankfully the
RISC-V org set up a simple to use git repo that has a script to build an
entire RISC-V toolchain on your machine. Since you’re building the whole
toolchain from source this will take some time on my machine (Ryzen
4500u, 16GB of RAM, 1TB PCIe NVMe storage), it took around ~30 minutes
to build the whole tool chain. You can find the repo &lt;a
href="https://github.com/riscv-collab/riscv-gnu-toolchain"&gt;here&lt;/a&gt;, and
follow the instructions in the &lt;code&gt;Installation (Newlib)&lt;/code&gt;
section of the README. That will setup a bare bones OS independent
toolchain that can use newlib for the cstdlib (not that I am currently
using it in my software).&lt;/p&gt;
&lt;h3 id="setting-up-a-program"&gt;Setting up a Program&lt;/h3&gt;
&lt;p&gt;This is probably one of the more complicated steps in baremetal
programming as this will involve setting up a linker script, which can
sometimes feel like an act of black magic to get right. I’ll try to walk
through some linker script basics to show how I setup mine. The linker
script &lt;code&gt;linker.ld&lt;/code&gt; I’m using is below&lt;/p&gt;
&lt;pre class="ld"&gt;&lt;code&gt;SECTIONS
{
    . = 0x45000000;
    .text : {
        PROVIDE(__text_start = .);
        *(.text.start)
        *(.text*)
        . = ALIGN(4096);
        PROVIDE(__text_end = .);
    }
    .data : {
        PROVIDE(__data_start = .);
        . = ALIGN(16);
        *(.rodata*);
        *(.data .data.*)
        PROVIDE(__data_end = .);
    }
    . += 1024;
    PROVIDE(__stack_start = .);
    . = ALIGN(16);
    . += 4096;
    PROVIDE(__stack_end = .);

    /DISCARD/ :
    {
        *(.riscv.attributes);
        *(.comment);
    }
}&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The purpose of a linkscript is to describe how our binary will be
organized, the script I wrote will do the follow&lt;/p&gt;
&lt;ol type="1"&gt;
&lt;li&gt;Start the starting address offset to &lt;code&gt;0x45000000&lt;/code&gt;, This
is the address we are going to load the binary into memory, so any
pointers in the program will need to be offset from this address&lt;/li&gt;
&lt;li&gt;start the binary off with the &lt;code&gt;.text&lt;/code&gt; section which will
contain the executable code, in the text section we want the code for
&lt;code&gt;.text.start&lt;/code&gt; to come first. this is the code that implements
the “C runtime”. That is this is the code with the &lt;code&gt;_start&lt;/code&gt;
function that will setup the stack pointer and call into the C
&lt;code&gt;main&lt;/code&gt; function. After that we will place the text for all
the other functions in our binary. We keep this section aligned to
&lt;code&gt;4096&lt;/code&gt; bytes, and the &lt;code&gt;PROVIDE&lt;/code&gt; functions creates
a symbol with a pointer to that location in memory. We won’t use the
text start and end pointers in our program but it can be useful if you
want to know stuff about your binary at runtime of your program&lt;/li&gt;
&lt;li&gt;Next is the &lt;code&gt;.data&lt;/code&gt; section that has all the data for our
program. Here you can see I also added the &lt;code&gt;rodata&lt;/code&gt; or read
only section to the data section. The reason I did this is because I’m
not going to bother with properly implementing read only data. We also
keep the data aligned to 16 bytes to ensure that every memory access
will be aligned for a 64bit RISCV memory access.&lt;/li&gt;
&lt;li&gt;The last “section” is not a real section but some extra padding at
the end to reserve the stack. Here I am reserving 4096 (4Kb) for the
stack of my program.&lt;/li&gt;
&lt;li&gt;Lastly I’m going to discard a few sections that GCC will compile
into the binary that I don’t need at all.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Now this probably isn’t the best way to write a linker script. For
example the stack is just kind of a hack in it, and I don’t implement
the &lt;code&gt;.bss&lt;/code&gt; section for zero initialized data.&lt;/p&gt;
&lt;p&gt;With this linker script we can now setup a basic program, we can use
the code presented below as the &lt;code&gt;main.c&lt;/code&gt; file&lt;/p&gt;
&lt;div class="sourceCode" id="cb2"&gt;&lt;pre class="sourceCode c"&gt;&lt;code class="sourceCode c"&gt;&lt;span id="cb2-1"&gt;&lt;a href="#cb2-1" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="pp"&gt;#include &lt;/span&gt;&lt;span class="im"&gt;&amp;lt;stdint.h&amp;gt;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-2"&gt;&lt;a href="#cb2-2" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb2-3"&gt;&lt;a href="#cb2-3" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="pp"&gt;#define UART0_BASE &lt;/span&gt;&lt;span class="bn"&gt;0x02500000&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-4"&gt;&lt;a href="#cb2-4" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="pp"&gt;#define UART0_DATA_REG &lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;UART0_BASE&lt;span class="pp"&gt; &lt;/span&gt;&lt;span class="op"&gt;+&lt;/span&gt;&lt;span class="pp"&gt; &lt;/span&gt;&lt;span class="bn"&gt;0x0000&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-5"&gt;&lt;a href="#cb2-5" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="pp"&gt;#define UART0_USR &lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;UART0_BASE&lt;span class="pp"&gt; &lt;/span&gt;&lt;span class="op"&gt;+&lt;/span&gt;&lt;span class="pp"&gt; &lt;/span&gt;&lt;span class="bn"&gt;0x007c&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-6"&gt;&lt;a href="#cb2-6" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb2-7"&gt;&lt;a href="#cb2-7" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="pp"&gt;#define write_reg&lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="pp"&gt;r&lt;/span&gt;&lt;span class="op"&gt;,&lt;/span&gt;&lt;span class="pp"&gt; v&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt;&lt;span class="pp"&gt; write_reg_handler&lt;/span&gt;&lt;span class="op"&gt;((&lt;/span&gt;&lt;span class="dt"&gt;volatile&lt;/span&gt;&lt;span class="pp"&gt; &lt;/span&gt;&lt;span class="dt"&gt;uint32_t&lt;/span&gt;&lt;span class="op"&gt;*)(&lt;/span&gt;&lt;span class="pp"&gt;r&lt;/span&gt;&lt;span class="op"&gt;),&lt;/span&gt;&lt;span class="pp"&gt; &lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="pp"&gt;v&lt;/span&gt;&lt;span class="op"&gt;))&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-8"&gt;&lt;a href="#cb2-8" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;void&lt;/span&gt; write_reg_handler&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="dt"&gt;volatile&lt;/span&gt; &lt;span class="dt"&gt;uint32_t&lt;/span&gt; &lt;span class="op"&gt;*&lt;/span&gt;reg&lt;span class="op"&gt;,&lt;/span&gt; &lt;span class="dt"&gt;const&lt;/span&gt; &lt;span class="dt"&gt;uint32_t&lt;/span&gt; value&lt;span class="op"&gt;)&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-9"&gt;&lt;a href="#cb2-9" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;{&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-10"&gt;&lt;a href="#cb2-10" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    reg&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; &lt;span class="op"&gt;=&lt;/span&gt; value&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-11"&gt;&lt;a href="#cb2-11" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;}&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-12"&gt;&lt;a href="#cb2-12" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb2-13"&gt;&lt;a href="#cb2-13" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="pp"&gt;#define read_reg&lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="pp"&gt;r&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt;&lt;span class="pp"&gt; read_reg_handler&lt;/span&gt;&lt;span class="op"&gt;((&lt;/span&gt;&lt;span class="dt"&gt;volatile&lt;/span&gt;&lt;span class="pp"&gt; &lt;/span&gt;&lt;span class="dt"&gt;uint32_t&lt;/span&gt;&lt;span class="op"&gt;*)(&lt;/span&gt;&lt;span class="pp"&gt;r&lt;/span&gt;&lt;span class="op"&gt;))&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-14"&gt;&lt;a href="#cb2-14" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;uint32_t&lt;/span&gt; read_reg_handler&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="dt"&gt;volatile&lt;/span&gt; &lt;span class="dt"&gt;uint32_t&lt;/span&gt; &lt;span class="op"&gt;*&lt;/span&gt;reg&lt;span class="op"&gt;)&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-15"&gt;&lt;a href="#cb2-15" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;{&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-16"&gt;&lt;a href="#cb2-16" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="cf"&gt;return&lt;/span&gt; reg&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;];&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-17"&gt;&lt;a href="#cb2-17" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;}&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-18"&gt;&lt;a href="#cb2-18" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb2-19"&gt;&lt;a href="#cb2-19" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;void&lt;/span&gt; _putchar&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="dt"&gt;char&lt;/span&gt; c&lt;span class="op"&gt;)&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-20"&gt;&lt;a href="#cb2-20" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;{&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-21"&gt;&lt;a href="#cb2-21" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="cf"&gt;while&lt;/span&gt;&lt;span class="op"&gt;((&lt;/span&gt;read_reg&lt;span class="op"&gt;(&lt;/span&gt;UART0_USR&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="op"&gt;&amp;amp;&lt;/span&gt; &lt;span class="bn"&gt;0b10&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt; &lt;span class="op"&gt;==&lt;/span&gt; &lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;)&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-22"&gt;&lt;a href="#cb2-22" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="op"&gt;{&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-23"&gt;&lt;a href="#cb2-23" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        asm&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;nop&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-24"&gt;&lt;a href="#cb2-24" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="op"&gt;}&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-25"&gt;&lt;a href="#cb2-25" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb2-26"&gt;&lt;a href="#cb2-26" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    write_reg&lt;span class="op"&gt;(&lt;/span&gt;UART0_DATA_REG&lt;span class="op"&gt;,&lt;/span&gt; c&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-27"&gt;&lt;a href="#cb2-27" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;}&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-28"&gt;&lt;a href="#cb2-28" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb2-29"&gt;&lt;a href="#cb2-29" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;const&lt;/span&gt; &lt;span class="dt"&gt;char&lt;/span&gt; &lt;span class="op"&gt;*&lt;/span&gt;hello_world &lt;span class="op"&gt;=&lt;/span&gt; &lt;span class="st"&gt;&amp;quot;Hello World!&lt;/span&gt;&lt;span class="sc"&gt;\r\n&lt;/span&gt;&lt;span class="st"&gt;&amp;quot;&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-30"&gt;&lt;a href="#cb2-30" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;/span&gt;
&lt;span id="cb2-31"&gt;&lt;a href="#cb2-31" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="dt"&gt;int&lt;/span&gt; main&lt;span class="op"&gt;()&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-32"&gt;&lt;a href="#cb2-32" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;{&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-33"&gt;&lt;a href="#cb2-33" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="cf"&gt;for&lt;/span&gt;&lt;span class="op"&gt;(&lt;/span&gt;&lt;span class="dt"&gt;const&lt;/span&gt; &lt;span class="dt"&gt;char&lt;/span&gt; &lt;span class="op"&gt;*&lt;/span&gt;c &lt;span class="op"&gt;=&lt;/span&gt; hello_world&lt;span class="op"&gt;;&lt;/span&gt; c&lt;span class="op"&gt;[&lt;/span&gt;&lt;span class="dv"&gt;0&lt;/span&gt;&lt;span class="op"&gt;]&lt;/span&gt; &lt;span class="op"&gt;!=&lt;/span&gt; &lt;span class="ch"&gt;&amp;#39;&lt;/span&gt;&lt;span class="sc"&gt;\0&lt;/span&gt;&lt;span class="ch"&gt;&amp;#39;&lt;/span&gt;&lt;span class="op"&gt;;&lt;/span&gt; c&lt;span class="op"&gt;++)&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-34"&gt;&lt;a href="#cb2-34" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="op"&gt;{&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-35"&gt;&lt;a href="#cb2-35" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;        _putchar&lt;span class="op"&gt;(&lt;/span&gt;c&lt;span class="op"&gt;);&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-36"&gt;&lt;a href="#cb2-36" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    &lt;span class="op"&gt;}&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb2-37"&gt;&lt;a href="#cb2-37" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="op"&gt;}&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;This program will write the string “Hello World!” to the serial port.
Now a common question for code like this is how did I know to set all
the &lt;code&gt;UART0&lt;/code&gt; registers? Well the way to find this information
is to look at the datasheet, programmer’s manual, or user manual for the
chip you are using. In this case we are using an Allwinner D1 and we can
find the user manual with all the registers on the linux-sunxi page &lt;a
href="https://linux-sunxi.org/D1"&gt;here&lt;/a&gt;. On pages 900 to 940 we can
see a description on how the serial works for this SoC. I also looked at
the schematic &lt;a
href="https://dl.linux-sunxi.org/D1/D1_Nezha_development_board_schematic_diagram_20210224.pdf"&gt;here&lt;/a&gt;,
to see that the serial port we have is wired to &lt;code&gt;UART0&lt;/code&gt; on
the SoC. From here we are relying on uboot to boot the board which will
setup the serial port for us, which means we can just write to the UART
data register to start printing content to the console.&lt;/p&gt;
&lt;p&gt;We will also need need to setup a basic assembly program to setup the
stack and call our main function. Below you can see my example called
&lt;code&gt;start.S&lt;/code&gt;&lt;/p&gt;
&lt;div class="sourceCode" id="cb3"&gt;&lt;pre
class="sourceCode asm"&gt;&lt;code class="sourceCode fasm"&gt;&lt;span id="cb3-1"&gt;&lt;a href="#cb3-1" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;.&lt;span class="bu"&gt;section&lt;/span&gt; &lt;span class="op"&gt;.&lt;/span&gt;text&lt;span class="op"&gt;.&lt;/span&gt;start&lt;/span&gt;
&lt;span id="cb3-2"&gt;&lt;a href="#cb3-2" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    .global _start&lt;/span&gt;
&lt;span id="cb3-3"&gt;&lt;a href="#cb3-3" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;&lt;span class="fu"&gt;_start:&lt;/span&gt;&lt;/span&gt;
&lt;span id="cb3-4"&gt;&lt;a href="#cb3-4" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    la &lt;span class="kw"&gt;sp&lt;/span&gt;&lt;span class="op"&gt;,&lt;/span&gt; __stack_start&lt;/span&gt;
&lt;span id="cb3-5"&gt;&lt;a href="#cb3-5" aria-hidden="true" tabindex="-1"&gt;&lt;/a&gt;    j main&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;This assembly file just creates a section called
&lt;code&gt;.text.start&lt;/code&gt; and a global symbol for a function called
&lt;code&gt;_start&lt;/code&gt; which will be the first function our program
executes. All this assembly file does is setup the stack pointer
register &lt;code&gt;sp&lt;/code&gt; to with the address (using the load address
&lt;code&gt;la&lt;/code&gt; pseudo instruction) to the stack we setup in the linker
script, and then call the main function by jumping directly to it.&lt;/p&gt;
&lt;h3 id="building-the-program"&gt;Building the Program&lt;/h3&gt;
&lt;p&gt;Building the program is pretty straight forward, we need to tell gcc
to build the two source files without including the c standard library,
and then to link the binary using our linker script. we can do this with
the following command&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;riscv64-unknown-elf-gcc march=rv64g --std=gnu99 -msmall-data-limit=0 -c main.c
riscv64-unknown-elf-gcc march=rv64g --std=gnu99 -msmall-data-limit=0 -c start.S
riscv64-unknown-elf-gcc march=rv64g -march=rv64g -ffreestanding -nostdlib -msmall-data-limit=0 -T linker.ld start.o main.o -o app.elf
riscv64-unknown-elf-objcopy -O binary app.elf app.bin&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This will build our source files into &lt;code&gt;.o&lt;/code&gt; files first,
then combine those &lt;code&gt;.o&lt;/code&gt; files into a &lt;code&gt;.elf&lt;/code&gt; file,
finally converting the &lt;code&gt;.elf&lt;/code&gt; into a raw binary file where we
use the &lt;code&gt;.bin&lt;/code&gt; extension. We need a raw binary file as we
want to just load our program into memory and begin executing. If we
load the &lt;code&gt;.elf&lt;/code&gt; file it will have the elf header and other
extra data that is not executable in it. In order to run a
&lt;code&gt;.elf&lt;/code&gt; file we would need an elf loader, which goes beyond
the scope of this example.&lt;/p&gt;
&lt;h3 id="running-the-program"&gt;Running the Program&lt;/h3&gt;
&lt;p&gt;Now we have the raw binary its time to try and load it. I found that
the uboot configuration that comes with the board has pretty limited
support for loading binaries. So we are going to take advantage of the
&lt;code&gt;loadx&lt;/code&gt; command to load the binary over serial. In the uboot
terminal we are going to run the command:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;loadx 45000000&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Now the next steps will depend on which serial terminal you are
using. We want to use the &lt;code&gt;XMODEM&lt;/code&gt; protocol to load the
binary. In the serial terminal I am using &lt;code&gt;gnu screen&lt;/code&gt; you
can execute arbitrary programs and send their output to the serial
terminal. You can do this by hitting the key combination “CTRL-A + :”
and then typing in &lt;code&gt;exec !! sx app.bin&lt;/code&gt;. This will send the
binary to the serial terminal using the XMODEM protocol. If you are not
using GNU screen look up instructions for how to send an XMODEM binary.
Now that the binary is loaded we can type in&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;go 45000000&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The should start to execute the program and you should see
&lt;code&gt;Hello World!&lt;/code&gt; printed to the console!&lt;/p&gt;
&lt;p&gt;&lt;img
src="/assets/2022-06-09-baremetal-risc-v/riscv-terminal.png" /&gt;&lt;/p&gt;
&lt;h2 id="whats-next"&gt;What’s Next?&lt;/h2&gt;
&lt;p&gt;Well the sky is the limit! We have a method to load and run a program
that can do anything on the Nezha board now. Looking through the
datasheet we can see how to access the GPIO on the board to blink an
LED. If you’re really ambitious you could try getting ethernet or USB
working in a baremetal environment. I am going to continue on my goal of
emulating the N64 cartridge bus which will require me to get GPIO
working as well as interrupts on the GPIO lines. If you want to see the
current progress of my work you can check it out on github &lt;a
href="https://github.com/Hazematman/N64-Cart-Emulator"&gt;here&lt;/a&gt;.&lt;/p&gt;
</description><pubDate>Thu, 09 Jun 2022 04:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/baremetal-risc-v.html</guid></item><item><title>Digital Garden</title><link>https://fryzekconcepts.com/notes/digital_garden.html</link><description>&lt;p&gt;After reading Maggie Appleton page on &lt;a
href="https://maggieappleton.com/garden-history"&gt;digital gardens&lt;/a&gt; I
was inspired to convert my own website into a digital garden.&lt;/p&gt;
&lt;p&gt;I have many half baked ideas that I seem to be able to finish. Some
of them get to a published state like &lt;a
href="/notes/rasterizing-triangles.html"&gt;Rasterizing Triangles&lt;/a&gt; and
&lt;a href="/notes/baremetal-risc-v.html"&gt;Baremetal RISC-V&lt;/a&gt;, but many of
them never make it to the published state. The idea of digital garden
seems very appealing to me, as it encourages you to post on a topic even
if you haven’t made it “publishable” yet.&lt;/p&gt;
&lt;h2 id="how-this-site-works"&gt;How this site works&lt;/h2&gt;
&lt;p&gt;I wanted a bit of challenge when putting together this website as I
don’t do a lot of web development in my day to day life, so I thought it
would be a good way to learn more things. This site has been entirely
built from scratch using a custom static site generator I setup with
pandoc. It relies on pandoc’s filters to implement some of the classic
“Digital Garden” features like back linking. The back linking feature
has not been totally developed yet and right now it just provides with a
convenient way to link to other notes or pages on this site.&lt;/p&gt;
&lt;p&gt;I hope to develop this section more and explain how I got various
features in pandoc to work as a static site generator.&lt;/p&gt;
</description><pubDate>Sun, 30 Oct 2022 04:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/digital_garden.html</guid></item><item><title>2022 Graphics Team Contributions at Igalia</title><link>https://fryzekconcepts.com/notes/2022_igalia_graphics_team.html</link><description>&lt;p&gt;This year I started a new job working with &lt;a
href="https://www.igalia.com/technology/graphics"&gt;Igalia’s Graphics
Team&lt;/a&gt;. For those of you who don’t know &lt;a
href="https://www.igalia.com/"&gt;Igalia&lt;/a&gt; they are a &lt;a
href="https://en.wikipedia.org/wiki/Igalia"&gt;“worker-owned, employee-run
cooperative model consultancy focused on open source software”&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;As a new member of the team, I thought it would be a great idea to
summarize the incredible amount of work the team completed in 2022. If
you’re interested keep reading!&lt;/p&gt;
&lt;h2 id="vulkan-1.2-conformance-on-rpi-4"&gt;Vulkan 1.2 Conformance on RPi
4&lt;/h2&gt;
&lt;p&gt;One of the big milestones for the team in 2022 was &lt;a
href="https://www.khronos.org/conformance/adopters/conformant-products#submission_694"&gt;achieving
Vulkan 1.2 conformance on the Raspberry Pi 4&lt;/a&gt;. The folks over at the
Raspberry Pi company wrote a nice &lt;a
href="https://www.raspberrypi.com/news/vulkan-update-version-1-2-conformance-for-raspberry-pi-4/"&gt;article&lt;/a&gt;
about the achievement. Igalia has been partnering with the Raspberry Pi
company to bring build and improve the graphics driver on all versions
of the Raspberry Pi.&lt;/p&gt;
&lt;p&gt;The Vulkan 1.2 spec ratification came with a few &lt;a
href="https://registry.khronos.org/vulkan/specs/1.2-extensions/html/vkspec.html#versions-1.2"&gt;extensions&lt;/a&gt;
that were promoted to Core. This means a conformant Vulkan 1.2 driver
needs to implement those extensions. Alejandro Piñeiro wrote this
interesting &lt;a
href="https://blogs.igalia.com/apinheiro/2022/05/v3dv-status-update-2022-05-16/"&gt;blog
post&lt;/a&gt; that talks about some of those extensions.&lt;/p&gt;
&lt;p&gt;Vulkan 1.2 also came with a number of optional extensions such as
&lt;code&gt;VK_KHR_pipeline_executable_properties&lt;/code&gt;. My colleague Iago
Toral wrote an excellent &lt;a
href="https://blogs.igalia.com/itoral/2022/05/09/vk_khr_pipeline_executables/"&gt;blog
post&lt;/a&gt; on how we implemented that extension on the Raspberry Pi 4 and
what benefits it provides for debugging.&lt;/p&gt;
&lt;h2 id="vulkan-1.3-support-on-turnip"&gt;Vulkan 1.3 support on Turnip&lt;/h2&gt;
&lt;p&gt;Igalia has been heavily supporting the Open-Source Turnip Vulkan
driver for Qualcomm Adreno GPUs, and in 2022 we helped it achieve Vulkan
1.3 conformance. Danylo Piliaiev on the graphics team here at Igalia,
wrote a great &lt;a
href="https://blogs.igalia.com/dpiliaiev/turnip-vulkan-1-3/"&gt;blog
post&lt;/a&gt; on this achievement! One of the biggest challenges for the
Turnip driver is that it is a completely reverse-engineered driver that
has been built without access to any hardware documentation or reference
driver code.&lt;/p&gt;
&lt;p&gt;With Vulkan 1.3 conformance has also come the ability to run more
commercial games on Adreno GPUs through the use of the DirectX
translation layers. If you would like to see more of this check out this
&lt;a
href="https://blogs.igalia.com/dpiliaiev/turnip-july-2022-update/"&gt;post&lt;/a&gt;
from Danylo where he talks about getting “The Witcher 3”, “The Talos
Principle”, and “OMD2” running on the A660 GPU. Outside of Vulkan 1.3
support he also talks about some of the extensions that were implemented
to allow “Zink” (the OpenGL over Vulkan driver) to run Turnip, and bring
OpenGL 4.6 support to Adreno GPUs.&lt;/p&gt;
&lt;p&gt;&lt;div class="youtube-video"&gt;&lt;iframe src="https://www.youtube.com/embed/oVFWy25uiXA"&gt;&lt;/iframe&gt;&lt;/div&gt;&lt;/p&gt;
&lt;h2 id="vulkan-extensions"&gt;Vulkan Extensions&lt;/h2&gt;
&lt;p&gt;Several developers on the Graphics Team made several key
contributions to Vulkan Extensions and the Vulkan conformance test suite
(CTS). My colleague Ricardo Garcia made an excellent &lt;a
href="https://rg3.name/202212122137.html"&gt;blog post&lt;/a&gt; about those
contributions. Below I’ve listed what Igalia did for each of the
extensions:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;VK_EXT_image_2d_view_of_3d
&lt;ul&gt;
&lt;li&gt;We reviewed the spec and are listed as contributors to this
extension&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_EXT_shader_module_identifier
&lt;ul&gt;
&lt;li&gt;We reviewed the spec, contributed to it, and created tests for this
extension&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_EXT_attachment_feedback_loop_layout
&lt;ul&gt;
&lt;li&gt;We reviewed, created tests and contributed to this extension&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_EXT_mesh_shader
&lt;ul&gt;
&lt;li&gt;We contributed to the spec and created tests for this extension&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_EXT_mutable_descriptor_type
&lt;ul&gt;
&lt;li&gt;We reviewed the spec and created tests for this extension&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_EXT_extended_dynamic_state3
&lt;ul&gt;
&lt;li&gt;We wrote tests and reviewed the spec for this extension&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="amdgpu-kernel-driver-contributions"&gt;AMDGPU kernel driver
contributions&lt;/h2&gt;
&lt;p&gt;Our resident “Not an AMD expert” Melissa Wen made several
contributions to the AMDGPU driver. Those contributions include
connecting parts of the &lt;a
href="https://lore.kernel.org/amd-gfx/20220329201835.2393141-1-mwen@igalia.com/"&gt;pixel
blending and post blending code in AMD’s &lt;code&gt;DC&lt;/code&gt; module to
&lt;code&gt;DRM&lt;/code&gt;&lt;/a&gt; and &lt;a
href="https://lore.kernel.org/amd-gfx/20220804161349.3561177-1-mwen@igalia.com/"&gt;fixing
a bug related to how panel orientation is set when a display is
connected&lt;/a&gt;. She also had a &lt;a
href="https://indico.freedesktop.org/event/2/contributions/50/"&gt;presentation
at XDC 2022&lt;/a&gt;, where she talks about techniques you can use to
understand and debug AMDGPU, even when there aren’t hardware docs
available.&lt;/p&gt;
&lt;p&gt;André Almeida also completed and submitted work on &lt;a
href="https://lore.kernel.org/dri-devel/20220714191745.45512-1-andrealmeid@igalia.com/"&gt;enabled
logging features for the new GFXOFF hardware feature in AMD GPUs&lt;/a&gt;. He
also created a userspace application (which you can find &lt;a
href="https://gitlab.freedesktop.org/andrealmeid/gfxoff_tool"&gt;here&lt;/a&gt;),
that lets you interact with this feature through the
&lt;code&gt;debugfs&lt;/code&gt; interface. Additionally, he submitted a &lt;a
href="https://lore.kernel.org/dri-devel/20220929184307.258331-1-contact@emersion.fr/"&gt;patch&lt;/a&gt;
for async page flips (which he also talked about in his &lt;a
href="https://indico.freedesktop.org/event/2/contributions/61/"&gt;XDC 2022
presentation&lt;/a&gt;) which is still yet to be merged.&lt;/p&gt;
&lt;h2 id="modesetting-without-glamor-on-rpi"&gt;Modesetting without Glamor on
RPi&lt;/h2&gt;
&lt;p&gt;Christopher Michael joined the Graphics Team in 2022 and along with
Chema Casanova made some key contributions to enabling hardware
acceleration and mode setting on the Raspberry Pi without the use of &lt;a
href="https://www.freedesktop.org/wiki/Software/Glamor/"&gt;Glamor&lt;/a&gt;
which allows making more video memory available to graphics applications
running on a Raspberry Pi.&lt;/p&gt;
&lt;p&gt;The older generation Raspberry Pis (1-3) only have a maximum of 256MB
of memory available for video memory, and using Glamor will consume part
of that video memory. Christopher wrote an excellent &lt;a
href="https://blogs.igalia.com/cmichael/2022/05/30/modesetting-a-glamor-less-rpi-adventure/"&gt;blog
post&lt;/a&gt; on this work. Both him and Chema also had a joint presentation
at XDC 2022 going into more detail on this work.&lt;/p&gt;
&lt;h2 id="linux-format-magazine-column"&gt;Linux Format Magazine Column&lt;/h2&gt;
&lt;p&gt;Our very own Samuel Iglesias had a column published in Linux Format
Magazine. It’s a short column about reaching Vulkan 1.1 conformance for
v3dv &amp;amp; Turnip Vulkan drivers, and how Open-Source GPU drivers can go
from a “hobby project” to the defacto driver for the platform. Check it
out on page 7 of &lt;a
href="https://linuxformat.com/linux-format-288.html"&gt;issue #288&lt;/a&gt;!&lt;/p&gt;
&lt;h2 id="xdc-2022"&gt;XDC 2022&lt;/h2&gt;
&lt;p&gt;X.Org Developers Conference is one of the big conferences for us here
at the Graphics Team. Last year at XDC 2022 our Team presented 5 talks
in Minneapolis, Minnesota. XDC 2022 took place towards the end of the
year in October, so it provides some good context on how the team closed
out the year. If you didn’t attend or missed their presentation, here’s
a breakdown:&lt;/p&gt;
&lt;h3
id="replacing-the-geometry-pipeline-with-mesh-shaders-ricardo-garcía"&gt;&lt;a
href="https://indico.freedesktop.org/event/2/contributions/48/"&gt;“Replacing
the geometry pipeline with mesh shaders”&lt;/a&gt; (Ricardo García)&lt;/h3&gt;
&lt;p&gt;Ricardo presents what exactly mesh shaders are in Vulkan. He made
many contributions to this extension including writing 1000s of CTS
tests for this extension with a &lt;a
href="https://rg3.name/202210222107.html"&gt;blog post&lt;/a&gt; on his
presentation that should check out!&lt;/p&gt;
&lt;p&gt;&lt;div class="youtube-video"&gt;&lt;iframe src="https://www.youtube.com/embed/aRNJ4xj_nDs"&gt;&lt;/iframe&gt;&lt;/div&gt;&lt;/p&gt;
&lt;h3 id="status-of-vulkan-on-raspberry-pi-iago-toral"&gt;&lt;a
href="https://indico.freedesktop.org/event/2/contributions/68/"&gt;“Status
of Vulkan on Raspberry Pi”&lt;/a&gt; (Iago Toral)&lt;/h3&gt;
&lt;p&gt;Iago goes into detail about the current status of the Raspberry Pi
Vulkan driver. He talks about achieving Vulkan 1.2 conformance, as well
as some of the challenges the team had to solve due to hardware
limitations of the Broadcom GPU.&lt;/p&gt;
&lt;p&gt;&lt;div class="youtube-video"&gt;&lt;iframe src="https://www.youtube.com/embed/GM9IojyzCVM"&gt;&lt;/iframe&gt;&lt;/div&gt;&lt;/p&gt;
&lt;h3
id="enable-hardware-acceleration-for-gl-applications-without-glamor-on-xorg-modesetting-driver-jose-maría-casanova-christopher-michael"&gt;&lt;a
href="https://indico.freedesktop.org/event/2/contributions/60/"&gt;“Enable
hardware acceleration for GL applications without Glamor on Xorg
modesetting driver”&lt;/a&gt; (Jose María Casanova, Christopher Michael)&lt;/h3&gt;
&lt;p&gt;Chema and Christopher talk about the challenges they had to solve to
enable hardware acceleration on the Raspberry Pi without Glamor.&lt;/p&gt;
&lt;p&gt;&lt;div class="youtube-video"&gt;&lt;iframe src="https://www.youtube.com/embed/Bo_MOM7JTeQ"&gt;&lt;/iframe&gt;&lt;/div&gt;&lt;/p&gt;
&lt;h3 id="im-not-an-amd-expert-but-melissa-wen"&gt;&lt;a
href="https://indico.freedesktop.org/event/2/contributions/50/"&gt;“I’m not
an AMD expert, but…”&lt;/a&gt; (Melissa Wen)&lt;/h3&gt;
&lt;p&gt;In this non-technical presentation, Melissa talks about techniques
developers can use to understand and debug drivers without access to
hardware documentation.&lt;/p&gt;
&lt;p&gt;&lt;div class="youtube-video"&gt;&lt;iframe src="https://www.youtube.com/embed/CMm-yhsMB7U"&gt;&lt;/iframe&gt;&lt;/div&gt;&lt;/p&gt;
&lt;h3 id="async-page-flip-in-atomic-api-andré-almeida"&gt;&lt;a
href="https://indico.freedesktop.org/event/2/contributions/61/"&gt;“Async
page flip in atomic API”&lt;/a&gt; (André Almeida)&lt;/h3&gt;
&lt;p&gt;André talks about the work that has been done to enable asynchronous
page flipping in DRM’s atomic API with an introduction to the topic by
explaining about what exactly is asynchronous page flip, and why you
would want it.&lt;/p&gt;
&lt;p&gt;&lt;div class="youtube-video"&gt;&lt;iframe src="https://www.youtube.com/embed/qayPPIfrqtE"&gt;&lt;/iframe&gt;&lt;/div&gt;&lt;/p&gt;
&lt;h2 id="fosdem-2022"&gt;FOSDEM 2022&lt;/h2&gt;
&lt;p&gt;Another important conference for us is FOSDEM, and last year we
presented 3 of the 5 talks in the graphics dev room. FOSDEM took place
in early February 2022, these talks provide some good context of where
the team started in 2022.&lt;/p&gt;
&lt;h3 id="the-status-of-turnip-driver-development-hyunjun-ko"&gt;&lt;a
href="https://archive.fosdem.org/2022/schedule/event/turnip/"&gt;The status
of Turnip driver development&lt;/a&gt; (Hyunjun Ko)&lt;/h3&gt;
&lt;p&gt;Hyunjun presented the current state of the Turnip driver, also
talking about the difficulties of developing a driver for a platform
without hardware documentation. He talks about how Turnip developers
reverse engineer the behaviour of the hardware, and then implement that
in an open-source driver. He also made a companion &lt;a
href="https://blogs.igalia.com/zzoon/graphics/mesa/2022/02/21/complement-story/"&gt;blog
post&lt;/a&gt; to checkout along with his presentation.&lt;/p&gt;
&lt;h3
id="v3dv-status-update-for-open-source-vulkan-driver-for-raspberry-pi-4-alejandro-piñeiro"&gt;&lt;a
href="https://archive.fosdem.org/2022/schedule/event/v3dv/"&gt;v3dv: Status
Update for Open Source Vulkan Driver for Raspberry Pi 4&lt;/a&gt; (Alejandro
Piñeiro)&lt;/h3&gt;
&lt;p&gt;Igalia has been presenting the status of the v3dv driver since
December 2019 and in this presentation, Alejandro talks about the status
of the v3dv driver in early 2022. He talks about achieving conformance,
the extensions that had to be implemented, and the future plans of the
v3dv driver.&lt;/p&gt;
&lt;h3 id="fun-with-border-colors-in-vulkan-ricardo-garcia"&gt;&lt;a
href="https://archive.fosdem.org/2022/schedule/event/vulkan_borders/"&gt;Fun
with border colors in Vulkan&lt;/a&gt; (Ricardo Garcia)&lt;/h3&gt;
&lt;p&gt;Ricardo presents about the work he did on the
&lt;code&gt;VK_EXT_border_color_swizzle&lt;/code&gt; extension in Vulkan. He talks
about the specific contributions he did and how the extension fits in
with sampling color operations in Vulkan.&lt;/p&gt;
&lt;h2 id="gsoc-igalia-ce"&gt;GSoC &amp;amp; Igalia CE&lt;/h2&gt;
&lt;p&gt;Last year Melissa &amp;amp; André co-mentored contributors working on
introducing KUnit tests to the AMD display driver. This project was
hosted as a &lt;a href="https://summerofcode.withgoogle.com/"&gt;“Google
Summer of Code” (GSoC)&lt;/a&gt; project from the X.Org Foundation. If you’re
interested in seeing their work Tales da Aparecida, Maíra Canal, Magali
Lemes, and Isabella Basso presented their work at the &lt;a
href="https://lpc.events/event/16/contributions/1310/"&gt;Linux Plumbers
Conference 2022&lt;/a&gt; and across two talks at XDC 2022. Here you can see
their &lt;a
href="https://indico.freedesktop.org/event/2/contributions/65/"&gt;first&lt;/a&gt;
presentation and here you can see their &lt;a
href="https://indico.freedesktop.org/event/2/contributions/164/"&gt;second&lt;/a&gt;
second presentation.&lt;/p&gt;
&lt;p&gt;André &amp;amp; Melissa also mentored two &lt;a
href="https://www.igalia.com/coding-experience/"&gt;“Igalia Coding
Experience” (CE)&lt;/a&gt; projects, one related to IGT GPU test tools on the
VKMS kernel driver, and the other for IGT GPU test tools on the V3D
kernel driver. If you’re interested in reading up on some of that work,
Maíra Canal &lt;a
href="https://mairacanal.github.io/january-update-finishing-my-igalia-ce/"&gt;wrote
about her experience&lt;/a&gt; being part of the Igalia CE.&lt;/p&gt;
&lt;p&gt;Ella Stanforth was also part of the Igalia Coding Experience, being
mentored by Iago &amp;amp; Alejandro. They worked on the
&lt;code&gt;VK_KHR_sampler_ycbcr_conversion&lt;/code&gt; extension for the v3dv
driver. Alejandro talks about their work in his &lt;a
href="https://blogs.igalia.com/apinheiro/2023/01/v3dv-status-update-2023-01/"&gt;blog
post here&lt;/a&gt;.&lt;/p&gt;
&lt;h1 id="whats-next"&gt;What’s Next?&lt;/h1&gt;
&lt;p&gt;The graphics team is looking forward to having a jam-packed 2023 with
just as many if not more contributions to the Open-Source graphics
stack! I’m super excited to be part of the team, and hope to see my name
in our 2023 recap post!&lt;/p&gt;
&lt;p&gt;Also, you might have heard that &lt;a
href="https://www.igalia.com/2022/xdc-2023"&gt;Igalia will be hosting XDC
2023&lt;/a&gt; in the beautiful city of A Coruña! We hope to see you there
where there will be many presentations from all the great people working
on the Open-Source graphics stack, and most importantly where you can &lt;a
href="https://www.youtube.com/watch?v=7hWcu8O9BjM"&gt;dream in the
Atlantic!&lt;/a&gt;&lt;/p&gt;
&lt;figure&gt;
&lt;img src="https://www.igalia.com/assets/i/news/XDC-event-banner.jpg"
alt="Photo of A Coruña" /&gt;
&lt;figcaption aria-hidden="true"&gt;Photo of A Coruña&lt;/figcaption&gt;
&lt;/figure&gt;
</description><pubDate>Thu, 02 Feb 2023 05:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/2022_igalia_graphics_team.html</guid></item><item><title>Global Game Jam 2023 - GI Jam</title><link>https://fryzekconcepts.com/notes/global_game_jam_2023.html</link><description>&lt;p&gt;At the beginning of this month I participated in the Games
Institutes’s Global Game Jam event. &lt;a
href="https://uwaterloo.ca/games-institute/"&gt;The Games Institute&lt;/a&gt; is
an organization at my local university (The University of Waterloo) that
focuses on games-based research. They host a game jam every school term
and this term’s jam happened to coincide with the Global Game Jam. Since
this event was open to everyone (and it’s been a few years since I’ve
been a student at UW 👴️), I joined up to try and stretch some of my more
creative muscles. The event was a 48-hour game jam that began on Friday,
February 3rd and ended on Sunday,February 5th.&lt;/p&gt;
&lt;p&gt;The game we created is called &lt;a
href="https://globalgamejam.org/2023/games/turtle-roots-5"&gt;Turtle
Roots&lt;/a&gt;, and it is a simple resource management game. You play as a
magical turtle floating through the sky and collecting water in order to
survive. The turtle can spend some of its “nutrients” to grow roots
which will allow it to gather water and collect more nutrients. The
challenge in the game is trying to survive for as long as possible
without running out of water.&lt;/p&gt;
&lt;div class="gallery"&gt;
&lt;p&gt;&lt;img src="/assets/global_game_jam_2023/screen_shot_1.png" /&gt; &lt;img
src="/assets/global_game_jam_2023/screen_shot_2.png" /&gt; &lt;img
src="/assets/global_game_jam_2023/screen_shot_3.png" /&gt;&lt;/p&gt;
&lt;p&gt;Screenshots of Turtle Roots&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;The game we created is called &lt;a
href="https://globalgamejam.org/2023/games/turtle-roots-5"&gt;Turtle
Roots&lt;/a&gt;, and it is a simple resource management game. You play as a
magical turtle floating through the sky and collecting water in order to
survive. The turtle can spend some of its “nutrients” to grow roots
which will allow it to gather water and collect more nutrients. The
challenge in the game is trying to survive for as long as possible
without running out of water.&lt;/p&gt;
&lt;h2 id="the-team"&gt;The Team&lt;/h2&gt;
&lt;p&gt;I attended the event solo and quickly partnered up with two other
people, who also attended solo. One member had already participated in a
game jam before and specialized in art. The other member was attending a
game jam for the first time and was looking for the best way they could
contribute. Having particular skills for sound, they ended up creating
all the audio in our game. This left me as the sole programmer for our
team.&lt;/p&gt;
&lt;h2 id="my-game-jam-experiences"&gt;My Game Jam Experiences&lt;/h2&gt;
&lt;p&gt;In recent years,I participated in a &lt;a
href="/notes/n64brew-gamejam-2021.html"&gt;Nintendo 64 homebrew game
jam&lt;/a&gt; and the Puerto Rico Game Developers Association event for the
global game jam, submitting &lt;a
href="https://globalgamejam.org/2022/games/magnetic-parkour-6"&gt;Magnetic
Parkour&lt;/a&gt;, I also participated in &lt;a href="https://ldjam.com/"&gt;Ludum
Dare&lt;/a&gt; back around 2013 but unfortunately I’ve since lost the link to
my submission. While in high school, my friend and I participated in the
“Ottawa Tech Jame” (similar to a game jam), sort of worked like a game
jam called “Ottawa Tech Jam” submitting &lt;a
href="http://www.fastquake.com/projects/zorvwarz/"&gt;Zorv Warz&lt;/a&gt; and &lt;a
href="http://www.fastquake.com/projects/worldseed/"&gt;E410&lt;/a&gt;. As you can
probably tell, I really like gamedev. The desire to build my own video
games is actually what originally got me into programming. When I was
around 14 years old, I picked up a C++ programming book from the library
since I wanted to try to build my own game and I heard most game
developers use C++. I used some proprietary game development library
(that I can’t recall the name of)to build 2D and 3D games in Windows
using C++. I didn’t really get too far into it until high school when I
started to learn SFML, SDL, and OpenGL. I also dabbled with Unity during
that time as well. However,I’ve always had a strong desire to build most
of the foundation of the game myself without using an engine. You can
see this desire really come out in the work I did for Zorv Warz, E410,
and the N64 homebrew game jam. When working with a team, I feel it can
be a lot easier to use a game engine, even if it doesn’t scratch the
same itch for me.&lt;/p&gt;
&lt;h2 id="the-tech-behind-the-game"&gt;The Tech Behind the Game&lt;/h2&gt;
&lt;p&gt;Lately I’ve had a growing interest in the game engine called &lt;a
href="https://godotengine.org/"&gt;Godot&lt;/a&gt;, and wanted to use this
opportunity to learn the engine more and build a game in it. Godot is
interesting to me as its a completely open source game engine, and as
you can probably guess from my &lt;a
href="/notes/2022_igalia_graphics_team.html"&gt;job&lt;/a&gt;, open source
software as well as free software is something I’m particularly
interested in.&lt;/p&gt;
&lt;p&gt;Godot is a really powerful game engine that handles a lot of
complexity for you. For example,it has a built in parallax background
component, that we took advantage of to add more depth to our game. This
allows you to control the background scrolling speed for different layer
of the background, giving the illusion of depth in a 2D game.&lt;/p&gt;
&lt;p&gt;Another powerful feature of Godot is its physics engine. Godot makes
it really easy to create physics objects in your scene and have them do
interesting stuff. You might be wondering where physics comes into play
in our game, and we actually use it for the root animations. I set up a
sort of “rag doll” system for the roots to make them flop around in the
air as the player moves, really giving a lot more “life” to an otherwise
static game.&lt;/p&gt;
&lt;p&gt;Godot has a built in scripting language called “GDScript” which is
very similar to Python. I’ve really grown to like this language. It has
an optional type system you can take advantage of that helps with
reducing the number of bugs that exist in your game. It also has great
connectivity with the editor. This proved useful as I could “export”
variables in the game and allow my team members to modify certain
parameters of the game without knowing any programming. This is super
helpful with balancing, and more easily allows non-technical members of
team to contribute to the game logic in a more concrete way.&lt;/p&gt;
&lt;p&gt;Overall I’m very happy with how our game turned out. Last year I
tried to participate in a few more game jams, but due to a combination
of lack of personal motivation, poor team dynamics, and other factors,
none of those game jams panned out. This was the first game jam in a
while where I feel like I really connected with my team and I also feel
like we made a super polished and fun game in the end.&lt;/p&gt;
</description><pubDate>Sat, 11 Feb 2023 05:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/global_game_jam_2023.html</guid></item><item><title>Journey Through Freedreno</title><link>https://fryzekconcepts.com/notes/freedreno_journey.html</link><description>&lt;figure&gt;
&lt;img src="/assets/freedreno/glinfo_freedreno.png"
alt="Android running Freedreno" /&gt;
&lt;figcaption aria-hidden="true"&gt;Android running Freedreno&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;As part of my training at Igalia I’ve been attempting to write a new
backend for Freedreno that targets the proprietary “KGSL” kernel mode
driver. For those unaware there are two “main” kernel mode drivers on
Qualcomm SOCs for the GPU, there is the “MSM”, and “KGSL”. “MSM” is DRM
compliant, and Freedreno already able to run on this driver. “KGSL” is
the proprietary KMD that Qualcomm’s proprietary userspace driver
targets. Now why would you want to run freedreno against KGSL, when MSM
exists? Well there are a few ones, first MSM only really works on an
up-streamed kernel, so if you have to run a down-streamed kernel you can
continue using the version of KGSL that the manufacturer shipped with
your device. Second this allows you to run both the proprietary adreno
driver and the open source freedreno driver on the same device just by
swapping libraries, which can be very nice for quickly testing something
against both drivers.&lt;/p&gt;
&lt;h2 id="when-drm-isnt-just-drm"&gt;When “DRM” isn’t just “DRM”&lt;/h2&gt;
&lt;p&gt;When working on a new backend, one of the critical things to do is to
make use of as much “common code” as possible. This has a number of
benefits, least of all reducing the amount of code you have to write. It
also allows reduces the number of bugs that will likely exist as you are
relying on well tested code, and it ensures that the backend is mostly
likely going to continue to work with new driver updates.&lt;/p&gt;
&lt;p&gt;When I started the work for a new backend I looked inside mesa’s
&lt;code&gt;src/freedreno/drm&lt;/code&gt; folder. This has the current backend code
for Freedreno, and its already modularized to support multiple backends.
It currently has support for the above mentioned MSM kernel mode driver
as well as virtio (a backend that allows Freedreno to be used from
within in a virtualized environment). From the name of this path, you
would think that the code in this module would only work with kernel
mode drivers that implement DRM, but actually there is only a handful of
places in this module where DRM support is assumed. This made it a good
starting point to introduce the KGSL backend and piggy back off the
common code.&lt;/p&gt;
&lt;p&gt;For example the &lt;code&gt;drm&lt;/code&gt; module has a lot of code to deal
with the management of synchronization primitives, buffer objects, and
command submit lists. All managed at a abstraction above “DRM” and to
re-implement this code would be a bad idea.&lt;/p&gt;
&lt;h2 id="how-to-get-android-to-behave"&gt;How to get Android to behave&lt;/h2&gt;
&lt;p&gt;One of this big struggles with getting the KGSL backend working was
figuring out how I could get Android to load mesa instead of Qualcomm
blob driver that is shipped with the device image. Thankfully a good
chunk of this work has already been figured out when the Turnip
developers (Turnip is the open source Vulkan implementation for Adreno
GPUs) figured out how to get Turnip running on android with KGSL.
Thankfully one of my coworkers &lt;a
href="https://blogs.igalia.com/dpiliaiev/"&gt;Danylo&lt;/a&gt; is one of those
Turnip developers, and he gave me a lot of guidance on getting Android
setup. One thing to watch out for is the outdated instructions &lt;a
href="https://docs.mesa3d.org/android.html"&gt;here&lt;/a&gt;. These instructions
&lt;em&gt;almost&lt;/em&gt; work, but require some modifications. First if you’re
using a more modern version of the Android NDK, the compiler has been
replaced with LLVM/Clang, so you need to change which compiler is being
used. Second flags like &lt;code&gt;system&lt;/code&gt; in the cross compiler script
incorrectly set the system as &lt;code&gt;linux&lt;/code&gt; instead of
&lt;code&gt;android&lt;/code&gt;. I had success using the below cross compiler
script. Take note that the compiler paths need to be updated to match
where you extracted the android NDK on your system.&lt;/p&gt;
&lt;pre class="meson"&gt;&lt;code&gt;[binaries]
ar = &amp;#39;/home/lfryzek/Documents/projects/igalia/freedreno/android-ndk-r25b-linux/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-ar&amp;#39;
c = [&amp;#39;ccache&amp;#39;, &amp;#39;/home/lfryzek/Documents/projects/igalia/freedreno/android-ndk-r25b-linux/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-clang&amp;#39;]
cpp = [&amp;#39;ccache&amp;#39;, &amp;#39;/home/lfryzek/Documents/projects/igalia/freedreno/android-ndk-r25b-linux/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android29-clang++&amp;#39;, &amp;#39;-fno-exceptions&amp;#39;, &amp;#39;-fno-unwind-tables&amp;#39;, &amp;#39;-fno-asynchronous-unwind-tables&amp;#39;, &amp;#39;-static-libstdc++&amp;#39;]
c_ld = &amp;#39;lld&amp;#39;
cpp_ld = &amp;#39;lld&amp;#39;
strip = &amp;#39;/home/lfryzek/Documents/projects/igalia/freedreno/android-ndk-r25b-linux/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-strip&amp;#39;
# Android doesn&amp;#39;t come with a pkg-config, but we need one for Meson to be happy not
# finding all the optional deps it looks for.  Use system pkg-config pointing at a
# directory we get to populate with any .pc files we want to add for Android
pkgconfig = [&amp;#39;env&amp;#39;, &amp;#39;PKG_CONFIG_LIBDIR=/home/lfryzek/Documents/projects/igalia/freedreno/android-ndk-r25b-linux/android-ndk-r25b/pkgconfig:/home/lfryzek/Documents/projects/igalia/freedreno/install-android/lib/pkgconfig&amp;#39;, &amp;#39;/usr/bin/pkg-config&amp;#39;]

[host_machine]
system = &amp;#39;android&amp;#39;
cpu_family = &amp;#39;arm&amp;#39;
cpu = &amp;#39;armv8&amp;#39;
endian = &amp;#39;little&amp;#39;&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Another thing I had to figure out with Android, that was different
with these instructions, was how I would get Android to load mesa
versions of mesa libraries. That’s when my colleague &lt;a
href="https://www.igalia.com/team/mark"&gt;Mark&lt;/a&gt; pointed out to me that
Android is open source and I could just check the source code myself.
Sure enough you have find the OpenGL driver loader in &lt;a
href="https://android.googlesource.com/platform/frameworks/native/+/master/opengl/libs/EGL/Loader.cpp"&gt;Android’s
source code&lt;/a&gt;. From this code we can that Android will try to load a
few different files based on some settings, and in my case it would try
to load 3 different shaded libraries in the
&lt;code&gt;/vendor/lib64/egl&lt;/code&gt; folder, &lt;code&gt;libEGL_adreno.so&lt;/code&gt;
,&lt;code&gt;libGLESv1_CM_adreno.so&lt;/code&gt;, and &lt;code&gt;libGLESv2.so&lt;/code&gt;. I
could just replace these libraries with the version built from mesa and
voilà, you’re now loading a custom driver! This realization that I could
just “read the code” was very powerful in debugging some more android
specific issues I ran into, like dealing with gralloc.&lt;/p&gt;
&lt;p&gt;Something cool that the opensource Freedreno &amp;amp; Turnip driver
developers figured out was getting android to run test OpenGL
applications from the adb shell without building android APKs. If you
check out the &lt;a
href="https://gitlab.freedesktop.org/freedreno/freedreno"&gt;freedreno
repo&lt;/a&gt;, they have an &lt;code&gt;ndk-build.sh&lt;/code&gt; script that can build
tests in the &lt;code&gt;tests-*&lt;/code&gt; folder. The nice benefit of this is
that it provides an easy way to run simple test cases without worrying
about the android window system integration. Another nifty feature about
this repo is the &lt;code&gt;libwrap&lt;/code&gt; tool that lets trace the commands
being submitted to the GPU.&lt;/p&gt;
&lt;h2 id="what-even-is-gralloc"&gt;What even is Gralloc?&lt;/h2&gt;
&lt;p&gt;Gralloc is the graphics memory allocated in Android, and the OS will
use it to allocate the surface for “windows”. This means that the memory
we want to render the display to is managed by gralloc and not our KGSL
backend. This means we have to get all the information about this
surface from gralloc, and if you look in
&lt;code&gt;src/egl/driver/dri2/platform_android.c&lt;/code&gt; you will see
existing code for handing gralloc. You would think “Hey there is no work
for me here then”, but you would be wrong. The handle gralloc provides
is hardware specific, and the code in &lt;code&gt;platform_android.c&lt;/code&gt;
assumes a DRM gralloc implementation. Thankfully the turnip developers
had already gone through this struggle and if you look in
&lt;code&gt;src/freedreno/vulkan/tu_android.c&lt;/code&gt; you can see they have
implemented a separate path when a Qualcomm msm implementation of
gralloc is detected. I could copy this detection logic and add a
separate path to &lt;code&gt;platform_android.c&lt;/code&gt;.&lt;/p&gt;
&lt;h2 id="working-with-the-freedreno-community"&gt;Working with the Freedreno
community&lt;/h2&gt;
&lt;p&gt;When working on any project (open-source or otherwise), it’s nice to
know that you aren’t working alone. Thankfully the
&lt;code&gt;#freedreno&lt;/code&gt; channel on &lt;code&gt;irc.oftc.net&lt;/code&gt; is very
active and full of helpful people to answer any questions you may have.
While working on the backend, one area I wasn’t really sure how to
address was the synchronization code for buffer objects. The backend
exposed a function called &lt;code&gt;cpu_prep&lt;/code&gt;, This function was just
there to call the DRM implementation of &lt;code&gt;cpu_prep&lt;/code&gt; on the
buffer object. I wasn’t exactly sure how to implement this functionality
with KGSL since it doesn’t use DRM buffer objects.&lt;/p&gt;
&lt;p&gt;I ended up reaching out to the IRC channel and Rob Clark on the
channel explained to me that he was actually working on moving a lot of
the code for &lt;code&gt;cpu_prep&lt;/code&gt; into common code so that a non-drm
driver (like the KGSL backend I was working on) would just need to
implement that operation as NOP (no operation).&lt;/p&gt;
&lt;h2 id="dealing-with-bugs-reverse-engineering-the-blob"&gt;Dealing with
bugs &amp;amp; reverse engineering the blob&lt;/h2&gt;
&lt;p&gt;I encountered a few different bugs when implementing the KGSL
backend, but most of them consisted of me calling KGSL wrong, or handing
synchronization incorrectly. Thankfully since Turnip is already running
on KGSL, I could just more carefully compare my code to what Turnip is
doing and figure out my logical mistake.&lt;/p&gt;
&lt;p&gt;Some of the bugs I encountered required the backend interface in
Freedreno to be modified to expose per a new per driver implementation
of that backend function, instead of just using a common implementation.
For example the existing function to map a buffer object into userspace
assumed that the same &lt;code&gt;fd&lt;/code&gt; for the device could be used for
the buffer object in the &lt;code&gt;mmap&lt;/code&gt; call. This worked fine for
any buffer objects we created through KGSL but would not work for buffer
objects created from gralloc (remember the above section on surface
memory for windows comming from gralloc). To resolve this issue I
exposed a new per backend implementation of “map” where I could take a
different path if the buffer object came from gralloc.&lt;/p&gt;
&lt;p&gt;While testing the KGSL backend I did encounter a new bug that seems
to effect both my new KGSL backend and the Turnip KGSL backend. The bug
is an &lt;code&gt;iommu fault&lt;/code&gt; that occurs when the surface allocated by
gralloc does not have a height that is aligned to 4. The blitting engine
on a6xx GPUs copies in 16x4 chunks, so if the height is not aligned by 4
the GPU will try to write to pixels that exists outside the allocated
memory. This issue only happens with KGSL backends since we import
memory from gralloc, and gralloc allocates exactly enough memory for the
surface, with no alignment on the height. If running on any other
platform, the &lt;code&gt;fdl&lt;/code&gt; (Freedreno Layout) code would be called
to compute the minimum required size for a surface which would take into
account the alignment requirement for the height. The blob driver
Qualcomm didn’t seem to have this problem, even though its getting the
exact same buffer from gralloc. So it must be doing something different
to handle the none aligned height.&lt;/p&gt;
&lt;p&gt;Because this issue relied on gralloc, the application needed to
running as an Android APK to get a surface from gralloc. The best way to
fix this issue would be to figure out what the blob driver is doing and
try to replicate this behavior in Freedreno (assuming it isn’t doing
something silly like switch to sysmem rendering). Unfortunately it
didn’t look like the libwrap library worked to trace an APK.&lt;/p&gt;
&lt;p&gt;The libwrap library relied on a linux feature known as
&lt;code&gt;LD_PRELOAD&lt;/code&gt; to load &lt;code&gt;libwrap.so&lt;/code&gt; when the
application starts and replace the system functions like
&lt;code&gt;open&lt;/code&gt; and &lt;code&gt;ioctl&lt;/code&gt; with their own implementation
that traces what is being submitted to the KGSL kernel mode driver.
Thankfully android exposes this &lt;code&gt;LD_PRELOAD&lt;/code&gt; mechanism
through its “wrap” interface where you create a propety called
&lt;code&gt;wrap.&amp;lt;app-name&amp;gt;&lt;/code&gt; with a value
&lt;code&gt;LD_PRELOAD=&amp;lt;path to libwrap.so&amp;gt;&lt;/code&gt;. Android will then
load your library like would be done in a normal linux shell. If you
tried to do this with libwrap though you find very quickly that you
would get corrupted traces. When android launches your APK, it doesn’t
only launch your application, there are different threads for different
android system related functions and some of them can also use OpenGL.
The libwrap library is not designed to handle multiple threads using
KGSL at the same time. After discovering this issue I created a &lt;a
href="https://gitlab.freedesktop.org/freedreno/freedreno/-/merge_requests/22"&gt;MR&lt;/a&gt;
that would store the tracing file handles as TLS (thread local storage)
preventing the clobbering of the trace file, and also allowing you to
view the traces generated by different threads separately from each
other.&lt;/p&gt;
&lt;p&gt;With this is in hand one could begin investing what the blob driver
is doing to handle this unaligned surfaces.&lt;/p&gt;
&lt;h2 id="whats-next"&gt;What’s next?&lt;/h2&gt;
&lt;p&gt;Well the next obvious thing to fix is the aligned height issue which
is still open. I’ve also worked on upstreaming my changes with this &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21570"&gt;WIP
MR&lt;/a&gt;.&lt;/p&gt;
&lt;figure&gt;
&lt;img src="/assets/freedreno/3d-mark.png"
alt="Freedreno running 3d-mark" /&gt;
&lt;figcaption aria-hidden="true"&gt;Freedreno running 3d-mark&lt;/figcaption&gt;
&lt;/figure&gt;
</description><pubDate>Tue, 28 Feb 2023 05:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/freedreno_journey.html</guid></item><item><title>Igalia’s Mesa 23.1 Contributions - Behind the Scenes</title><link>https://fryzekconcepts.com/notes/mesa_23_1_contributions_behind_the_scenes.html</link><description>&lt;p&gt;It’s an exciting time for Mesa as its next major release is unveiled
this week. Igalia has played an important role in this milestone, with
Eric Engestrom managing the release and 11 other Igalians contributing
over 110 merge requests. A sample of these contributions are detailed
below.&lt;/p&gt;
&lt;h2 id="radv-implement-vk.check_status"&gt;radv: Implement
vk.check_status&lt;/h2&gt;
&lt;p&gt;As part of an effort to enhance the reliability of GPU resets on
amdgpu, Tony implemented a GPU reset notification feature in the RADV
Vulkan driver. This new function improves the robustness of the RADV
driver. The driver can now check if the GPU has been reset by a
userspace application, allowing the driver to recover their contexts,
exit, or engage in some other appropriate action.&lt;/p&gt;
&lt;p&gt;You can read more about Tony’s changes in the link below&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22253"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22253&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="turnip-kgsl-backend-rewrite"&gt;turnip: KGSL backend rewrite&lt;/h2&gt;
&lt;p&gt;With a goal of improving feature parity of the KGSL kernel mode
driver with its drm counterpart, Mark has been rewriting the backend for
KGSL. These changes leverage the new, common backend Vulkan
infrastructure inside Mesa and fix multiple bugs. In addition, they
introduce support for importing/exporting sync FDs, pre-signalled
fences, and timeline semaphore support.&lt;/p&gt;
&lt;p&gt;If you’re interested in taking a deeper dive into Mark’s changes, you
can read the following MR:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21651"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21651&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="turnip-a7xx-preparation-transition-to-c"&gt;turnip: a7xx
preparation, transition to C++&lt;/h2&gt;
&lt;p&gt;Danylo has adopted a significant role for two major changes inside
turnip: 1)contributing to the effort to migrate turnip to C++ and
2)supporting the next generation a7xx Adreno GPUs from Qualcomm. A more
detailed overview of Danylo’s changes can be found in the linked MRs
below:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21931"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21931&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22148"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22148&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="v3dv3dv-various-fixes-cts-conformance"&gt;v3d/v3dv various fixes
&amp;amp; CTS conformance&lt;/h2&gt;
&lt;p&gt;Igalia maintains the v3d OpenGL driver and v3dv Vulkan drive for
broadcom videocore GPUs which can be found on devices such as the
Raspberry Pi. Iago, Alex and Juan have combined their expertise to
implement multiple fixes for both the v3d gallium driver and the v3dv
vulkan driver on the Raspberry Pi. These changes include CPU performance
optimizations, support for 16-bit floating point vertex attributes, and
raising support in the driver to OpenGL 3.1 level functionality. This
Igalian trio has also been addressing fixes for conformance issues
raised in the Vulkan 1.3.5 conformance test suite (CTS).&lt;/p&gt;
&lt;p&gt;You can dive into some of their Raspberry Pi driver changes here:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22131"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22131&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21361"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21361&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20787"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20787&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="ci-build-system-and-cleanup"&gt;ci, build system, and cleanup&lt;/h2&gt;
&lt;p&gt;In addition to managing the 23.1 release, Eric has also implemented
many fixes in Mesa’s infrastructure. He has assisted with addressing a
number of CI issues within Mesa on various drivers from v3d to panfrost.
Eric also dedicated part of his time to general clean-up of the Mesa
code (e.g. removing duplicate functions, fixing and improving the
meson-based build system, and removing dead code).&lt;/p&gt;
&lt;p&gt;If you’re interested in seeing some of his work, check out some of
the MRs below:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22410"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22410&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21504"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21504&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21558"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21558&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20180"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20180&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</description><pubDate>Thu, 11 May 2023 04:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/mesa_23_1_contributions_behind_the_scenes.html</guid></item><item><title>Converting from 3D to 2D</title><link>https://fryzekconcepts.com/notes/converting_from_3d_to_2d.html</link><description>&lt;p&gt;Recently I’ve been working on a project where I needed to convert an
application written in OpenGL to a software renderer. The matrix
transformation code in OpenGL made use of the GLM library for matrix
math, and I needed to convert the 4x4 matrices to be 3x3 matrices to
work with the software renderer. There was some existing code to do this
that was broken, and looked something like this:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;glm::mat3 mat3x3 = glm::mat3(mat4x4);&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Don’t worry if you don’t see the problem already, I’m going to
illustrate in more detail with the example of a translation matrix. In
3D a standard translation matrix to translate by a vector
&lt;code&gt;(x, y, z)&lt;/code&gt; looks something like this:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;[1 0 0 x]
[0 1 0 y]
[0 0 1 z]
[0 0 0 1]&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Then when we multiply this matrix by a vector like
&lt;code&gt;(a, b, c, 1)&lt;/code&gt; the result is
&lt;code&gt;(a + x, b + y, c + z, 1)&lt;/code&gt;. If you don’t understand why the
matrix is 4x4 or why we have that extra 1 at the end don’t worry, I’ll
explain that in more detail later.&lt;/p&gt;
&lt;p&gt;Now using the existing conversion code to get a 3x3 matrix will
simply take the first 3 columns and first 3 rows of the matrix and
produce a 3x3 matrix from those. Converting the translation matrix above
using this code produces the following matrix:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;[1 0 0]
[0 1 0]
[0 0 1]&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;See the problem now? The &lt;code&gt;(x, y, z)&lt;/code&gt; values disappeared!
In the conversion process we lost these critical values from the
translation matrix, and now if we multiply by this matrix nothing will
happen since we are just left with the identity matrix. So if we can’t
use this simple “cast” function in GLM, what can we use?&lt;/p&gt;
&lt;p&gt;Well one thing we can do is preserve the last column and last row of
the matrix. So assume we have a 4x4 matrix like this:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;[a b c d]
[e f g h]
[i j k l]
[m n o p]&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Then preserving the last row and column we should get a matrix like
this:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;[a b d]
[e f h]
[m n p]&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;And if we use this conversion process for the same translation matrix
we will get:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;[1 0 x]
[0 1 y]
[0 0 1]&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Now we see that the &lt;code&gt;(x, y)&lt;/code&gt; part of the translation is
preserved, and if we try to multiply this matrix by the vector
&lt;code&gt;(a, b, 1)&lt;/code&gt; the result will be
&lt;code&gt;(a + x, b + y, 1)&lt;/code&gt;. The translation is preserved in the
conversion!&lt;/p&gt;
&lt;h2 id="why-do-we-have-to-use-this-conversion"&gt;Why do we have to use
this conversion?&lt;/h2&gt;
&lt;p&gt;The reason the conversion is more complicated is hidden in how we
defined the translation matrix and vector we wanted to translate. The
vector was actually a 4D vector with the final component set to 1. The
reason we do this is that we actually want to represent an affine space
instead of just a vector space. An affine space being a type of space
where you can have both points and vectors. A point is exactly what you
would expect it to be just a point in space from some origin, and vector
is a direction with magnitude but no origin. This is important because
strictly speaking translation isn’t actually defined for vectors in a
normal vector space. Additionally if you try to construct a matrix to
represent translation for a vector space you’ll find that its impossible
to derive a matrix to do this and that operation is not a linear
function. On the other hand operations like translation are well defined
in an affine space and do what you would expect.&lt;/p&gt;
&lt;p&gt;To get around the problem of vector spaces, mathematicians more
clever than I figured out you can implement an affine space in a normal
vector space by increasing the dimension of the vector space by one, and
by adding an extra row and column to the transformation matrices used.
They called this a &lt;strong&gt;homogeneous coordinate system&lt;/strong&gt;. This
lets you say that a vector is actually just a point if the 4th component
is 1, but if its 0 its just a vector. Using this abstraction one can
implement all the well defined operations for an affine space (like
translation!).&lt;/p&gt;
&lt;p&gt;So using the “homogeneous coordinate system” abstraction, translation
is an operation that defined by taking a point and moving it by a
vector. Lets look at how that works with the translation matrix I used
as an example above. If you multiply that matrix by a 4D vector where
the 4th component is 0, it will just return the same vector. Now if we
multiply by a 4D vector where the 4th component is 1, it will return the
point translated by the vector we used to construct that translation
matrix. This implements the translation operation as its defined in an
affine space!&lt;/p&gt;
&lt;p&gt;If you’re interested in understanding more about homogeneous
coordinate spaces, (like how the translation matrix is derived in the
first place) I would encourage you to look at resources like &lt;a
href="https://books.google.ca/books/about/Mathematics_for_Computer_Graphics_Applic.html?id=YmQy799flPkC&amp;amp;redir_esc=y"&gt;“Mathematics
for Computer Graphics Applications”&lt;/a&gt;. They provide a much more
detailed explanation than I am providing here. (The homogeneous
coordinate system also has some benefits for representing projections
which I won’t get into here, but are explained in that text book.)&lt;/p&gt;
&lt;p&gt;Now to finally answer the question about why we needed to preserve
those final columns and vectors. Based on what we now know, we weren’t
actually just converting from a “3D space” to a “2D space” we were
converting from a “3D homogeneous space” to a “2D homogeneous space”.
The process of converting from a higher dimension matrix to a lower
dimensional matrix is lossy and some transformation details are going to
be lost in process (like for example the translation along the z-axis).
There is no way to tell what kind of space a given matrix is supposed to
transform just by looking at the matrix itself. The matrix does not
carry any information about about what space its operating in and any
conversion function would need to know that information to properly
convert that matrix. Therefore we need develop our own conversion
function that preserves the transformations that are important to our
application when moving from a “3D homogeneous space” to a “2D
homogeneous space”.&lt;/p&gt;
&lt;p&gt;Hopefully this explanation helps if you are every working on
converting 3D transformation code to 2D.&lt;/p&gt;
</description><pubDate>Mon, 25 Sep 2023 04:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/converting_from_3d_to_2d.html</guid></item><item><title>A Dive into Vulkanised 2024</title><link>https://fryzekconcepts.com/notes/vulkanised_2024.html</link><description>&lt;figure&gt;
&lt;img src="/assets/vulkanised_2024/vulkanized_logo_web.jpg"
alt="Vulkanised sign at google’s office" /&gt;
&lt;figcaption aria-hidden="true"&gt;Vulkanised sign at google’s
office&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;Last week I had an exciting opportunity to attend the Vulkanised 2024
conference. For those of you not familar with the event, it is &lt;a
href="https://vulkan.org/events/vulkanised-2024"&gt;“The Premier Vulkan
Developer Conference”&lt;/a&gt; hosted by the Vulkan working group from
Khronos. With the excitement out of the way, I decided to write about
some of the interesting information that came out of the conference.&lt;/p&gt;
&lt;h2 id="a-few-presentations"&gt;A Few Presentations&lt;/h2&gt;
&lt;p&gt;My colleagues Iago, Stéphane, and Hyunjun each had the opportunity to
present on some of their work into the wider Vulkan ecosystem.&lt;/p&gt;
&lt;figure&gt;
&lt;img src="/assets/vulkanised_2024/vulkan_video_web.jpg"
alt="Stéphane and Hyujun presenting" /&gt;
&lt;figcaption aria-hidden="true"&gt;Stéphane and Hyujun
presenting&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;Stéphane &amp;amp; Hyunjun presented “Implementing a Vulkan Video Encoder
From Mesa to Streamer”. They jointly talked about the work they
performed to implement the Vulkan video extensions in Intel’s ANV Mesa
driver as well as in GStreamer. This was an interesting presentation
because you got to see how the new Vulkan video extensions affected both
driver developers implementing the extensions and application developers
making use of the extensions for real time video decoding and encoding.
&lt;a
href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-stephane-cerveau-ko-igalia.pdf"&gt;Their
presentation is available on vulkan.org&lt;/a&gt;.&lt;/p&gt;
&lt;figure&gt;
&lt;img src="/assets/vulkanised_2024/opensource_vulkan_web.jpg"
alt="Iago presenting" /&gt;
&lt;figcaption aria-hidden="true"&gt;Iago presenting&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;Later my colleague Iago presented jointly with Faith Ekstrand (a
well-known Linux graphic stack contributor from Collabora) on “8 Years
of Open Drivers, including the State of Vulkan in Mesa”. They both
talked about the current state of Vulkan in the open source driver
ecosystem, and some of the benefits open source drivers have been able
to take advantage of, like the common Vulkan runtime code and a shared
compiler stack. You can check out &lt;a
href="https://vulkan.org/user/pages/09.events/vulkanised-2024/Vulkanised-2024-faith-ekstrand-collabora-Iago-toral-igalia.pdf"&gt;their
presentation for all the details&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Besides Igalia’s presentations, there were several more which I found
interesting, with topics such as Vulkan developer tools, experiences of
using Vulkan in real work applications, and even how to teach Vulkan to
new developers. Here are some highlights for some of them.&lt;/p&gt;
&lt;h3 id="using-vulkan-synchronization-validation-effectively"&gt;&lt;a
href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-john-zulauf-lunarg.pdf"&gt;Using
Vulkan Synchronization Validation Effectively&lt;/a&gt;&lt;/h3&gt;
&lt;p&gt;John Zulauf had a presentation of the Vulkan synchronization
validation layers that he has been working on. If you are not familiar
with these, then you should really check them out. They work by tracking
how resources are used inside Vulkan and providing error messages with
some hints if you use a resource in a way where it is not synchronized
properly. It can’t catch every error, but it’s a great tool in the
toolbelt of Vulkan developers to make their lives easier when it comes
to debugging synchronization issues. As John said in the presentation,
synchronization in Vulkan is hard, and nearly every application he
tested the layers on reveled a synchronization issue, no matter how
simple it was. He can proudly say he is a vkQuake contributor now
because of these layers.&lt;/p&gt;
&lt;h3 id="years-of-teaching-vulkan-with-example-for-video-extensions"&gt;&lt;a
href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-helmut-hlavacs.pdf"&gt;6
Years of Teaching Vulkan with Example for Video Extensions&lt;/a&gt;&lt;/h3&gt;
&lt;p&gt;This was an interesting presentation from a professor at the
university of Vienna about his experience teaching graphics as well as
game development to students who may have little real programming
experience. He covered the techniques he uses to make learning easier as
well as resources that he uses. This would be a great presentation to
check out if you’re trying to teach Vulkan to others.&lt;/p&gt;
&lt;h3 id="vulkan-synchronization-made-easy"&gt;&lt;a
href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-grigory-dzhavadyan.pdf"&gt;Vulkan
Synchronization Made Easy&lt;/a&gt;&lt;/h3&gt;
&lt;p&gt;Another presentation focused on Vulkan sync, but instead of debugging
it, Grigory showed how his graphics library abstracts sync away from the
user without implementing a render graph. He presented an interesting
technique that is similar to how the sync validation layers work when it
comes ensuring that resources are always synchronized before use. If
you’re building your own engine in Vulkan, this is definitely something
worth checking out.&lt;/p&gt;
&lt;h3 id="vulkan-video-encode-api-a-deep-dive"&gt;&lt;a
href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-tony-zlatinski-nvidia.pdf"&gt;Vulkan
Video Encode API: A Deep Dive&lt;/a&gt;&lt;/h3&gt;
&lt;p&gt;Tony at Nvidia did a deep dive into the new Vulkan Video extensions,
explaining a bit about how video codecs work, and also including a
roadmap for future codec support in the video extensions. Especially
interesting for us was that he made a nice call-out to Igalia and our
work on Vulkan Video CTS and open source driver support on slide (6)
:)&lt;/p&gt;
&lt;h2 id="thoughts-on-vulkanised"&gt;Thoughts on Vulkanised&lt;/h2&gt;
&lt;p&gt;Vulkanised is an interesting conference that gives you the
intersection of people working on Vulkan drivers, game developers using
Vulkan for their graphics backend, visual FX tool developers using
Vulkan-based tools in their pipeline, industrial application developers
using Vulkan for some embedded commercial systems, and general hobbyists
who are just interested in Vulkan. As an example of some of these
interesting audience members, I got to talk with a member of the Blender
foundation about his work on the Vulkan backend to Blender.&lt;/p&gt;
&lt;p&gt;Lastly the event was held at Google’s offices in Sunnyvale. Which I’m
always happy to travel to, not just for the better weather (coming from
Canada), but also for the amazing restaurants and food that’s in the Bay
Area!&lt;/p&gt;
&lt;figure&gt;
&lt;img src="/assets/vulkanised_2024/food_web.jpg"
alt="Great bay area food" /&gt;
&lt;figcaption aria-hidden="true"&gt;Great bay area food&lt;/figcaption&gt;
&lt;/figure&gt;
</description><pubDate>Wed, 14 Feb 2024 05:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/vulkanised_2024.html</guid></item><item><title>Software Rendering and Android</title><link>https://fryzekconcepts.com/notes/android_swrast.html</link><description>&lt;p&gt;My current project at Igalia has had me working on Mesa’s software
renderers, llvmpipe and lavapipe. I’ve been working to get them running
on Android, and I wanted to document the progress I’ve made, the
challenges I’ve faced, and talk a little bit about the development
process for a project like this. My work is not totally merged into
upstream mesa yet, but you can see the MRs I made here:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29344"&gt;llvmpipe:
Add android platform integration&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29785"&gt;u_gralloc/fallback:
Set fd from handle directly&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805"&gt;llvmpipe
&amp;amp; lavalpipe: Implement sync fd import/export extensions&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28735"&gt;lavapipe:
Implement &lt;code&gt;VK_EXT_external_memory_dma_buf&lt;/code&gt;&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="setting-up-an-android-development-environment"&gt;Setting up an
Android development environment&lt;/h2&gt;
&lt;p&gt;Getting system level software to build and run on Android is
unfortunately not straightforward. Since we are doing software rendering
we don’t need a physical device and instead we can make use of the
Android emulator, and if you didn’t know Android has two emulators, the
common one most people use is “goldfish” and the other lesser known is
“cuttlefish”. For this project I did my work on the cuttlefish emulator
as its meant for testing the Android OS itself instead of just Android
apps and is more reflective of real hardware. The cuttlefish emulator
takes a little bit more work to setup, and I’ve found that it only works
properly in Debian based linux distros. I run Fedora, so I had to run
the emulator in a debian VM.&lt;/p&gt;
&lt;p&gt;Thankfully Google has good instructions for building and running
cuttlefish, which you can find &lt;a
href="https://source.android.com/docs/devices/cuttlefish/get-started"&gt;here&lt;/a&gt;.
The instructions show you how to setup the emulator using nightly build
images from Google. We’ll also need to setup our own Android OS images
so after we’ve confirmed we can run the emulator, we need to start
looking at building AOSP.&lt;/p&gt;
&lt;p&gt;For building our own AOSP image, we can also follow the instructions
from Google &lt;a
href="https://source.android.com/docs/setup/build/building"&gt;here&lt;/a&gt;.
For the target we’ll want
&lt;code&gt;aosp_cf_x86_64_phone-trunk_staging-eng&lt;/code&gt;. At this point it’s
a good idea to verify that you can build the image, which you can do by
following the rest of the instructions on the page. Building AOSP from
source does take a while though, so prepare to wait potentially an
entire day for the image to build. Also if you get errors complaining
that you’re out of memory, you can try to reduce the number of parallel
builds. Google officially recommends to have 64GB of RAM, and I only had
32GB so some packages had to be built with the parallel builds set to 1
so I wouldn’t run out of RAM.&lt;/p&gt;
&lt;p&gt;For running this custom-built image on Cuttlefish, you can just copy
all the &lt;code&gt;*.img&lt;/code&gt; files from
&lt;code&gt;out/target/product/vsoc_x86_64/&lt;/code&gt; to the root cuttlefish
directory, and then launch cuttlefish. If everything worked successfully
you should be able to see your custom built AOSP image running in the
cuttlefish webui.&lt;/p&gt;
&lt;h2 id="building-mesa-targeting-android"&gt;Building Mesa targeting
Android&lt;/h2&gt;
&lt;p&gt;Working from the changes in MR &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29344"&gt;!29344&lt;/a&gt;
building llvmpipe or lavapipe targeting Android should just work™️. To
get to that stage required a few changes. First llvmpipe actually
already had some support on Android, as long as it was running on a
device that supports a DRM display driver. In that case it could use the
&lt;code&gt;dri&lt;/code&gt; window system integration which already works on
Android. I wanted to get llvmpipe (and lavapipe) running without dri, so
I had to add support for Android in the &lt;code&gt;drisw&lt;/code&gt; window system
integration.&lt;/p&gt;
&lt;p&gt;To support Android in &lt;code&gt;drisw&lt;/code&gt;, this mainly meant adding
support for importing dmabuf as framebuffers. The Android windowing
system will provide us with a “gralloc” buffer which inside has a dmabuf
fd that represents the framebuffer. Adding support for importing dmabufs
in drisw means we can import and begin drawing to these frame buffers.
Most the changes to support that can be found in &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/src/gallium/frontends/dri/drisw.c#L405"&gt;&lt;code&gt;drisw_allocate_textures&lt;/code&gt;&lt;/a&gt;
and the underlying changes to llvmpipe to support importing dmabufs in
MR &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805"&gt;!27805&lt;/a&gt;.
The EGL Android platform code also needed some changes to use the
&lt;code&gt;drisw&lt;/code&gt; window system code. Previously this code would only
work with true dri drivers, but with some small tweaks it was possible
to get to have it initialize the drisw window system and then using it
for rendering if no hardware devices are available.&lt;/p&gt;
&lt;p&gt;For lavapipe the changes were a lot simpler. The Android Vulkan
loader requires your driver to have &lt;code&gt;HAL_MODULE_INFO_SYM&lt;/code&gt;
symbol in the binary, so that got created and populated correctly,
following other Vulkan drivers in Mesa like turnip. Then the image
creation code had to be modified to support the
&lt;code&gt;VK_ANDROID_native_buffer&lt;/code&gt; extension which allows the Android
Vulkan loader to create images using Android native buffer handles.
Under the hood this means getting the dmabuf fd from the native buffer
handle. Thankfully mesa already has some common code to handle this, so
I could just use that. Some other small changes were also necessary to
address crashes and other failures that came up during testing.&lt;/p&gt;
&lt;p&gt;With the changes out of of the way we can now start building Mesa on
Android. For this project I had to update the Android documentation for
Mesa to include steps for building LLVM for Android since the version
Google ships with the NDK is missing libraries that llvmpipe/lavapipe
need to function. You can see the updated documentation &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/drivers/llvmpipe.rst"&gt;here&lt;/a&gt;
and &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/android.rst"&gt;here&lt;/a&gt;.
After sorting out LLVM, building llvmpipe/lavapipe is the same as
building any other Mesa driver for Android: we setup a cross file to
tell meson how to cross compile and then we run meson. At this point you
could manual modify the Android image and copy these files to the vm,
but I also wanted to support building a new AOSP image directly
including the driver. In order to do that you also have to rename the
driver binaries to match Android’s naming convention, and make sure
SO_NAME matches as well. If you check out &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/android.rst?plain=1#L183"&gt;this&lt;/a&gt;
section of the documentation I wrote, it covers how to do that.&lt;/p&gt;
&lt;p&gt;If you followed all of that you should have built an version of
llvmpipe and lavapipe that you can run on Android’s cuttlefish
emulator.&lt;/p&gt;
&lt;figure&gt;
&lt;img src="/assets/2024-06-27-android-swrast/lavapipe.png"
alt="Android running lavapipe" /&gt;
&lt;figcaption aria-hidden="true"&gt;Android running lavapipe&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;h2 id="references"&gt;References&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29344"
class="uri"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29344&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;Main MR with Android changes&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://source.android.com/docs/devices/cuttlefish/get-started"
class="uri"&gt;https://source.android.com/docs/devices/cuttlefish/get-started&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;Google’s official guide for getting started with the Cuttlefish
emulator&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://source.android.com/docs/setup/build/building"
class="uri"&gt;https://source.android.com/docs/setup/build/building&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;Google’s official guide for building AOSP images&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/drivers/llvmpipe.rst"
class="uri"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/drivers/llvmpipe.rst&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;My updated documentation in MR for llvmpipe&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/android.rst"
class="uri"&gt;https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/android.rst&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;My updated documentation in MR for Android integration in mesa&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;/ul&gt;
</description><pubDate>Thu, 27 Jun 2024 04:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/android_swrast.html</guid></item><item><title>2024 Graphics Team Contributions at Igalia</title><link>https://fryzekconcepts.com/notes/2024_igalia_graphics_team.html</link><description>&lt;p&gt;2024 has been an exciting year for the &lt;a
href="https://www.igalia.com/technology/graphics"&gt;Igalia’s Graphics
Team&lt;/a&gt;. We’ve been making a lot of progress on Turnip, AMD display
driver, the Raspberry Pi graphics stack, Vulkan video, and more.&lt;/p&gt;
&lt;h2 id="vulkan-device-generated-commands"&gt;Vulkan Device Generated
Commands&lt;/h2&gt;
&lt;p&gt;Igalia’s Ricardo Garcia has been working hard on adding support for
the new &lt;code&gt;VK_EXT_device_generated_commands&lt;/code&gt; extension in the
Vulkan Conformance Test Suite. He wrote an excellent blog post on the
extension and on his work that you can read &lt;a
href="https://rg3.name/202409270942.html"&gt;here&lt;/a&gt;. Ricardo also
presented the extension at XDC 2024 in Montréal, which he also &lt;a
href="https://rg3.name/202411181555.html"&gt;blogged about&lt;/a&gt;. Take a look
and see what generating Vulkan commands directly on the GPU looks
like!&lt;/p&gt;
&lt;h2 id="raspberry-pi-enhancements-performance-improvements"&gt;Raspberry Pi
Enhancements &amp;amp; Performance Improvements&lt;/h2&gt;
&lt;p&gt;Our very own Maíra Canal made a big contribution to improve the
graphics performance of Raspberry Pi 4 &amp;amp; 5 devices by introducing
support for “Super Pages”. She wrote an excellent and detailed blog post
on what Super Pages are, how they improve performance, and comparing
performance of different apps and games. You can read all the juicy
details &lt;a
href="https://mairacanal.github.io/unleashing-power-enabling-super-pages-on-RPi/"&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;She also worked on introducing CPU jobs to the Broadcom GPU kernel
driver in Linux. These changes allow user space to implement jobs that
get executed on the CPU in sync with the work on the GPU. She wrote a
great blog post detailing what CPU jobs allow you to do and how they
work that you can read &lt;a
href="https://mairacanal.github.io/introducing-cpu-jobs-to-the-rpi/"&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Christian Gmeiner on the Graphics team has also been working on
adding Perfetto support to Broadcom GPUs. Perfetto is a performance
tracing tool and support for it in Broadcom drivers will allow to
developers to gain more insight into bottlenecks of their GPU
applications. You can check out his changes to add support in the
following MRs: - &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31575"&gt;MR
31575&lt;/a&gt; - &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32277"&gt;MR
32277&lt;/a&gt; - &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31751"&gt;MR
31751&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;The Raspberry Pi team here at Igalia presented all of their work at
XDC 2024 in Montréal. You can see a video below.&lt;/p&gt;
&lt;p&gt;&lt;div class="youtube-video"&gt;&lt;iframe src="https://www.youtube.com/embed/tlSFHkp6ODM"&gt;&lt;/iframe&gt;&lt;/div&gt;&lt;/p&gt;
&lt;h2 id="linux-kernel-6.8"&gt;Linux Kernel 6.8&lt;/h2&gt;
&lt;p&gt;A number of Igalians made several contributions to the Linux 6.8
kernel release back in March of this year. Our colleague Maíra wrote a
great blog post outlining these contributions that you can read &lt;a
href="https://mairacanal.github.io/introducing-cpu-jobs-to-the-rpi/"&gt;here&lt;/a&gt;.
To highlight some of these contributions:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;AMD HDR &amp;amp; Color Management
&lt;ul&gt;
&lt;li&gt;Melissa Wen has been working on improving and implementing HDR
support in AMD’s display driver as well as working on color management
in the Linux display stack.&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;Async Flip
&lt;ul&gt;
&lt;li&gt;André Almeida implemented support for asynchronous page flip in the
atomic DRM modesetting API.&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;V3D 7.1.x Kernel Driver
&lt;ul&gt;
&lt;li&gt;Iago Toral contributed a number of patches upstream to get the
Broadcom DRM driver working with the latest Broadcom hardware used in
the Raspberry Pi 5.&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;GPU stats for the Raspberry Pi 4/5
&lt;ul&gt;
&lt;li&gt;José María “Chema” Casanova worked on adding GPU stats support to
the latest Raspberry Pi hardware.&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="turnip-improvements"&gt;Turnip Improvements&lt;/h2&gt;
&lt;p&gt;Dhruv Mark Collins has been very hard at work to try and bring
performance parity between Qualcomm’s proprietary driver and the open
source Turnip driver. Two of his big contributions to this were
improving the 2D buffer to image copies on A7XX devices, and
implementing unidirectional Low Resolution Z (LRZ) on A7XX devices. You
can see the MR for these changes &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31401"&gt;here&lt;/a&gt;
and &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29453"&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;A new member of the Igalia Graphics Team Karmjit Mahil has been
working on different parts of the Turnip stack, but one notable
improvement he made was to improve &lt;code&gt;fmulz&lt;/code&gt; handling for
Direct3D 9. You can check out his changes &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31479"&gt;here&lt;/a&gt;
and read more about them.&lt;/p&gt;
&lt;p&gt;Danylo Piliaiev has been hard at work adding support for the latest
generation of Adreno GPUs. This included getting support for the &lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26934"&gt;A750
working&lt;/a&gt;, and then implementing performance improvements to bring it
up to parity with other Adreno GPUs in Turnip. He also worked on
implementing a number of Vulkan extensions and performance improvements
such as:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;VK_KHR_shader_atomic_int64
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27776"&gt;MR
27776&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_KHR_fragment_shading_rate
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30905"&gt;MR
30905&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_KHR_8bit_storage
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28254"&gt;MR
28254&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;shaderInt8 feature
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29875"&gt;MR
29875&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_KHR_shader_subgroup_rotate
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31358"&gt;MR
31358&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_EXT_map_memory_placed
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28928"&gt;MR
28928&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_EXT_legacy_dithering
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30536"&gt;MR
30536&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;VK_EXT_depth_clamp_zero_one
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29387"&gt;MR
29387&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="display-next-hackfest-displaykms-meet-up"&gt;Display Next Hackfest
&amp;amp; Display/KMS Meet-up&lt;/h2&gt;
&lt;p&gt;Igalia hosted the 2024 version of the Display Next Hackfest. This
community event is a way to get Linux display developers together to
work on improving the Linux display stack. Our Melissa Wen wrote a blog
post about the event and what it was like to organize it. You can read
all about it &lt;a
href="https://melissawen.github.io/blog/2024/09/25/reflections-2024-display-next-hackfest"&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;figure&gt;
&lt;img
src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-0.jpg"
alt="Display Next Hackfest" /&gt;
&lt;figcaption aria-hidden="true"&gt;Display Next Hackfest&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;Just in-case you thought you couldn’t get enough Linux display stack,
Melissa also helped organize a Display/KMS meet-up at XDC 2024. She
wrote all about that meet-up and the progress the community made on her
blog &lt;a
href="https://melissawen.github.io/blog/2024/11/19/summary-display-kms-meeting-xdc2024"&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id="amd-display-amdgpu"&gt;AMD Display &amp;amp; AMDGPU&lt;/h2&gt;
&lt;p&gt;Melissa Wen has also been hard at work improving AMDGPU’s display
driver. She made a number of changes including &lt;a
href="https://lore.kernel.org/amd-gfx/ea31b795-5b75-40e6-846e-51dc6696f8bc@amd.com/#t"&gt;improving
display debug log&lt;/a&gt; to include hardware color capabilities, &lt;a
href="https://lore.kernel.org/amd-gfx/20240927230600.2619844-1-superm1@kernel.org/"&gt;Migrating
EDID handling to EDID common code&lt;/a&gt; and various bug fixes such as:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Fixing null-pointer dereference on edid reading
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://lore.kernel.org/amd-gfx/20240216122401.216860-1-mwen@igalia.com/"&gt;https://lore.kernel.org/amd-gfx/20240216122401.216860-1-mwen@igalia.com/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;Checking dc_link before dereferencing
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://lore.kernel.org/amd-gfx/20240227190828.444715-1-mwen@igalia.com/"&gt;https://lore.kernel.org/amd-gfx/20240227190828.444715-1-mwen@igalia.com/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;Using mpcc_count to log MPC state
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://lore.kernel.org/amd-gfx/20240412163928.118203-1-mwen@igalia.com/"&gt;https://lore.kernel.org/amd-gfx/20240412163928.118203-1-mwen@igalia.com/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;Fixing cursor offset on rotation 180
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://lore.kernel.org/amd-gfx/20240807075546.831208-22-chiahsuan.chung@amd.com/"&gt;https://lore.kernel.org/amd-gfx/20240807075546.831208-22-chiahsuan.chung@amd.com/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;Fixes for kernel crashes since cursor overlay mode
&lt;ul&gt;
&lt;li&gt;&lt;a
href="https://lore.kernel.org/amd-gfx/20241217205029.39850-1-mwen@igalia.com/"&gt;https://lore.kernel.org/amd-gfx/20241217205029.39850-1-mwen@igalia.com/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Tvrtko Ursulin, a recent addition to our team, has been working on
fixing issues in AMDGPU and some of the Linux kernel’s common code. For
example, he worked on fixing bugs in the DRM scheduler around missing
locks, optimizing the re-lock cycle on the submit path, and cleaned up
the code. On AMDGPU he worked on improving memory usage reporting,
fixing out of bounds writes, and micro-optimized ring emissions. For DMA
fence he simplified fence merging and resolved a potential memory leak.
Lastly, on workqueue he fixed false positive sanity check warnings that
AMDGPU &amp;amp; DRM scheduler interactions were triggering. You can see the
code for some of changes below: - &lt;a
href="https://lore.kernel.org/amd-gfx/20240906180639.12218-1-tursulin@igalia.com/"&gt;https://lore.kernel.org/amd-gfx/20240906180639.12218-1-tursulin@igalia.com/&lt;/a&gt;
- &lt;a
href="https://lore.kernel.org/amd-gfx/20241008150532.23661-1-tursulin@igalia.com/"&gt;https://lore.kernel.org/amd-gfx/20241008150532.23661-1-tursulin@igalia.com/&lt;/a&gt;
- &lt;a
href="https://lore.kernel.org/amd-gfx/20241227111938.22974-1-tursulin@igalia.com/"&gt;https://lore.kernel.org/amd-gfx/20241227111938.22974-1-tursulin@igalia.com/&lt;/a&gt;
- &lt;a
href="https://lore.kernel.org/amd-gfx/20240813135712.82611-1-tursulin@igalia.com/"&gt;https://lore.kernel.org/amd-gfx/20240813135712.82611-1-tursulin@igalia.com/&lt;/a&gt;
- &lt;a
href="https://lore.kernel.org/amd-gfx/20240712152855.45284-1-tursulin@igalia.com/"&gt;https://lore.kernel.org/amd-gfx/20240712152855.45284-1-tursulin@igalia.com/&lt;/a&gt;&lt;/p&gt;
&lt;h2 id="vulkan-opengl-extensions"&gt;Vulkan &amp;amp; OpenGL Extensions&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;GL_EXT_texture_offset_non_const&lt;/code&gt;
&lt;ul&gt;
&lt;li&gt;Ricardo was busy working on extending OpenGL by adding &lt;a
href="https://github.com/KhronosGroup/GLSL/blob/main/extensions/ext/GL_EXT_texture_offset_non_const.txt"&gt;this&lt;/a&gt;
extension to GLSL as well as providing an implementation for it in &lt;a
href="https://github.com/KhronosGroup/glslang/pull/3782"&gt;glslang&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;VK_KHR_video_encode_av1&lt;/code&gt; &amp;amp;
&lt;code&gt;VK_KHR_video_decode_av1&lt;/code&gt;
&lt;ul&gt;
&lt;li&gt;Igalia is listed as a contributor to these extensions and worked
very hard to implement CTS support for the extensions.&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="etnaviv-improvements"&gt;Etnaviv Improvements&lt;/h2&gt;
&lt;p&gt;Christian Gmeiner, one of the maintainers of the Etnaviv driver for
Vivante GPUs, has been hard at work this year to make a number of big
improvements to Etnaviv. This includes using hwdb to detect GPU
features, which he wrote about &lt;a
href="https://christian-gmeiner.info/2024-04-12-hwdb/"&gt;here&lt;/a&gt;. Another
big improvement was migrating Etnaviv to use isaspec for the GPU isa
description, allowing an assembler and disassembler to be generated from
XML. This also allowed Etnaviv to reuse some common features in Mesa for
assemblers/disassemblers and take advantage of the python code
generation features others in the community have been working on. He
wrote a detailed blog about it, that you can find &lt;a
href="https://christian-gmeiner.info/2024-07-11-it-all-started-with-a-nop-part1/"&gt;here&lt;/a&gt;.
On the same vein of Etnaviv infrastructure improvements, Christian has
also been working on a new shader compiler, written in Rust, called
“EBC”. Christian presented this new shader compiler at XDC 2024 this
year. You can check out his presentation below.&lt;/p&gt;
&lt;p&gt;&lt;div class="youtube-video"&gt;&lt;iframe src="https://www.youtube.com/embed/n_fn4evXeZo"&gt;&lt;/iframe&gt;&lt;/div&gt;&lt;/p&gt;
&lt;p&gt;On the side of new features, Christian landed a big one in Mesa 24.03
for Etnaviv: Multiple Render Target (MRT) support! This allows games and
applications to render to multiple render targets (think framebuffers)
in a single graphics operations. This feature is heavily used by
deferred rendering techniques, and is a requirement for later versions
of desktop OpenGL and OpenGL ES 3. Keep an eye on &lt;a
href="https://christian-gmeiner.info/"&gt;Christian’s blog&lt;/a&gt; to see any
of his future announcements.&lt;/p&gt;
&lt;h2 id="lavapipellvmpipe-android-chromeos"&gt;Lavapipe/LLVMpipe, Android
&amp;amp; ChromeOS&lt;/h2&gt;
&lt;p&gt;I had a busy year working on improving Lavapipe/LLVMpipe platform
integration. This started with adding support for DMABUF import/export,
so that the display handles from Android Window system could be properly
imported and mapped. Next came Android window system integration for DRI
software rendering backend in EGL, and lastly but most importantly came
updating the documentation in Mesa for building Android support. I wrote
all about this effort &lt;a href="/notes/android_swrast.html"&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;The latter half on the year had me working on improving lavapipe’s
integration with ChromeOs, and having Lavapipe work as a host Vulkan
driver for Venus. You can see some of the changes I made in
virglrenderer &lt;a
href="https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1458"&gt;here&lt;/a&gt;
and crosvm &lt;a
href="https://gitlab.freedesktop.org/Hazematman/crosvm/-/commit/9ee86e72edfb3a652148dd233ffca75847949558"&gt;here&lt;/a&gt;.
This work is still ongoing.&lt;/p&gt;
&lt;h2 id="whats-next"&gt;What’s Next?&lt;/h2&gt;
&lt;p&gt;We’re not planning to stop our 2024 momentum, and we’re hopping for
2025 to be a great year for Igalia and the Linux graphics stack! I’m
booked to present about &lt;a
href="https://www.vulkan.org/events/vulkanised-2025#agenda"&gt;Lavapipe at
Vulkanised 2025&lt;/a&gt;, where Ricardo will also present about
Device-Generated Commands. Maíra &amp;amp; Chema will be presenting together
at FOSDEM 2025 about improving performance on Raspberry Pi GPUs, and
Melissa will also present about kworkflow there. We’ll also be at XDC
2025, networking and presenting about all the work we are doing on the
Linux graphics stack. Thanks for following our work this year, and
here’s to making 2025 an even better year for Linux graphics!&lt;/p&gt;
</description><pubDate>Fri, 20 Dec 2024 05:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/2024_igalia_graphics_team.html</guid></item></channel></rss>