diff options
| -rw-r--r-- | html/graphics_feed.xml | 2 | ||||
| -rw-r--r-- | html/igalia_feed.xml | 1224 |
2 files changed, 1225 insertions, 1 deletions
diff --git a/html/graphics_feed.xml b/html/graphics_feed.xml index 6808c14..5f38aca 100644 --- a/html/graphics_feed.xml +++ b/html/graphics_feed.xml @@ -1,5 +1,5 @@ <?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>Tue, 08 Apr 2025 21:24:40 -0000</lastBuildDate><item><title>2022 Graphics Team Contributions at Igalia</title><link>https://fryzekconcepts.com/notes/2022_igalia_graphics_team.html</link><description><p>This year I started a new job working with <a +<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>Wed, 16 Apr 2025 13:01:17 -0000</lastBuildDate><item><title>2022 Graphics Team Contributions at Igalia</title><link>https://fryzekconcepts.com/notes/2022_igalia_graphics_team.html</link><description><p>This year I started a new job working with <a href="https://www.igalia.com/technology/graphics">Igalia’s Graphics Team</a>. For those of you who don’t know <a href="https://www.igalia.com/">Igalia</a> they are a <a diff --git a/html/igalia_feed.xml b/html/igalia_feed.xml new file mode 100644 index 0000000..5f38aca --- /dev/null +++ b/html/igalia_feed.xml @@ -0,0 +1,1224 @@ +<?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>Wed, 16 Apr 2025 13:01:17 -0000</lastBuildDate><item><title>2022 Graphics Team Contributions at Igalia</title><link>https://fryzekconcepts.com/notes/2022_igalia_graphics_team.html</link><description><p>This year I started a new job working with <a +href="https://www.igalia.com/technology/graphics">Igalia’s Graphics +Team</a>. For those of you who don’t know <a +href="https://www.igalia.com/">Igalia</a> they are a <a +href="https://en.wikipedia.org/wiki/Igalia">“worker-owned, employee-run +cooperative model consultancy focused on open source software”</a>.</p> +<p>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!</p> +<h2 id="vulkan-1.2-conformance-on-rpi-4">Vulkan 1.2 Conformance on RPi +4</h2> +<p>One of the big milestones for the team in 2022 was <a +href="https://www.khronos.org/conformance/adopters/conformant-products#submission_694">achieving +Vulkan 1.2 conformance on the Raspberry Pi 4</a>. The folks over at the +Raspberry Pi company wrote a nice <a +href="https://www.raspberrypi.com/news/vulkan-update-version-1-2-conformance-for-raspberry-pi-4/">article</a> +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.</p> +<p>The Vulkan 1.2 spec ratification came with a few <a +href="https://registry.khronos.org/vulkan/specs/1.2-extensions/html/vkspec.html#versions-1.2">extensions</a> +that were promoted to Core. This means a conformant Vulkan 1.2 driver +needs to implement those extensions. Alejandro Piñeiro wrote this +interesting <a +href="https://blogs.igalia.com/apinheiro/2022/05/v3dv-status-update-2022-05-16/">blog +post</a> that talks about some of those extensions.</p> +<p>Vulkan 1.2 also came with a number of optional extensions such as +<code>VK_KHR_pipeline_executable_properties</code>. My colleague Iago +Toral wrote an excellent <a +href="https://blogs.igalia.com/itoral/2022/05/09/vk_khr_pipeline_executables/">blog +post</a> on how we implemented that extension on the Raspberry Pi 4 and +what benefits it provides for debugging.</p> +<h2 id="vulkan-1.3-support-on-turnip">Vulkan 1.3 support on Turnip</h2> +<p>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 <a +href="https://blogs.igalia.com/dpiliaiev/turnip-vulkan-1-3/">blog +post</a> 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.</p> +<p>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 +<a +href="https://blogs.igalia.com/dpiliaiev/turnip-july-2022-update/">post</a> +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.</p> +<p><div class="youtube-video"><iframe src="https://www.youtube.com/embed/oVFWy25uiXA"></iframe></div></p> +<h2 id="vulkan-extensions">Vulkan Extensions</h2> +<p>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 <a +href="https://rg3.name/202212122137.html">blog post</a> about those +contributions. Below I’ve listed what Igalia did for each of the +extensions:</p> +<ul> +<li>VK_EXT_image_2d_view_of_3d +<ul> +<li>We reviewed the spec and are listed as contributors to this +extension</li> +</ul></li> +<li>VK_EXT_shader_module_identifier +<ul> +<li>We reviewed the spec, contributed to it, and created tests for this +extension</li> +</ul></li> +<li>VK_EXT_attachment_feedback_loop_layout +<ul> +<li>We reviewed, created tests and contributed to this extension</li> +</ul></li> +<li>VK_EXT_mesh_shader +<ul> +<li>We contributed to the spec and created tests for this extension</li> +</ul></li> +<li>VK_EXT_mutable_descriptor_type +<ul> +<li>We reviewed the spec and created tests for this extension</li> +</ul></li> +<li>VK_EXT_extended_dynamic_state3 +<ul> +<li>We wrote tests and reviewed the spec for this extension</li> +</ul></li> +</ul> +<h2 id="amdgpu-kernel-driver-contributions">AMDGPU kernel driver +contributions</h2> +<p>Our resident “Not an AMD expert” Melissa Wen made several +contributions to the AMDGPU driver. Those contributions include +connecting parts of the <a +href="https://lore.kernel.org/amd-gfx/20220329201835.2393141-1-mwen@igalia.com/">pixel +blending and post blending code in AMD’s <code>DC</code> module to +<code>DRM</code></a> and <a +href="https://lore.kernel.org/amd-gfx/20220804161349.3561177-1-mwen@igalia.com/">fixing +a bug related to how panel orientation is set when a display is +connected</a>. She also had a <a +href="https://indico.freedesktop.org/event/2/contributions/50/">presentation +at XDC 2022</a>, where she talks about techniques you can use to +understand and debug AMDGPU, even when there aren’t hardware docs +available.</p> +<p>André Almeida also completed and submitted work on <a +href="https://lore.kernel.org/dri-devel/20220714191745.45512-1-andrealmeid@igalia.com/">enabled +logging features for the new GFXOFF hardware feature in AMD GPUs</a>. He +also created a userspace application (which you can find <a +href="https://gitlab.freedesktop.org/andrealmeid/gfxoff_tool">here</a>), +that lets you interact with this feature through the +<code>debugfs</code> interface. Additionally, he submitted a <a +href="https://lore.kernel.org/dri-devel/20220929184307.258331-1-contact@emersion.fr/">patch</a> +for async page flips (which he also talked about in his <a +href="https://indico.freedesktop.org/event/2/contributions/61/">XDC 2022 +presentation</a>) which is still yet to be merged.</p> +<h2 id="modesetting-without-glamor-on-rpi">Modesetting without Glamor on +RPi</h2> +<p>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 <a +href="https://www.freedesktop.org/wiki/Software/Glamor/">Glamor</a> +which allows making more video memory available to graphics applications +running on a Raspberry Pi.</p> +<p>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 <a +href="https://blogs.igalia.com/cmichael/2022/05/30/modesetting-a-glamor-less-rpi-adventure/">blog +post</a> on this work. Both him and Chema also had a joint presentation +at XDC 2022 going into more detail on this work.</p> +<h2 id="linux-format-magazine-column">Linux Format Magazine Column</h2> +<p>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; 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 <a +href="https://linuxformat.com/linux-format-288.html">issue #288</a>!</p> +<h2 id="xdc-2022">XDC 2022</h2> +<p>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:</p> +<h3 +id="replacing-the-geometry-pipeline-with-mesh-shaders-ricardo-garcía"><a +href="https://indico.freedesktop.org/event/2/contributions/48/">“Replacing +the geometry pipeline with mesh shaders”</a> (Ricardo García)</h3> +<p>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 <a +href="https://rg3.name/202210222107.html">blog post</a> on his +presentation that should check out!</p> +<p><div class="youtube-video"><iframe src="https://www.youtube.com/embed/aRNJ4xj_nDs"></iframe></div></p> +<h3 id="status-of-vulkan-on-raspberry-pi-iago-toral"><a +href="https://indico.freedesktop.org/event/2/contributions/68/">“Status +of Vulkan on Raspberry Pi”</a> (Iago Toral)</h3> +<p>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.</p> +<p><div class="youtube-video"><iframe src="https://www.youtube.com/embed/GM9IojyzCVM"></iframe></div></p> +<h3 +id="enable-hardware-acceleration-for-gl-applications-without-glamor-on-xorg-modesetting-driver-jose-maría-casanova-christopher-michael"><a +href="https://indico.freedesktop.org/event/2/contributions/60/">“Enable +hardware acceleration for GL applications without Glamor on Xorg +modesetting driver”</a> (Jose María Casanova, Christopher Michael)</h3> +<p>Chema and Christopher talk about the challenges they had to solve to +enable hardware acceleration on the Raspberry Pi without Glamor.</p> +<p><div class="youtube-video"><iframe src="https://www.youtube.com/embed/Bo_MOM7JTeQ"></iframe></div></p> +<h3 id="im-not-an-amd-expert-but-melissa-wen"><a +href="https://indico.freedesktop.org/event/2/contributions/50/">“I’m not +an AMD expert, but…”</a> (Melissa Wen)</h3> +<p>In this non-technical presentation, Melissa talks about techniques +developers can use to understand and debug drivers without access to +hardware documentation.</p> +<p><div class="youtube-video"><iframe src="https://www.youtube.com/embed/CMm-yhsMB7U"></iframe></div></p> +<h3 id="async-page-flip-in-atomic-api-andré-almeida"><a +href="https://indico.freedesktop.org/event/2/contributions/61/">“Async +page flip in atomic API”</a> (André Almeida)</h3> +<p>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.</p> +<p><div class="youtube-video"><iframe src="https://www.youtube.com/embed/qayPPIfrqtE"></iframe></div></p> +<h2 id="fosdem-2022">FOSDEM 2022</h2> +<p>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.</p> +<h3 id="the-status-of-turnip-driver-development-hyunjun-ko"><a +href="https://archive.fosdem.org/2022/schedule/event/turnip/">The status +of Turnip driver development</a> (Hyunjun Ko)</h3> +<p>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 <a +href="https://blogs.igalia.com/zzoon/graphics/mesa/2022/02/21/complement-story/">blog +post</a> to checkout along with his presentation.</p> +<h3 +id="v3dv-status-update-for-open-source-vulkan-driver-for-raspberry-pi-4-alejandro-piñeiro"><a +href="https://archive.fosdem.org/2022/schedule/event/v3dv/">v3dv: Status +Update for Open Source Vulkan Driver for Raspberry Pi 4</a> (Alejandro +Piñeiro)</h3> +<p>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.</p> +<h3 id="fun-with-border-colors-in-vulkan-ricardo-garcia"><a +href="https://archive.fosdem.org/2022/schedule/event/vulkan_borders/">Fun +with border colors in Vulkan</a> (Ricardo Garcia)</h3> +<p>Ricardo presents about the work he did on the +<code>VK_EXT_border_color_swizzle</code> extension in Vulkan. He talks +about the specific contributions he did and how the extension fits in +with sampling color operations in Vulkan.</p> +<h2 id="gsoc-igalia-ce">GSoC &amp; Igalia CE</h2> +<p>Last year Melissa &amp; André co-mentored contributors working on +introducing KUnit tests to the AMD display driver. This project was +hosted as a <a href="https://summerofcode.withgoogle.com/">“Google +Summer of Code” (GSoC)</a> 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 <a +href="https://lpc.events/event/16/contributions/1310/">Linux Plumbers +Conference 2022</a> and across two talks at XDC 2022. Here you can see +their <a +href="https://indico.freedesktop.org/event/2/contributions/65/">first</a> +presentation and here you can see their <a +href="https://indico.freedesktop.org/event/2/contributions/164/">second</a> +second presentation.</p> +<p>André &amp; Melissa also mentored two <a +href="https://www.igalia.com/coding-experience/">“Igalia Coding +Experience” (CE)</a> 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 <a +href="https://mairacanal.github.io/january-update-finishing-my-igalia-ce/">wrote +about her experience</a> being part of the Igalia CE.</p> +<p>Ella Stanforth was also part of the Igalia Coding Experience, being +mentored by Iago &amp; Alejandro. They worked on the +<code>VK_KHR_sampler_ycbcr_conversion</code> extension for the v3dv +driver. Alejandro talks about their work in his <a +href="https://blogs.igalia.com/apinheiro/2023/01/v3dv-status-update-2023-01/">blog +post here</a>.</p> +<h1 id="whats-next">What’s Next?</h1> +<p>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!</p> +<p>Also, you might have heard that <a +href="https://www.igalia.com/2022/xdc-2023">Igalia will be hosting XDC +2023</a> 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 <a +href="https://www.youtube.com/watch?v=7hWcu8O9BjM">dream in the +Atlantic!</a></p> +<figure> +<img src="https://www.igalia.com/assets/i/news/XDC-event-banner.jpg" +alt="Photo of A Coruña" /> +<figcaption aria-hidden="true">Photo of A Coruña</figcaption> +</figure> +</description><pubDate>Thu, 02 Feb 2023 00: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><figure> +<img src="/assets/freedreno/glinfo_freedreno.png" +alt="Android running Freedreno" /> +<figcaption aria-hidden="true">Android running Freedreno</figcaption> +</figure> +<p>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.</p> +<h2 id="when-drm-isnt-just-drm">When “DRM” isn’t just “DRM”</h2> +<p>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.</p> +<p>When I started the work for a new backend I looked inside mesa’s +<code>src/freedreno/drm</code> 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.</p> +<p>For example the <code>drm</code> 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.</p> +<h2 id="how-to-get-android-to-behave">How to get Android to behave</h2> +<p>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 <a +href="https://blogs.igalia.com/dpiliaiev/">Danylo</a> 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 <a +href="https://docs.mesa3d.org/android.html">here</a>. These instructions +<em>almost</em> 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 <code>system</code> in the cross compiler script +incorrectly set the system as <code>linux</code> instead of +<code>android</code>. 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.</p> +<pre class="meson"><code>[binaries] +ar = &#39;/home/lfryzek/Documents/projects/igalia/freedreno/android-ndk-r25b-linux/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-ar&#39; +c = [&#39;ccache&#39;, &#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&#39;] +cpp = [&#39;ccache&#39;, &#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++&#39;, &#39;-fno-exceptions&#39;, &#39;-fno-unwind-tables&#39;, &#39;-fno-asynchronous-unwind-tables&#39;, &#39;-static-libstdc++&#39;] +c_ld = &#39;lld&#39; +cpp_ld = &#39;lld&#39; +strip = &#39;/home/lfryzek/Documents/projects/igalia/freedreno/android-ndk-r25b-linux/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-strip&#39; +# Android doesn&#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 = [&#39;env&#39;, &#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&#39;, &#39;/usr/bin/pkg-config&#39;] + +[host_machine] +system = &#39;android&#39; +cpu_family = &#39;arm&#39; +cpu = &#39;armv8&#39; +endian = &#39;little&#39;</code></pre> +<p>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 <a +href="https://www.igalia.com/team/mark">Mark</a> 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 <a +href="https://android.googlesource.com/platform/frameworks/native/+/master/opengl/libs/EGL/Loader.cpp">Android’s +source code</a>. 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 +<code>/vendor/lib64/egl</code> folder, <code>libEGL_adreno.so</code> +,<code>libGLESv1_CM_adreno.so</code>, and <code>libGLESv2.so</code>. 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.</p> +<p>Something cool that the opensource Freedreno &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 <a +href="https://gitlab.freedesktop.org/freedreno/freedreno">freedreno +repo</a>, they have an <code>ndk-build.sh</code> script that can build +tests in the <code>tests-*</code> 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 <code>libwrap</code> tool that lets trace the commands +being submitted to the GPU.</p> +<h2 id="what-even-is-gralloc">What even is Gralloc?</h2> +<p>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 +<code>src/egl/driver/dri2/platform_android.c</code> 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 <code>platform_android.c</code> +assumes a DRM gralloc implementation. Thankfully the turnip developers +had already gone through this struggle and if you look in +<code>src/freedreno/vulkan/tu_android.c</code> 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 <code>platform_android.c</code>.</p> +<h2 id="working-with-the-freedreno-community">Working with the Freedreno +community</h2> +<p>When working on any project (open-source or otherwise), it’s nice to +know that you aren’t working alone. Thankfully the +<code>#freedreno</code> channel on <code>irc.oftc.net</code> 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 <code>cpu_prep</code>, This function was just +there to call the DRM implementation of <code>cpu_prep</code> on the +buffer object. I wasn’t exactly sure how to implement this functionality +with KGSL since it doesn’t use DRM buffer objects.</p> +<p>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 <code>cpu_prep</code> 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).</p> +<h2 id="dealing-with-bugs-reverse-engineering-the-blob">Dealing with +bugs &amp; reverse engineering the blob</h2> +<p>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.</p> +<p>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 <code>fd</code> for the device could be used for +the buffer object in the <code>mmap</code> 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.</p> +<p>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 <code>iommu fault</code> 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 <code>fdl</code> (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.</p> +<p>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.</p> +<p>The libwrap library relied on a linux feature known as +<code>LD_PRELOAD</code> to load <code>libwrap.so</code> when the +application starts and replace the system functions like +<code>open</code> and <code>ioctl</code> with their own implementation +that traces what is being submitted to the KGSL kernel mode driver. +Thankfully android exposes this <code>LD_PRELOAD</code> mechanism +through its “wrap” interface where you create a propety called +<code>wrap.&lt;app-name&gt;</code> with a value +<code>LD_PRELOAD=&lt;path to libwrap.so&gt;</code>. 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 <a +href="https://gitlab.freedesktop.org/freedreno/freedreno/-/merge_requests/22">MR</a> +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.</p> +<p>With this is in hand one could begin investing what the blob driver +is doing to handle this unaligned surfaces.</p> +<h2 id="whats-next">What’s next?</h2> +<p>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 <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21570">WIP +MR</a>.</p> +<figure> +<img src="/assets/freedreno/3d-mark.png" +alt="Freedreno running 3d-mark" /> +<figcaption aria-hidden="true">Freedreno running 3d-mark</figcaption> +</figure> +</description><pubDate>Tue, 28 Feb 2023 00: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><p>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.</p> +<h2 id="radv-implement-vk.check_status">radv: Implement +vk.check_status</h2> +<p>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.</p> +<p>You can read more about Tony’s changes in the link below</p> +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22253">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22253</a></li> +</ul> +<h2 id="turnip-kgsl-backend-rewrite">turnip: KGSL backend rewrite</h2> +<p>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.</p> +<p>If you’re interested in taking a deeper dive into Mark’s changes, you +can read the following MR:</p> +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21651">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21651</a></li> +</ul> +<h2 id="turnip-a7xx-preparation-transition-to-c">turnip: a7xx +preparation, transition to C++</h2> +<p>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:</p> +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21931">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21931</a></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22148">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22148</a></li> +</ul> +<h2 id="v3dv3dv-various-fixes-cts-conformance">v3d/v3dv various fixes +&amp; CTS conformance</h2> +<p>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).</p> +<p>You can dive into some of their Raspberry Pi driver changes here:</p> +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22131">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22131</a></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21361">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21361</a></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20787">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20787</a></li> +</ul> +<h2 id="ci-build-system-and-cleanup">ci, build system, and cleanup</h2> +<p>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).</p> +<p>If you’re interested in seeing some of his work, check out some of +the MRs below:</p> +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22410">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22410</a></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21504">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21504</a></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21558">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21558</a></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20180">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20180</a></li> +</ul> +</description><pubDate>Wed, 10 May 2023 23: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><p>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:</p> +<pre><code>glm::mat3 mat3x3 = glm::mat3(mat4x4);</code></pre> +<p>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 +<code>(x, y, z)</code> looks something like this:</p> +<pre><code>[1 0 0 x] +[0 1 0 y] +[0 0 1 z] +[0 0 0 1]</code></pre> +<p>Then when we multiply this matrix by a vector like +<code>(a, b, c, 1)</code> the result is +<code>(a + x, b + y, c + z, 1)</code>. 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.</p> +<p>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:</p> +<pre><code>[1 0 0] +[0 1 0] +[0 0 1]</code></pre> +<p>See the problem now? The <code>(x, y, z)</code> 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?</p> +<p>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:</p> +<pre><code>[a b c d] +[e f g h] +[i j k l] +[m n o p]</code></pre> +<p>Then preserving the last row and column we should get a matrix like +this:</p> +<pre><code>[a b d] +[e f h] +[m n p]</code></pre> +<p>And if we use this conversion process for the same translation matrix +we will get:</p> +<pre><code>[1 0 x] +[0 1 y] +[0 0 1]</code></pre> +<p>Now we see that the <code>(x, y)</code> part of the translation is +preserved, and if we try to multiply this matrix by the vector +<code>(a, b, 1)</code> the result will be +<code>(a + x, b + y, 1)</code>. The translation is preserved in the +conversion!</p> +<h2 id="why-do-we-have-to-use-this-conversion">Why do we have to use +this conversion?</h2> +<p>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.</p> +<p>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 <strong>homogeneous coordinate system</strong>. 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!).</p> +<p>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!</p> +<p>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 <a +href="https://books.google.ca/books/about/Mathematics_for_Computer_Graphics_Applic.html?id=YmQy799flPkC&amp;redir_esc=y">“Mathematics +for Computer Graphics Applications”</a>. 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.)</p> +<p>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”.</p> +<p>Hopefully this explanation helps if you are every working on +converting 3D transformation code to 2D.</p> +</description><pubDate>Sun, 24 Sep 2023 23: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><figure> +<img src="/assets/vulkanised_2024/vulkanized_logo_web.jpg" +alt="Vulkanised sign at google’s office" /> +<figcaption aria-hidden="true">Vulkanised sign at google’s +office</figcaption> +</figure> +<p>Last week I had an exciting opportunity to attend the Vulkanised 2024 +conference. For those of you not familar with the event, it is <a +href="https://vulkan.org/events/vulkanised-2024">“The Premier Vulkan +Developer Conference”</a> 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.</p> +<h2 id="a-few-presentations">A Few Presentations</h2> +<p>My colleagues Iago, Stéphane, and Hyunjun each had the opportunity to +present on some of their work into the wider Vulkan ecosystem.</p> +<figure> +<img src="/assets/vulkanised_2024/vulkan_video_web.jpg" +alt="Stéphane and Hyujun presenting" /> +<figcaption aria-hidden="true">Stéphane and Hyujun +presenting</figcaption> +</figure> +<p>Stéphane &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. +<a +href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-stephane-cerveau-ko-igalia.pdf">Their +presentation is available on vulkan.org</a>.</p> +<figure> +<img src="/assets/vulkanised_2024/opensource_vulkan_web.jpg" +alt="Iago presenting" /> +<figcaption aria-hidden="true">Iago presenting</figcaption> +</figure> +<p>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 <a +href="https://vulkan.org/user/pages/09.events/vulkanised-2024/Vulkanised-2024-faith-ekstrand-collabora-Iago-toral-igalia.pdf">their +presentation for all the details</a>.</p> +<p>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.</p> +<h3 id="using-vulkan-synchronization-validation-effectively"><a +href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-john-zulauf-lunarg.pdf">Using +Vulkan Synchronization Validation Effectively</a></h3> +<p>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.</p> +<h3 id="years-of-teaching-vulkan-with-example-for-video-extensions"><a +href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-helmut-hlavacs.pdf">6 +Years of Teaching Vulkan with Example for Video Extensions</a></h3> +<p>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.</p> +<h3 id="vulkan-synchronization-made-easy"><a +href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-grigory-dzhavadyan.pdf">Vulkan +Synchronization Made Easy</a></h3> +<p>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.</p> +<h3 id="vulkan-video-encode-api-a-deep-dive"><a +href="https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-tony-zlatinski-nvidia.pdf">Vulkan +Video Encode API: A Deep Dive</a></h3> +<p>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) +:)</p> +<h2 id="thoughts-on-vulkanised">Thoughts on Vulkanised</h2> +<p>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.</p> +<p>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!</p> +<figure> +<img src="/assets/vulkanised_2024/food_web.jpg" +alt="Great bay area food" /> +<figcaption aria-hidden="true">Great bay area food</figcaption> +</figure> +</description><pubDate>Wed, 14 Feb 2024 00: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><p>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:</p> +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29344">llvmpipe: +Add android platform integration</a></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29785">u_gralloc/fallback: +Set fd from handle directly</a></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805">llvmpipe +&amp; lavalpipe: Implement sync fd import/export extensions</a></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28735">lavapipe: +Implement <code>VK_EXT_external_memory_dma_buf</code></a></li> +</ul> +<h2 id="setting-up-an-android-development-environment">Setting up an +Android development environment</h2> +<p>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.</p> +<p>Thankfully Google has good instructions for building and running +cuttlefish, which you can find <a +href="https://source.android.com/docs/devices/cuttlefish/get-started">here</a>. +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.</p> +<p>For building our own AOSP image, we can also follow the instructions +from Google <a +href="https://source.android.com/docs/setup/build/building">here</a>. +For the target we’ll want +<code>aosp_cf_x86_64_phone-trunk_staging-eng</code>. 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.</p> +<p>For running this custom-built image on Cuttlefish, you can just copy +all the <code>*.img</code> files from +<code>out/target/product/vsoc_x86_64/</code> 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.</p> +<h2 id="building-mesa-targeting-android">Building Mesa targeting +Android</h2> +<p>Working from the changes in MR <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29344">!29344</a> +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 +<code>dri</code> 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 <code>drisw</code> window system +integration.</p> +<p>To support Android in <code>drisw</code>, 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 <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/src/gallium/frontends/dri/drisw.c#L405"><code>drisw_allocate_textures</code></a> +and the underlying changes to llvmpipe to support importing dmabufs in +MR <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805">!27805</a>. +The EGL Android platform code also needed some changes to use the +<code>drisw</code> 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.</p> +<p>For lavapipe the changes were a lot simpler. The Android Vulkan +loader requires your driver to have <code>HAL_MODULE_INFO_SYM</code> +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 +<code>VK_ANDROID_native_buffer</code> 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.</p> +<p>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 <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/drivers/llvmpipe.rst">here</a> +and <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/android.rst">here</a>. +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 <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/android.rst?plain=1#L183">this</a> +section of the documentation I wrote, it covers how to do that.</p> +<p>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.</p> +<figure> +<img src="/assets/2024-06-27-android-swrast/lavapipe.png" +alt="Android running lavapipe" /> +<figcaption aria-hidden="true">Android running lavapipe</figcaption> +</figure> +<h2 id="references">References</h2> +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29344" +class="uri">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29344</a> +<ul> +<li>Main MR with Android changes</li> +</ul></li> +<li><a +href="https://source.android.com/docs/devices/cuttlefish/get-started" +class="uri">https://source.android.com/docs/devices/cuttlefish/get-started</a> +<ul> +<li>Google’s official guide for getting started with the Cuttlefish +emulator</li> +</ul></li> +<li><a href="https://source.android.com/docs/setup/build/building" +class="uri">https://source.android.com/docs/setup/build/building</a> +<ul> +<li>Google’s official guide for building AOSP images</li> +</ul></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/drivers/llvmpipe.rst" +class="uri">https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/drivers/llvmpipe.rst</a> +<ul> +<li>My updated documentation in MR for llvmpipe</li> +</ul></li> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/android.rst" +class="uri">https://gitlab.freedesktop.org/mesa/mesa/-/blob/9705df53408777d493eab19e5a58c432c1e75acb/docs/android.rst</a> +<ul> +<li>My updated documentation in MR for Android integration in mesa</li> +</ul></li> +</ul> +</description><pubDate>Wed, 26 Jun 2024 23: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><p>2024 has been an exciting year for the <a +href="https://www.igalia.com/technology/graphics">Igalia’s Graphics +Team</a>. We’ve been making a lot of progress on Turnip, AMD display +driver, the Raspberry Pi graphics stack, Vulkan video, and more.</p> +<h2 id="vulkan-device-generated-commands">Vulkan Device Generated +Commands</h2> +<p>Igalia’s Ricardo Garcia has been working hard on adding support for +the new <code>VK_EXT_device_generated_commands</code> extension in the +Vulkan Conformance Test Suite. He wrote an excellent blog post on the +extension and on his work that you can read <a +href="https://rg3.name/202409270942.html">here</a>. Ricardo also +presented the extension at XDC 2024 in Montréal, which he also <a +href="https://rg3.name/202411181555.html">blogged about</a>. Take a look +and see what generating Vulkan commands directly on the GPU looks +like!</p> +<h2 id="raspberry-pi-enhancements-performance-improvements">Raspberry Pi +Enhancements &amp; Performance Improvements</h2> +<p>Our very own Maíra Canal made a big contribution to improve the +graphics performance of Raspberry Pi 4 &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 <a +href="https://mairacanal.github.io/unleashing-power-enabling-super-pages-on-RPi/">here</a>.</p> +<p>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 <a +href="https://mairacanal.github.io/introducing-cpu-jobs-to-the-rpi/">here</a>.</p> +<p>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: - <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31575">MR +31575</a> - <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32277">MR +32277</a> - <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31751">MR +31751</a></p> +<p>The Raspberry Pi team here at Igalia presented all of their work at +XDC 2024 in Montréal. You can see a video below.</p> +<p><div class="youtube-video"><iframe src="https://www.youtube.com/embed/tlSFHkp6ODM"></iframe></div></p> +<h2 id="linux-kernel-6.8">Linux Kernel 6.8</h2> +<p>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 <a +href="https://mairacanal.github.io/introducing-cpu-jobs-to-the-rpi/">here</a>. +To highlight some of these contributions:</p> +<ul> +<li>AMD HDR &amp; Color Management +<ul> +<li>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.</li> +</ul></li> +<li>Async Flip +<ul> +<li>André Almeida implemented support for asynchronous page flip in the +atomic DRM modesetting API.</li> +</ul></li> +<li>V3D 7.1.x Kernel Driver +<ul> +<li>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.</li> +</ul></li> +<li>GPU stats for the Raspberry Pi 4/5 +<ul> +<li>José María “Chema” Casanova worked on adding GPU stats support to +the latest Raspberry Pi hardware.</li> +</ul></li> +</ul> +<h2 id="turnip-improvements">Turnip Improvements</h2> +<p>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 <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31401">here</a> +and <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29453">here</a>.</p> +<p>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 <code>fmulz</code> handling for +Direct3D 9. You can check out his changes <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31479">here</a> +and read more about them.</p> +<p>Danylo Piliaiev has been hard at work adding support for the latest +generation of Adreno GPUs. This included getting support for the <a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26934">A750 +working</a>, and then implementing performance improvements to bring it +up to parity with other Adreno GPUs in Turnip. All-together the turnip +team implemented a number of Vulkan extensions and performance +improvements such as:</p> +<ul> +<li>VK_KHR_shader_atomic_int64 - Amber +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27776">MR +27776</a></li> +</ul></li> +<li>VK_KHR_fragment_shading_rate - Danylo Piliaiev +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30905">MR +30905</a></li> +</ul></li> +<li>VK_KHR_8bit_storage - Žan Dobersek +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28254">MR +28254</a></li> +</ul></li> +<li>shaderInt8 feature - Žan Dobersek +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29875">MR +29875</a></li> +</ul></li> +<li>VK_KHR_shader_subgroup_rotate - Job Noorman +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31358">MR +31358</a></li> +</ul></li> +<li>VK_EXT_map_memory_placed - Dhruv Mark Collins +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28928">MR +28928</a></li> +</ul></li> +<li>VK_EXT_legacy_dithering - Karmjit Mahil +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30536">MR +30536</a></li> +</ul></li> +<li>VK_EXT_depth_clamp_zero_one - Danylo Piliaiev +<ul> +<li><a +href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29387">MR +29387</a></li> +</ul></li> +</ul> +<h2 id="display-next-hackfest-displaykms-meet-up">Display Next Hackfest +&amp; Display/KMS Meet-up</h2> +<p>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 <a +href="https://melissawen.github.io/blog/2024/09/25/reflections-2024-display-next-hackfest">here</a>.</p> +<figure> +<img +src="https://raw.githubusercontent.com/melissawen/melissawen.github.io/refs/heads/master/img/2024-ldnh/hackfest-room-0.jpg" +alt="Display Next Hackfest" /> +<figcaption aria-hidden="true">Display Next Hackfest</figcaption> +</figure> +<p>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 <a +href="https://melissawen.github.io/blog/2024/11/19/summary-display-kms-meeting-xdc2024">here</a>.</p> +<h2 id="amd-display-amdgpu">AMD Display &amp; AMDGPU</h2> +<p>Melissa Wen has also been hard at work improving AMDGPU’s display +driver. She made a number of changes including <a +href="https://lore.kernel.org/amd-gfx/ea31b795-5b75-40e6-846e-51dc6696f8bc@amd.com/#t">improving +display debug log</a> to include hardware color capabilities, <a +href="https://lore.kernel.org/amd-gfx/20240927230600.2619844-1-superm1@kernel.org/">Migrating +EDID handling to EDID common code</a> and various bug fixes such as:</p> +<ul> +<li>Fixing null-pointer dereference on edid reading +<ul> +<li><a +href="https://lore.kernel.org/amd-gfx/20240216122401.216860-1-mwen@igalia.com/">https://lore.kernel.org/amd-gfx/20240216122401.216860-1-mwen@igalia.com/</a></li> +</ul></li> +<li>Checking dc_link before dereferencing +<ul> +<li><a +href="https://lore.kernel.org/amd-gfx/20240227190828.444715-1-mwen@igalia.com/">https://lore.kernel.org/amd-gfx/20240227190828.444715-1-mwen@igalia.com/</a></li> +</ul></li> +<li>Using mpcc_count to log MPC state +<ul> +<li><a +href="https://lore.kernel.org/amd-gfx/20240412163928.118203-1-mwen@igalia.com/">https://lore.kernel.org/amd-gfx/20240412163928.118203-1-mwen@igalia.com/</a></li> +</ul></li> +<li>Fixing cursor offset on rotation 180 +<ul> +<li><a +href="https://lore.kernel.org/amd-gfx/20240807075546.831208-22-chiahsuan.chung@amd.com/">https://lore.kernel.org/amd-gfx/20240807075546.831208-22-chiahsuan.chung@amd.com/</a></li> +</ul></li> +<li>Fixes for kernel crashes since cursor overlay mode +<ul> +<li><a +href="https://lore.kernel.org/amd-gfx/20241217205029.39850-1-mwen@igalia.com/">https://lore.kernel.org/amd-gfx/20241217205029.39850-1-mwen@igalia.com/</a></li> +</ul></li> +</ul> +<p>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; DRM scheduler interactions were triggering. You can see the +code for some of changes below: - <a +href="https://lore.kernel.org/amd-gfx/20240906180639.12218-1-tursulin@igalia.com/">https://lore.kernel.org/amd-gfx/20240906180639.12218-1-tursulin@igalia.com/</a> +- <a +href="https://lore.kernel.org/amd-gfx/20241008150532.23661-1-tursulin@igalia.com/">https://lore.kernel.org/amd-gfx/20241008150532.23661-1-tursulin@igalia.com/</a> +- <a +href="https://lore.kernel.org/amd-gfx/20241227111938.22974-1-tursulin@igalia.com/">https://lore.kernel.org/amd-gfx/20241227111938.22974-1-tursulin@igalia.com/</a> +- <a +href="https://lore.kernel.org/amd-gfx/20240813135712.82611-1-tursulin@igalia.com/">https://lore.kernel.org/amd-gfx/20240813135712.82611-1-tursulin@igalia.com/</a> +- <a +href="https://lore.kernel.org/amd-gfx/20240712152855.45284-1-tursulin@igalia.com/">https://lore.kernel.org/amd-gfx/20240712152855.45284-1-tursulin@igalia.com/</a></p> +<h2 id="vulkan-opengl-extensions">Vulkan &amp; OpenGL Extensions</h2> +<ul> +<li><code>GL_EXT_texture_offset_non_const</code> +<ul> +<li>Ricardo was busy working on extending OpenGL by adding <a +href="https://github.com/KhronosGroup/GLSL/blob/main/extensions/ext/GL_EXT_texture_offset_non_const.txt">this</a> +extension to GLSL as well as providing an implementation for it in <a +href="https://github.com/KhronosGroup/glslang/pull/3782">glslang</a></li> +</ul></li> +<li><code>VK_KHR_video_encode_av1</code> &amp; +<code>VK_KHR_video_decode_av1</code> +<ul> +<li>Igalia is listed as a contributor to these extensions and worked +very hard to implement CTS support for the extensions.</li> +</ul></li> +</ul> +<h2 id="etnaviv-improvements">Etnaviv Improvements</h2> +<p>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 <a +href="https://christian-gmeiner.info/2024-04-12-hwdb/">here</a>. 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 <a +href="https://christian-gmeiner.info/2024-07-11-it-all-started-with-a-nop-part1/">here</a>. +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.</p> +<p><div class="youtube-video"><iframe src="https://www.youtube.com/embed/n_fn4evXeZo"></iframe></div></p> +<p>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 <a +href="https://christian-gmeiner.info/">Christian’s blog</a> to see any +of his future announcements.</p> +<h2 id="lavapipellvmpipe-android-chromeos">Lavapipe/LLVMpipe, Android +&amp; ChromeOS</h2> +<p>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 <a href="android_swrast">here</a>.</p> +<p>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 <a +href="https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1458">here</a> +and crosvm <a +href="https://gitlab.freedesktop.org/Hazematman/crosvm/-/commit/9ee86e72edfb3a652148dd233ffca75847949558">here</a>. +This work is still ongoing.</p> +<h2 id="whats-next">What’s Next?</h2> +<p>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 <a +href="https://www.vulkan.org/events/vulkanised-2025#agenda">Lavapipe at +Vulkanised 2025</a>, where Ricardo will also present about +Device-Generated Commands. Maíra &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!</p> +</description><pubDate>Fri, 20 Dec 2024 00:00:00 -0000</pubDate><guid>https://fryzekconcepts.com/notes/2024_igalia_graphics_team.html</guid></item></channel></rss>
\ No newline at end of file |