← Wszystkie wpisy

Apple Silicon TBDR: co naprawdę zyskują twórcy aplikacji

GPU z Apple silicon nie renderują tak jak inne GPU. Dokumentacja Metal firmy Apple opisuje architekturę po imieniu: „GPU w Apple silicon implementują technikę renderowania o nazwie tile-based deferred rendering (TBDR), która optymalizuje wydajność i efektywność energetyczną.”1 Kształt TBDR jest powodem, dla którego API Metal 4, stos ML działający na urządzeniu oraz model programistyczny imageblock-and-tile-shader istnieją w obecnej formie.

Poniższe sekcje omawiają cztery udokumentowane przez Apple funkcje, które TBDR umożliwia, oraz to, co każda z nich daje aplikacji: imageblocks, tile shaders, raster order groups oraz rozszerzoną implementację multisample antialiasing. Wcześniejszy wpis na temat podstaw Metal 4 omówił rdzeń API Metal 4; tutaj uwaga skupia się na podłożu GPU, do którego ten API jest skierowany.

TL;DR

  • TBDR dzieli cel renderowania na kafelki, uruchamia wiele z nich równolegle na osobnych rdzeniach GPU i odracza cieniowanie do momentu, aż cała geometria zostanie obliczona dla każdego kafelka.1
  • Tile memory ma przepustowość wielokrotnie szybszą niż pamięć urządzenia, opóźnienie wielokrotnie niższe oraz znacząco niższy koszt energetyczny.1
  • A11 i nowsze GPU Apple dodają imageblocks, tile shading, raster order groups oraz kontrolę pokrycia próbek imageblock. Aplikacje sięgają po nie wszystkie poprzez Metal.1
  • Imageblocks pozwalają aplikacji definiować niestandardowe struktury danych dla każdego piksela w tile memory, utrzymywać dane między rysowaniami i dyspozycjami oraz mieszać pracę renderującą z obliczeniową w jednym przebiegu.1
  • Raster order groups synchronizują wątki fragmentów, które trafiają w ten sam piksel, eliminując wyścig read-modify-write, który łamie blending zależny od kolejności.1

Czym właściwie jest TBDR

Sformułowanie Apple, dosłownie: „GPU dzieli cel renderowania na siatkę mniejszych regionów zwanych kafelkami. Przetwarza każdy kafelek za pomocą jednego ze swoich rdzeni GPU, często uruchamiając wiele jednocześnie. GPU odracza, czyli odkłada, fazę renderowania dla każdego kafelka do momentu po obliczeniu całej geometrii dla tego kafelka.”1

Kontrast z GPU działającymi w trybie immediate-mode (IM) to również ujęcie Apple: „GPU IM w pełni przetwarza prymitywy, takie jak linie i trójkąty, niezależnie od tego, czy są widoczne w renderowaniu.”1 TBDR unika tej pracy, gromadząc najpierw całą geometrię dla kafelka, a następnie cieniując tylko to, co przetrwa okluzję. Apple stwierdza wynik wprost: „GPU TBDR unika niepotrzebnej pracy, przetwarzając jednocześnie całą geometrię przebiegu renderowania i cieniując tylko widoczne prymitywy.”1

Tile memory jest nagrodą. Apple opisuje jego zalety w porównaniu z pamięcią urządzenia:1

  • „Przepustowość wielokrotnie szybsza niż pamięć urządzenia”
  • „Opóźnienie dostępu wielokrotnie niższe niż pamięć urządzenia”
  • „Zużycie energii znacząco niższe niż przy dostępie do pamięci urządzenia”

Dwa przebiegi renderowania mogą się także nakładać na sprzęcie. Apple zauważa: „Podczas gdy GPU uruchamia ostatnie etapy przebiegu renderowania do tile memory, może rozpocząć etap wierzchołkowy przyszłego przebiegu renderowania. GPU może wykorzystać więcej bloków sprzętowych jednocześnie, uruchamiając oba etapy równolegle, ponieważ zwykle używają one różnych komponentów obliczeniowych i pamięciowych.”1

To jest podłoże. Wszystko poniżej z niego korzysta.

Imageblocks: niestandardowe dane na piksel w tile memory

Definicja imageblock według Apple: „Imageblocks to kafelki ustrukturyzowanych danych obrazu przechowywane w pamięci lokalnej, pozwalające opisywać dane obrazu w tile memory, którymi GPU Apple mogą efektywnie manipulować.”1 Są to dwuwymiarowe struktury danych z szerokością, wysokością i głębią piksela, a „każdy piksel w imageblock może składać się z wielu komponentów, a każdy komponent można adresować jako jego własny wycinek obrazu.”1 Przykład Apple: imageblock zawierający trzy wycinki obrazu dla komponentów albedo, specular i normal.

Kształt udokumentowany przez Apple:1

  • Dostępne zarówno dla funkcji kernel, jak i fragment.
  • Utrzymują się przez cały okres życia kafelka, między rysowaniami i dyspozycjami.
  • Istniejący kod renderujący automatycznie tworzy imageblocks pasujące do formatów załączników renderowania.
  • Aplikacje mogą definiować niestandardowe imageblocks w shaderach z dodatkowymi kanałami, tablicami i zagnieżdżonymi strukturami.
  • Fragment shader widzi tylko dane imageblock w pozycji tego fragmentu; wątek funkcji obliczeniowej może uzyskać dostęp do całego imageblock.

Trwałość między rysowaniami i dyspozycjami jest częścią interesującą operacyjnie. Sformułowanie Apple: „Trwałość imageblock oznacza, że można mieszać operacje renderowania i obliczeniowe w jednym przebiegu renderowania za pomocą tile shaders, gdzie obie mogą uzyskać dostęp do tej samej pamięci lokalnej. Można tworzyć zaawansowane algorytmy, które pozostają w pamięci lokalnej GPU, utrzymując wiele operacji w obrębie kafelka.”1

Dla aplikacji wysyłającej wieloetapowy potok renderowania (deferred shading, efekty screen-space, niestandardowy blending) utrzymywanie pośrednich wyników w tile memory zamiast krążenia przez pamięć urządzenia stanowi budżet na klatkę, który zwraca TBDR.

Tile shaders: render i compute, ten sam przebieg

Sformułowanie Apple dotyczące tile shaders: „Tile shaders to funkcje compute lub fragment, które wykonują się jako część przebiegu renderowania. Pozwalają aplikacji obliczać i zapisywać dane do tile memory, która jest trwała na GPU między przebiegami renderowania.”1

Tradycyjny model GPU jest tym, co tile shaders omijają. Słowa Apple: „Tradycyjne GPU rozdzielają polecenia renderowania i obliczeniowe na odrębne przebiegi. Te przebiegi zazwyczaj nie mogą komunikować się ze sobą bezpośrednio. Aplikacje obchodzą to ograniczenie, zapisując wyniki z jednego przebiegu do pamięci urządzenia, a następnie ładując te dane z powrotem do następnego przebiegu. W niektórych scenariuszach, takich jak wielofazowy algorytm renderowania, aplikacje mogą wielokrotnie kopiować pośrednie dane do pamięci urządzenia.”1

Tile shaders przenoszą te pośrednie dane do tile memory. Udokumentowany zysk Apple: „Aplikacje korzystające z tile shaders mogą uniknąć przechowywania pośrednich wyników w pamięci urządzenia i zaoszczędzić czas, przechowując dane w szybszej tile memory.”1

Dla aplikacji Metal 4 tile shaders łączą się z ujednoliconym projektem MTL4ComputeCommandEncoder opisanym we wpisie o podstawach Metal 4. Ujednolicenie enkodera i model programistyczny tile-shader to ta sama decyzja architektoniczna odczytywana na dwóch warstwach: zwijanie granic render-vs-compute, które istnieją na tradycyjnych GPU, ponieważ sprzęt GPU Apple ich nie potrzebuje.

Raster order groups: porządkowanie współbieżnych wątków fragmentów

Problem, który raster order groups rozwiązują, słowami Apple: „Metal gwarantuje, że GPU miesza w kolejności wywołań rysowania, dając iluzję, że GPU renderuje scenę sekwencyjnie. … Fragment shadery dla każdego trójkąta uruchamiają się współbieżnie na własnym wątku. Fragment shader dla tylnego trójkąta może nie wykonać się przed fragment shaderem dla przedniego trójkąta, co może być problemem dla shadera, który potrzebuje wyników z shadera innego trójkąta dla swojej niestandardowej funkcji blendingu. Z powodu współbieżności ta sekwencja read-modify-write może utworzyć wyścig.”1

Mechanizm: „Raster order groups pokonują ten konflikt dostępu, synchronizując wątki, które trafiają w te same współrzędne pikseli i próbkę (jeśli aktywuje się cieniowanie per próbkę).”1

Powierzchnia implementacyjna: „Aby zaimplementować raster order groups, należy adnotować wskaźniki do pamięci kwalifikatorem atrybutu. Shadery, które uzyskują dostęp do pikseli przez te wskaźniki, idą w kolejności zgłoszenia per piksel. Sprzęt czeka, aż wszystkie starsze wątki fragment shadera, które nakładają się na bieżący wątek, zakończą się, zanim bieżący wątek przejdzie dalej.”1

Niedawne GPU Apple rozszerzają mechanizm. Słowa Apple: „Metal na niedawnych GPU Apple rozszerza raster order groups o dodatkowe możliwości. Pozwalają synchronizować poszczególne kanały imageblock i pamięci threadgroup. Można także tworzyć wiele grup porządkowych, co daje bardziej szczegółową synchronizację i minimalizuje, jak często wątki czekają na dostęp.”1

Praktyczny przykład Apple to deferred shading. Tradycyjne dwufazowe podejście zapisuje g-buffer wielu tekstur do pamięci urządzenia, a następnie odczytuje je z powrotem dla fazy oświetlenia. Sformułowanie Apple: „Można wyeliminować potrzebę pośrednich tekstur, używając wielu grup porządkowych do zlepienia obu faz renderowania w jedną. Aby to zrobić, należy utrzymywać bufor geometrii w fragmentach wielkości kafelka, aby mogły pozostać w lokalnej pamięci imageblock.”1

Podział, który Apple zaleca:1

  • Pierwsza grupa porządkowa: trzy pola g-buffer (albedo, normal, depth).
  • Druga grupa porządkowa: zakumulowany wynik oświetlenia.
  • „GPU Apple mogą porządkować obie grupy oddzielnie, tak aby zaległe zapisy do drugiej grupy nie blokowały odczytów z pierwszej grupy.”1

Dwa wątki nadal synchronizują się na końcu wykonania, aby zakumulować światła. Zysk polega na tym, że niekonfliktowe odczyty są wykonywane współbieżnie, a nie szeregowo.

MSAA, które śledzi unikalne próbki na piksel

Udokumentowana implementacja MSAA Apple na GPU A11+ różni się od opisu podręcznikowego. Sformułowanie Apple: „Sprzęt śledzi, czy każdy piksel zawiera krawędź prymitywu, dzięki czemu uruchamia blending per próbkę tylko wtedy, gdy jest to konieczne. Jeśli inny prymityw pokrywa próbki w obrębie piksela, GPU miesza tylko raz dla całego piksela.”1

Przykład Apple ilustruje optymalizację. Piksel pokryty przez dwie nakładające się krawędzie trójkątów ma trzy unikalne kolory na czterech pozycjach próbek. Słowa Apple: „GPU Apple sprzed A11 mieszają każdą z trzech pokrytych próbek piksela. Począwszy od A11, GPU Apple mieszają tylko dwa razy, ponieważ dwie próbki dzielą ten sam kolor.”1

Redukcja kolorów idzie dalej. Apple: „GPU Apple mogą zmniejszyć liczbę unikalnych kolorów w pikselu. Na przykład, jeśli GPU renderuje nieprzezroczysty trójkąt na wcześniejszych trójkątach, reprezentuje piksel jednym kolorem.”1

Aplikacje mogą rozszerzyć implementację za pomocą tile shaders. Udokumentowany przypadek użycia Apple: „Można zaimplementować niestandardowy algorytm resolve, modyfikując dane pokrycia próbek w tile shaders. Na przykład rozważmy złożoną scenę, która zawiera oddzielne fazy renderowania dla geometrii nieprzezroczystej i przezroczystej. Można dodać tile shader, który rozwiązuje dane próbek dla geometrii nieprzezroczystej przed mieszaniem geometrii przezroczystej.”1

Tile shader działa na danych w pamięci lokalnej i może być częścią fazy geometrii nieprzezroczystej, utrzymując resolve w tile memory zamiast krążenia przez osobny przebieg.

Co to oznacza dla architektury aplikacji

Trzy wnioski wynikające z udokumentowanej powierzchni Apple.

  1. Tile memory to budżet. Cztery powyższe funkcje (imageblocks, tile shaders, raster order groups, sample coverage) istnieją po to, aby utrzymywać pracę w tile memory, a nie w pamięci urządzenia. Udokumentowane liczby Apple: przepustowość wielokrotnie szybsza niż pamięć urządzenia, opóźnienie wielokrotnie niższe, energia znacząco niższa.1 Architektura aplikacji, która respektuje ten budżet, działa szybciej i chłodniej niż taka, która tego nie robi.

  2. Render i compute nie są różnymi światami. GPU Apple nie dzieli renderowania i obliczeń na odrębne przebiegi w sposób, w jaki robią to tradycyjne GPU. Trwałość imageblock i tile shaders pozwalają aplikacji uruchamiać wielofazowe algorytmy w obrębie pojedynczego przebiegu renderowania. Ujednolicony enkoder compute Metal 4 to wyrażenie na poziomie API tego samego faktu architektonicznego.

  3. Współbieżność jest domyślna; porządkowanie jest opcjonalne. Raster order groups są sposobem, w jaki aplikacja mówi „ta sekwencja read-modify-write zależy od kolejności.” Domyślną postacią jest nieuporządkowana współbieżność, która jest naturalnym kształtem GPU. Aplikacje, które potrzebują uporządkowanego dostępu dla blendingu, przezroczystości lub zapisów g-buffer, adnotują konkretne wskaźniki i pozwalają sprzętowi sekwencjonować wątki.

Pełny klaster Apple Ecosystem: rdzeń API Metal 4 dla równoległej powierzchni API skierowanej do tego sprzętu; LLM Foundation Models na urządzeniu dla frameworka uruchamiającego ML na tym samym krzemie; Core ML — wnioskowanie na urządzeniu dla szerszego stosu ML. Hub znajduje się pod adresem Apple Ecosystem Series.

FAQ

Czy TBDR jest specyficzne dla Metal 4?

Nie. GPU z Apple silicon implementują TBDR w wielu generacjach GPU; Metal 4 to nowa powierzchnia rdzenia API skierowana do nich. Funkcje TBDR udokumentowane tutaj (imageblocks, tile shaders, raster order groups, kontrola pokrycia próbek A11+) działają poprzez Metal zarówno dla oryginalnego API z prefiksem MTL, jak i dla typów Metal 4 z prefiksem MTL4.1

Jaka jest różnica między imageblock a pamięcią threadgroup?

Udokumentowane rozróżnienie Apple: „Pamięć threadgroup nadaje się do nieustrukturyzowanych danych, ale imageblock lepiej nadaje się do danych obrazu.”1 Imageblocks niosą ze sobą strukturę 2D z szerokością, wysokością, głębią piksela i nazwanymi komponentami per piksel; pamięć threadgroup to alokacja płaska. Aplikacje, które potrzebują ustrukturyzowanych danych obrazu z adresowalnymi wycinkami, używają imageblocks; aplikacje, które potrzebują buforów scratch dla kerneli obliczeniowych, używają pamięci threadgroup.

Dlaczego raster order groups istnieją, jeśli Metal już gwarantuje blending w kolejności wywołań rysowania?

Metal gwarantuje pozory sekwencyjnego blendingu, ale GPU uruchamia fragment shadery współbieżnie. Sformułowanie Apple: shader, który wykonuje własny niestandardowy blending na podstawie wyników innego trójkąta, wpada w wyścig, ponieważ dwa wątki nie są w rzeczywistości sekwencyjne. Raster order groups to mechanizm, który synchronizuje tylko wątki kierowane do tego samego piksela, pozostawiając resztę współbieżną.1

Kiedy należy napisać własny algorytm resolve MSAA?

Apple dokumentuje jeden konkretny przypadek: scena z oddzielnymi fazami dla geometrii nieprzezroczystej i przezroczystej, gdzie resolve uruchamia się po fazie nieprzezroczystej, ale przed mieszaniem przezroczystej.1 Dla większości aplikacji wbudowana implementacja MSAA sprzętu obsługuje tę pracę; niestandardowe resolve to narzędzie do konkretnych przypadków brzegowych, które opisuje dokumentacja Apple.

Jak optymalizacja MSAA Apple oszczędza pracę?

Sprzęt Apple śledzi liczbę unikalnych próbek na piksel podczas renderowania nowych prymitywów. Przykład Apple: piksel pokryty przez dwie krawędzie trójkątów ma trzy unikalne kolory na czterech pozycjach próbek; GPU A11+ mieszają dwa razy, a nie trzy, ponieważ dwie próbki dzielą kolor, a późniejszy nieprzezroczysty trójkąt redukuje piksel z powrotem do pojedynczego koloru.1 Optymalizacja działa na poziomie sprzętu; aplikacje otrzymują ją bez zmian w API.

Czy architektura GPU Apple jest udokumentowana gdziekolwiek poza stroną TBDR?

Temat „Apple silicon” w dokumentacji Metal Apple zawiera linki do strony TBDR, na której opiera się ten wpis. Sesje WWDC Apple poświęcone Metal również obejmują szczegóły architektury GPU, a Metal Shading Language Specification obejmuje powierzchnię na poziomie shadera. Apple nie opublikowało podstawowych szczegółów na poziomie krzemu (liczba klastrów, szerokość ALU, specyfika silnika rastra) dla danej generacji GPU Apple w dokumentacji deweloperskiej; wszelkie takie liczby znalezione poza developer.apple.com należy traktować jako niezweryfikowane.

Bibliografia


  1. Apple Developer, „Tailor your apps for Apple GPUs and tile-based deferred rendering”. Architektura TBDR, ulepszenia A11+ (imageblocks, tile shaders, raster order groups, kontrola pokrycia próbek imageblock), charakterystyka tile memory, praktyczny przykład deferred shading, optymalizacja MSAA. Pobrano 2026-05-04. 

Powiązane artykuły

Metal 4 Essentials: What The New Core API Actually Changes

Metal 4 ships parallel MTL4-prefixed types alongside Metal in iOS 26. Multi-threaded command encoding, unified compute, …

11 min czytania

What SwiftUI Is Made Of

SwiftUI is a result-builder DSL on top of a value-typed View tree. Once the substrate is visible, AnyView, Group, and Vi…

17 min czytania

The Cleanup Layer Is the Real AI Agent Market

Charlie Labs pivoted from building agents to cleaning up after them. The AI agent market is moving from generation to pr…

15 min czytania