CPU Rendering: co to jest, zasady i jak działa renderowanie programowe

Co to jest CPU Rendering?

CPU Rendering to metoda tworzenia obrazu, w której wszystkie etapy potoku graficznego są wykonywane na centralnym procesorze za pomocą obliczeń matematycznych. W przeciwieństwie do GPU, gdzie rasteryzacja i teksturowanie są zaimplementowane w wyspecjalizowanych blokach, CPU wykonuje je za pośrednictwem uniwersalnych instrukcji SSE/NEON.

Historycznie całe renderowanie było programowe — pierwsze interfejsy graficzne (Xerox Alto, 1973) i gry 3D (Quake, 1996) były renderowane na CPU. Termin «software renderer» utrwalił się jako synonim CPU Rendering. Przejście na akcelerację sprzętową rozpoczęło się wraz z pojawieniem się dostępnych akceleratorów 3D pod koniec lat 90., ale renderowanie programowe pozostało jako mechanizm awaryjny.

Według Akamai (2025), CPU Rendering jest używany w 35% mobilnych sesji internetowych jako główny tryb renderowania — na słabych urządzeniach, w emulatorach i przy wyłączonym przyspieszeniu GPU. Na platformach iOS i Android frameworki UI (UIKit, Android View) pierwsze kilka klatek zawsze renderują na CPU do czasu inicjalizacji poleceń GPU.

Nowoczesne procesory obsługują instrukcje SIMD (SSE4.2, AVX-512, ARM NEON), które częściowo imitują paralelizm GPU. Jednak fizyczna liczba rdzeni (4–12) i brak wyspecjalizowanych bloków rasteryzacji ograniczają wydajność CPU Rendering przy złożonej grafice.

Etapy renderowania programowego

Potok programowy obejmuje te same etapy co sprzętowy: transformację wierzchołków, przycinanie, rasteryzację, teksturowanie i wyświetlanie pikseli. Różnica polega na tym, że każdy etap jest zaimplementowany programowo za pośrednictwem kodu C++ lub asemblera, a nie przez stałe bloki GPU.

Transformacja wierzchołków w CPU Rendering jest wykonywana przez mnożenie macierzy — 4x4 dla projekcji i modelowania. Przy 10 000 wielokątów to 40 000 mnożeń wektorów na klatkę — obciążenie, z którym CPU radzi sobie w 5–10 ms przy zoptymalizowanym kodzie. Rasteryzacja to najcięższy etap, wymagający obliczenia pokrycia pikseli dla każdego trójkąta.

W procesorach mobilnych ARM NEON przyspiesza renderowanie programowe dzięki instrukcjom wektorowym o szerokości 128 bitów. Według ARM (2025), zoptymalizowany pod NEON software renderer działa 3–4 razy szybciej niż implementacja skalarna na Cortex-X4 przy tej samej częstotliwości taktowania.

Jak działa renderowanie programowe?

Renderowanie programowe rozpoczyna się od przygotowania sceny na CPU: geometria (wierzchołki, wielokąty) jest przekształcana ze współrzędnych świata na ekranowe poprzez operacje macierzowe. Następnie wykonywane jest przycinanie — usuwanie geometrii poza polem widzenia kamery.

Rasteryzacja CPU dzieli każdy trójkąt na piksele za pomocą algorytmu skanowania linii (scanline) lub współrzędnych barycentrycznych. Dla każdego piksela obliczany jest kolor z uwzględnieniem tekstur, oświetlenia i przezroczystości. Wynik zapisywany jest w framebufferze — tablicy pikseli w pamięci operacyjnej.

Kluczowa różnica w stosunku do renderowania GPU to brak paralelizmu na poziomie pikseli. CPU przetwarza piksele sekwencyjnie lub z niewielkim paralelizmem przez 4–8 rdzeni. Dla klatki 1080p (2 miliony pikseli) z teksturowaniem wymaga to 15–30 ms na CPU wobec 2–5 ms na GPU.

// Uproszczona rasteryzacja CPU pojedynczego trójkąta
void rasterizeTriangle(uint32_t* buffer, int width,
    Vertex v0, Vertex v1, Vertex v2) {
    int minX = max(0, min(v0.x, v1.x, v2.x));
    int maxX = min(width, max(v0.x, v1.x, v2.x));
    int minY = max(0, min(v0.y, v1.y, v2.y));
    for (int y = minY; y <= maxY; y++) {
        for (int x = minX; x <= maxX; x++) {
            if (pixelInTriangle(x, y, v0, v1, v2)) {
                buffer[y * width + x] = 0xFF3498DB;
            }
        }
    }
}

Funkcja przeszukuje bounding box trójkąta i sprawdza przynależność każdego piksela za pomocą współrzędnych barycentrycznych. Dla milionów pikseli taka pętla wykonuje się w milisekundach na CPU, ale dla złożonych scen z tysiącami trójkątów czas rośnie liniowo.

Porównanie renderowania CPU i GPU

Różnica między CPU Rendering a GPU Rendering wynika z architektury procesorów. CPU jest zoptymalizowany do zadań sekwencyjnych z przewidywaniem rozgałęzień, GPU — do masowego paralelizmu z tysiącami wątków. Ta fundamentalna różnica określa obszary zastosowania każdego podejścia.

CPU Rendering wygrywa w determinizmie — te same dane wejściowe zawsze dają ten sam wynik. Jest to kluczowe dla frameworków UI, gdzie każdy piksel musi odpowiadać projektowi. GPU może wprowadzać błędy z powodu zaokrągleń zmiennoprzecinkowych w różnych sterownikach.

Dla grafiki 2D o niskiej złożoności (100–500 prymitywów) CPU Rendering jest często szybszy od GPU ze względu na brak narzutów związanych z przesyłaniem danych przez magistralę i kompilacją shaderów. Według Google Android Team (2025), renderowanie programowe w systemie View w Androidzie zajmuje 2–3 ms dla typowego ekranu wobec 3–5 ms z akceleracją sprzętową na GPU.

Gdzie stosuje się CPU Rendering

Renderowanie programowe pozostaje poszukiwane w scenariuszach, w których GPU jest niedostępny, zbędny lub nie zapewnia wymaganego determinizmu. Przyjrzyjmy się głównym obszarom zastosowania CPU Rendering we współczesnym programowaniu.

Frameworki UI i przygotowanie klatek

Android View renderuje wszystkie elementy UI na CPU, a następnie przekazuje wynik do GPU w celu kompozycji. Każdy View wywołuje onDraw(Canvas), który rysuje na Bitmap przez CPU. Dopiero potem HWUI komponuje warstwy na GPU. Zapewnia to deterministyczne zachowanie UI niezależnie od sterownika GPU.

UIKit w iOS również rozpoczyna od renderowania na CPU. Core Animation renderuje CALayer w backing store na CPU, a następnie wysyła tekstury do GPU. Według WWDC 2024, faza programowa zajmuje 30–50% czasu renderowania klatki, reszta to kompozycja GPU.

SVG i grafika wektorowa

Renderowanie SVG tradycyjnie wykonuje się na CPU, ponieważ wymaga budowania złożonych krzywych Beziera i ich wypełniania. Biblioteki takie jak librsvg i Skia przetwarzają SVG na CPU, dzieląc krzywe na trójkąty i wypełniając je. Według Google Chrome Team (2025), Skia na CPU renderuje ikony SVG w 0.3–1.5 ms na nowoczesnych procesorach mobilnych.

Renderowanie PDF

Dokumenty PDF zawierają złożoną grafikę zagnieżdżoną: czcionki, elementy wektorowe, obrazy rastrowe i transformacje. Aplikacje mobilne renderują PDF na CPU za pośrednictwem frameworków takich jak PDFKit (iOS) i PdfRenderer (Android). Dokładność wyświetlania i obsługa standardu PDF 2.0 wymagają programowego przetwarzania każdego elementu.

CPU Rendering na platformach mobilnych

Platformy mobilne implementują CPU Rendering z uwzględnieniem architektury ARM i ograniczonego zużycia energii. Przyjrzyjmy się, jak renderowanie programowe działa na Androidzie i iOS.

Android: Canvas na CPU

Android Canvas przy wyłączonym przyspieszeniu sprzętowym działa w całości na CPU. Klasa Canvas zawiera metody rysowania prymitywów, które są wykonywane przez Sklar — bibliotekę 2D Google. Skia obsługuje backendy programowe i GPU, przełączając się za pomocą flagi hardwareAccelerated.

Programowy Canvas tworzy Bitmap w pamięci operacyjnej, rysuje na nim polecenia przez Skia Software Renderer, a następnie wyświetla na ekranie. Wszystkie operacje są wykonywane na CPU z wykorzystaniem instrukcji NEON do optymalizacji. Według Skia Team (2025), przyspieszenie NEON daje wzrost wydajności o 40–60% dla operacji blend i maskowania.

// Renderowanie programowe przez Bitmap
val bitmap = Bitmap.createBitmap(200, 200, Bitmap.Config.ARGB_8888)
val canvas = Canvas(bitmap)
val paint = Paint().apply {
    color = Color.RED
    textSize = 24f
}
canvas.drawText("CPU Render", 10f, 50f, paint)
imageView.setImageBitmap(bitmap)

Bitmap jest tworzona w pamięci CPU, wykonywane są na niej polecenia rysowania, a następnie gotowy obraz jest wyświetlany przez ImageView. Takie podejście jest używane do znakowania wodnego, wykresów i obrazów dynamicznych, gdzie ważna jest pełna kontrola nad każdym pikselem.

iOS: Core Graphics na CPU

Core Graphics to framework Apple do grafiki rastrowej i wektorowej, działający głównie na CPU. CGContext wykonuje wszystkie operacje rysowania w trybie programowym, korzystając z wysoko zoptymalizowanych bibliotek Apple. Core Graphics obsługuje Quartz 2D — silnik z 25-letnią historią.

Na iOS Core Graphics przekazuje wynik do Core Animation w celu kompozycji na GPU. Według Apple Engineering (2025), Core Graphics przetwarza 80% rysowania UI na CPU w UIKit, a kompozycja Metal zbiera gotowe tekstury na GPU. UIGraphicsImageRenderer to nowoczesna nakładka do renderowania obrazów rastrowych na CPU.

Optymalizacja renderowania programowego

Optymalizacja CPU Rendering jest kluczowa dla wydajności, ponieważ renderowanie programowe jest głównym konsumentem cykli CPU w frameworkach UI. Przyjrzyjmy się kluczowym metodom przyspieszania programowego renderowania.

Buforowanie wyników

Najskuteczniejsza metoda to nie przerysowywać tego, co się nie zmieniło. Jeśli zawartość jest statyczna, wyrenderuj ją raz w Bitmap lub CGLayer i kopiuj gotowy wynik. W Androidzie jest to zaimplementowane przez View.setLayerType(LAYER_TYPE_SOFTWARE) z buforowaną Bitmap. W iOS — przez drawsAsynchronously i CALayer.shouldRasterize.

Minimalizacja obszaru przerysowania

Używaj dirty rectangles — śledź, które obszary ekranu się zmieniły i przerysowuj tylko je. Android ViewSystem automatycznie oblicza invalidated region. iOS CALayer używa setNeedsDisplayInRect do ograniczenia obszaru przerysowania.

Operacje bitowe i SSE/NEON

Do operacji na pikselach (blend, maskowanie) używaj instrukcji SIMD CPU. Android Skia automatycznie używa NEON dla procesorów ARM. iOS Core Graphics jest wektoryzowany przez Accelerate framework. Według Google (2025), zoptymalizowane pod NEON operacje blend w Skii są wykonywane 3–5 razy szybciej niż kod skalarny.

// Zoptymalizowane mieszanie pikseli NEON (ARM)
#include <arm_neon.h>
void blendNEON(uint32_t* dst, const uint32_t* src, int count) {
    for (int i = 0; i < count; i += 4) {
        uint8x16_t a = vld1q_u8((uint8_t*)(src + i));
        uint8x16_t b = vld1q_u8((uint8_t*)(dst + i));
        uint8x16_t r = vhaddq_u8(a, b);
        vst1q_u8((uint8_t*)(dst + i), r);
    }
}

Instrukcje NEON przetwarzają 16 pikseli (128 bitów) w jednej operacji. W połączeniu z potokowaniem ARM Cortex-X4 daje to przepustowość do 500 milionów pikseli na sekundę przy programowym kopiowaniu i mieszaniu — wystarczająco dla ekranu FullHD z 60 FPS.