Graphics Hacking by Rosenzweig and Kristóf

-
Rosenzweig – The Apple GPU and the Impossible Bug
In late 2020, Apple debuted the M1 with Apple’s GPU architecture, AGX, rumoured to be derived from Imagination’s PowerVR series. Since then, we’ve been reverse-engineering AGX and building open source graphics drivers. Last January, I rendered a triangle with my own code, but there has since been a heinous bug lurking:
The driver fails to render large amounts of geometry.
Spinning a cube is fine, low polygon geometry is okay, but detailed models won’t render. Instead, the GPU renders only part of the model and then faults.
[...]
Traditional immediate mode renderers render directly into the framebuffer. They first run the vertex shader for each vertex of a triangle, then run the fragment shader for each pixel in the triangle. Per-vertex “varying” data is passed almost directly between the shaders, so immediate mode renderers are efficient for complex scenes.
There is a drawback: rendering directly into the framebuffer requires tremendous amounts of memory access to constantly write the results of the fragment shader and to read out back results when blending. Immediate mode renderers are suited to discrete, power-hungry desktop GPUs with dedicated video RAM.
-
How mesh shaders are implemented in the driver | Timur’s blog
In part 1 I gave a brief introduction on what mesh and task shaders are from the perspective of application developers. Now it’s time to dive deeper and talk about how mesh shaders are implemented in a Vulkan driver on AMD HW. Note that everything I discuss here is already available as public information in open source driver code. The goal of this blog post is to elaborate on how mesh shaders are implemented on the NGG hardware in AMD RDNA2 GPUs, and to show how these details affect shader performance. Hopefully, this helps the reader better understand how the concepts in the API are translated to the HW and what pitfalls to avoid to get good perf.
-
Timur Kristóf: How mesh shaders are implemented the driver
In part 1 I gave a brief introduction on what mesh and task shaders are from the perspective of application developers. Now it’s time to dive deeper and talk about how mesh shaders are implemented in a Vulkan driver on AMD HW. Note that everything I discuss here is already available as public information in open source driver code. The goal of this blog post is to elaborate on how mesh shaders are implemented on the NGG hardware in AMD RDNA2 GPUs, and to show how these details affect shader performance. Hopefully, this helps the reader better understand how the concepts in the API are translated to the HW and what pitfalls to avoid to get good perf.
-
- Login or register to post comments
Printer-friendly version
- 2446 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
- August 2022 (304)
- July 2022 (1160)
- June 2022 (1211)
- May 2022 (1127)
- April 2022 (1130)
- March 2022 (1232)
- February 2022 (1022)
- January 2022 (1178)
- December 2021 (1206)
- November 2021 (1140)
- October 2021 (1117)
- September 2021 (1132)
- August 2021 (1125)
- July 2021 (1129)
- June 2021 (1088)
- May 2021 (1123)
- April 2021 (1180)
- March 2021 (1220)
- February 2021 (1136)
- January 2021 (1088)
- December 2020 (1091)
- November 2020 (1042)
- October 2020 (1161)
- September 2020 (1124)
- August 2020 (1064)
- July 2020 (1162)
- June 2020 (1104)
- May 2020 (1203)
- April 2020 (1211)
- March 2020 (1184)
Recent comments
1 hour 4 min ago
1 hour 30 min ago
2 hours 1 min ago
2 hours 20 min ago
7 hours 59 min ago
8 hours 2 min ago
11 hours 32 min ago
1 day 2 hours ago
1 day 2 hours ago
1 day 2 hours ago