path: root/html/graphics_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>Mon, 25 Sep 2023 19:42:55 -0000</lastBuildDate><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>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></channel></rss>