Update my domain

Signed-off-by: Alyssa Rosenzweig <alyssa@rosenz.ca>

Author: alyssarosenzweig

content/about.md

@@ -59,7 +59,7 @@ Asahi Linux is a community, and everyone is invited to contribute. If you are in
 
 Current major contributors are:
 
-* [Alyssa Rosenzweig](https://rosenzweig.io/), the Asahi GPU lead. Alyssa is a Linux graphics hacker known for her work on reverse-engineering the Arm Mali GPUs to build the free Panfrost driver. She is an upstream Mesa3D developer today maintaining Asahi's OpenGL and Vulkan drivers.
+* [Alyssa Rosenzweig](https://alyssarosenzweig.ca/), the Asahi GPU lead. Alyssa is a Linux graphics hacker known for her work on reverse-engineering the Arm Mali GPUs to build the free Panfrost driver. She is an upstream Mesa3D developer today maintaining Asahi's OpenGL and Vulkan drivers.
 
 * [Dougall Johnson (dougallj)](https://github.com/dougallj), instruction set architecture extraordinaire. Dougall reverse-engineered much of the instruction set of the Apple GPU and has analyzed the timing of the Apple M1's CPU cores to infer microarchitectural details.
 

content/blog/2021/03/11-progress-report.md

@@ -283,7 +283,7 @@ And then, of course, there is the [GPU](https://en.wikipedia.org/wiki/Graphics_p
 
 We could keep talking in depth for another 10000 words, but alas, this post is already too long. However, if you'd like to check out more things that have been going on in the community in these two months, here’s a list of things you shouldn’t miss:
 
-* [Alyssa](https://rosenzweig.io/)'s work reverse engineering the M1 GPU ([part 1](https://rosenzweig.io/blog/asahi-gpu-part-1.html), [part 2](https://rosenzweig.io/blog/asahi-gpu-part-2.html))
+* [Alyssa](https://alyssarosenzweig.ca/)'s work reverse engineering the M1 GPU ([part 1](https://alyssarosenzweig.ca/blog/asahi-gpu-part-1.html), [part 2](https://alyssarosenzweig.ca/blog/asahi-gpu-part-2.html))
 * [Dougall](https://twitter.com/dougallj)'s [GPU ISA docs](https://dougallj.github.io/applegpu/docs.html), [CPU microarchitecture docs](https://dougallj.github.io/applecpu/firestorm.html), and [AMX instruction set docs](https://gist.github.com/dougallj/7a75a3be1ec69ca550e7c36dc75e0d6f)
 * [Iris](https://twitter.com/modwizcode)' work [bringing M1 support to QEMU](https://twitter.com/modwizcode/status/1360308258519605254)
 * Mark's work porting [U-Boot](https://github.com/kettenis/u-boot/commits/apple-m1) and [OpenBSD](https://marc.info/?l=openbsd-arm&m=161386122115249&w=2) to the M1. He even has PCIe support already!

content/blog/2021/08/14-progress-report.md

@@ -42,7 +42,7 @@ On top of the hypervisor, we've built a flexible hardware I/O tracing framework
 
 One of the biggest challenges for Asahi Linux is making the M1's GPU work. But what most people think of as a "GPU" is actually two completely distinct pieces of hardware: the GPU proper, which is in charge of rendering frames in memory, and the display controller, which is in charge of sending those rendered frames from memory to the display.
 
-While Alyssa has been hard at work [reverse engineering](https://rosenzweig.io/blog/asahi-gpu-part-4.html) the userspace components of the GPU, from draw calls to shaders, we still haven't looked at the lowest levels of the hardware that handle memory management and submission of commands to the GPU. But before we can use the GPU to render anything, we need a way to put it on the screen! Up until now, we've been using the firmware-provided framebuffer, which is just an area of memory where we can write pixels to be shown on the screen, but this won't cut it for a real desktop. We need features such as displaying new frames without tearing, support for hardware sprites such as the mouse cursor, switching resolutions and configuring multiple outputs, and more. This is the job of the display controller.
+While Alyssa has been hard at work [reverse engineering](https://alyssarosenzweig.ca/blog/asahi-gpu-part-4.html) the userspace components of the GPU, from draw calls to shaders, we still haven't looked at the lowest levels of the hardware that handle memory management and submission of commands to the GPU. But before we can use the GPU to render anything, we need a way to put it on the screen! Up until now, we've been using the firmware-provided framebuffer, which is just an area of memory where we can write pixels to be shown on the screen, but this won't cut it for a real desktop. We need features such as displaying new frames without tearing, support for hardware sprites such as the mouse cursor, switching resolutions and configuring multiple outputs, and more. This is the job of the display controller.
 
 On most mobile SoCs, the display controller is just a piece of hardware with simple registers. While this is true on the M1 as well, Apple decided to give it a twist. They added a coprocessor to the display engine (called DCP), which runs its own firmware (initialized by the system bootloader), and moved most of the display driver into the coprocessor. But instead of doing it at a natural driver boundary... they took half of their macOS C++ driver, moved it into the DCP, and created a remote procedure call interface so that each half can call methods on C++ objects on the other CPU! Talk about overcomplicating things...
 

content/blog/2022/11/29-gpu-story.md

@@ -31,11 +31,11 @@ That means that in order to make the M1 GPU work with Asahi Linux, we need two b
 
 ## Alyssa joins the project
 
-All the way back in 2021 when Asahi Linux started, Alyssa Rosenzweig joined the project to start working on reverse engineering the M1 GPU. Together with [Dougall Johnson](https://mastodon.social/@dougall) (who focused on documenting the GPU shader architecture), she started reverse engineering all the user space bits, including the shaders and all the command list structures needed to set up rendering. That's a ton of work, but less than one month in she was [already drawing her first triangle](https://rosenzweig.io/blog/asahi-gpu-part-2.html)! She's amazing! If you haven't checked out her series on dissecting the M1 GPU you should visit her [website](https://rosenzweig.io/) and take a look! ✨✨
+All the way back in 2021 when Asahi Linux started, Alyssa Rosenzweig joined the project to start working on reverse engineering the M1 GPU. Together with [Dougall Johnson](https://mastodon.social/@dougall) (who focused on documenting the GPU shader architecture), she started reverse engineering all the user space bits, including the shaders and all the command list structures needed to set up rendering. That's a ton of work, but less than one month in she was [already drawing her first triangle](https://alyssarosenzweig.ca/blog/asahi-gpu-part-2.html)! She's amazing! If you haven't checked out her series on dissecting the M1 GPU you should visit her [website](https://alyssarosenzweig.ca/) and take a look! ✨✨
 
-But wait, how can she work on the user space driver without a kernel driver to go with it? Easy, she did it on macOS! Alyssa reverse engineered the macOS GPU driver UAPI enough to allocate memory and submit her own commands to the GPU, and this way she could work on the user space part without having to worry about the kernel bit. That's super cool! She started writing an M1 GPU OpenGL driver for [Mesa](https://www.mesa3d.org/), the Linux userspace graphics stack, and just a few months later she was already [passing 75% of the OpenGL ES 2 conformance tests](https://rosenzweig.io/blog/asahi-gpu-part-4.html), all on macOS!
+But wait, how can she work on the user space driver without a kernel driver to go with it? Easy, she did it on macOS! Alyssa reverse engineered the macOS GPU driver UAPI enough to allocate memory and submit her own commands to the GPU, and this way she could work on the user space part without having to worry about the kernel bit. That's super cool! She started writing an M1 GPU OpenGL driver for [Mesa](https://www.mesa3d.org/), the Linux userspace graphics stack, and just a few months later she was already [passing 75% of the OpenGL ES 2 conformance tests](https://alyssarosenzweig.ca/blog/asahi-gpu-part-4.html), all on macOS!
 
-Earlier this year, her work was so far ahead that she was running [games](https://rosenzweig.io/blog/asahi-gpu-part-6.html) on a fully open source Mesa OpenGL stack, running on top of Apple's kernel driver on macOS! But there was still no Linux kernel driver... time to help out with that part! ✨
+Earlier this year, her work was so far ahead that she was running [games](https://alyssarosenzweig.ca/blog/asahi-gpu-part-6.html) on a fully open source Mesa OpenGL stack, running on top of Apple's kernel driver on macOS! But there was still no Linux kernel driver... time to help out with that part! ✨
 
 ## The Mysterious GPU Firmware
 
@@ -51,7 +51,7 @@ Just like other parts of the M1 chip, the GPU has a coprocessor called an "ASC"
 * **Event messages**, which the firmware sends back to the driver when something happens (like a command completing or failing).
 * **Statistics**, **firmware logs**, and **tracing messages** used for GPU status information and debugging.
 * **Command queues**, which represent a single app's list of pending GPU work
-* **Buffer information**, **statistics**, and **page list structures**, used to manage the [Tiled Vertex Buffers](https://rosenzweig.io/blog/asahi-gpu-part-5.html).
+* **Buffer information**, **statistics**, and **page list structures**, used to manage the [Tiled Vertex Buffers](https://alyssarosenzweig.ca/blog/asahi-gpu-part-5.html).
 * **Context structures** and other bits that let the GPU firmware keep track of what is going on.
 * **Vertex rendering commands**, which tell the vertex processing and tiling part of the GPU how to process commands and shaders from userspace to run the vertex part of a whole render pass.
 * **Fragment rendering commands**, which tell the rasterization and fragment processing part of the GPU how to render the tiled vertex data from the vertex processing into an actual framebuffer.

content/blog/2023/03/20-road-to-vulkan.md

@@ -12,7 +12,7 @@ As you probably know, I've been working together with the rest of the Asahi Linu
 
 Today we're releasing a big update to our GPU drivers for Asahi Linux, so I wanted to talk to you about what we've been working on since then, and what's next!
 
-If this is your first time reading about our GPU adventures, you might want to check out my [Tales of the M1 GPU](/2022/11/tales-of-the-m1-gpu/) article first, which covers what I worked on last year! Also don't miss Alyssa's amazing series of articles on [her website](https://rosenzweig.io/), which goes all the way back to January 2021! ^^
+If this is your first time reading about our GPU adventures, you might want to check out my [Tales of the M1 GPU](/2022/11/tales-of-the-m1-gpu/) article first, which covers what I worked on last year! Also don't miss Alyssa's amazing series of articles on [her website](https://alyssarosenzweig.ca/), which goes all the way back to January 2021! ^^
 
 And if this is too long, feel free to [jump to the end](#conclusions) to learn what this all means for Asahi Linux!
 

content/blog/2024/01/11-fedora-asahi-new.md

@@ -28,7 +28,7 @@ The only platform not yet supported is the Mac Pro, although there probably isn'
 
 ## GPU - Conformant OpenGL ES 3.1 & more...
 
-Over the summer of 2023, [Alyssa Rosenzweig](https://rosenzweig.io)'s GPU reverse-engineering work [leapfrogged](https://rosenzweig.io/blog/opengl3-on-asahi-linux.html) us from OpenGL 2.1 over OpenGL 3.0 up to OpenGL 3.1; similarly, the OpenGL ES 2.0 support bumped up to OpenGL ES 3.0. Just two months later, in August 2023, we shipped [conformant](https://rosenzweig.io/blog/first-conformant-m1-gpu-driver.html) OpenGL ES 3.1 drivers, the world’s only conformant OpenGL ES 3.1 implementation for M1- and M2-family graphics hardware.
+Over the summer of 2023, [Alyssa Rosenzweig](https://alyssarosenzweig.ca)'s GPU reverse-engineering work [leapfrogged](https://alyssarosenzweig.ca/blog/opengl3-on-asahi-linux.html) us from OpenGL 2.1 over OpenGL 3.0 up to OpenGL 3.1; similarly, the OpenGL ES 2.0 support bumped up to OpenGL ES 3.0. Just two months later, in August 2023, we shipped [conformant](https://alyssarosenzweig.ca/blog/first-conformant-m1-gpu-driver.html) OpenGL ES 3.1 drivers, the world’s only conformant OpenGL ES 3.1 implementation for M1- and M2-family graphics hardware.
 
 What's the next step? Geometry shaders are introduced in OpenGL 3.2 and OpenGL ES 3.2. A [geometry shader](https://learnopengl.com/Advanced-OpenGL/Geometry-Shader) takes as input a set of vertices that form a single primitive e.g. a point or a triangle, which then transform these vertices as it sees fit before sending them to the next shader stage. What makes the geometry shader interesting is that it is able to convert the original primitive (set of vertices) to completely different primitives, possibly generating more vertices than were initially given. In the latest Fedora release, you’ll find a newer version, OpenGL 3.3. 3.2 and 3.3 add big ticket features like geometry shaders. Since Geometry shaders are not natively supported by the Apple GPU, correctly implementing them requires driver gymnastics. This is magnified by the interactions of geometry shaders with other features like transform feedback, primitive restart, indirect draws, and tessellation. We care about correctness, a promise included with conformance. It’s paramount to implement them the correct way -- which is not the easy way.
 

content/blog/2024/10/10-aaa-gaming-on-m1.md

@@ -53,7 +53,7 @@ virtual machine is 4K, and you're happy because you can play [**Fallout
 
 The final piece is an adult-level Vulkan driver, since translating DirectX requires Vulkan 1.3
 with many extensions. Back in April, I wrote
-[Honeykrisp](https://rosenzweig.io/blog/vk13-on-the-m1-in-1-month.html), the
+[Honeykrisp](https://alyssarosenzweig.ca/blog/vk13-on-the-m1-in-1-month.html), the
 only Vulkan 1.3 driver for Apple hardware. I've since added DXVK support. Let's look at some new features.
 
 ### Tessellation
@@ -81,7 +81,7 @@ just fast enough for games like
 without crashing the hardware. In OpenGL and Vulkan, out-of-bounds loads may
 return arbitrary elements, and out-of-bounds stores may corrupt the buffer.
 Our OpenGL driver [exploits this
-definition](https://rosenzweig.io/blog/conformant-gl46-on-the-m1.html) for
+definition](https://alyssarosenzweig.ca/blog/conformant-gl46-on-the-m1.html) for
 efficient robustness on the M1.
 
 Some games require stronger guarantees.  In DirectX, out-of-bounds loads return zero, and
@@ -143,7 +143,7 @@ enough to enjoy [**Portal 2**](https://store.steampowered.com/app/620/Portal_2/)
 
 This work has been years in the making with major contributions from...
 
-* [Alyssa Rosenzweig](https://rosenzweig.io)
+* [Alyssa Rosenzweig](https://alyssarosenzweig.ca)
 * [Asahi Lina](https://lina.yt/me)
 * [chaos_princess](https://social.treehouse.systems/@chaos_princess)
 * [Davide Cavalca](https://github.com/davide125)

content/blog/2025/02/12-passing-the-torch.md

@@ -15,7 +15,7 @@ opportunity to build sustainable project governance. No matter how talented an
 individual, a large project cannot rest on a single person's shoulders. So
 instead of one replacement... we have seven:
 
-* [**Alyssa Rosenzweig**](https://rosenzweig.io), graphics dev.
+* [**Alyssa Rosenzweig**](https://alyssarosenzweig.ca), graphics dev.
 * [**chaos_princess**](https://social.treehouse.systems/@chaos_princess), kernel dev.
 * [**Davide Cavalca**](https://github.com/davide125), Fedora dev.
 * [**Neal Gompa**](https://royalgeekworld.com/), Fedora dev.

content/governance.md

@@ -12,7 +12,7 @@ To support that code, we need infrastructure and funding, to run servers and sup
 
 There are seven board members, aside from temporary vacancies. The current members are:
 
-* [Alyssa Rosenzweig](https://rosenzweig.io) (treasurer). <alyssa@asahilinux.org>
+* [Alyssa Rosenzweig](https://alyssarosenzweig.ca) (treasurer). <alyssa@asahilinux.org>
 * [Davide Cavalca](https://github.com/davide125) (administrator). <davide@asahilinux.org>
 * [Neal Gompa](https://royalgeekworld.com/) (secretary, treasurer). <neal@asahilinux.org>
 * [James Calligeros](https://social.treehouse.systems/@chadmed). <james@asahilinux.org>