CPU Rendering: ce este, principii și cum funcționează randarea software

Ce este CPU Rendering?

CPU Rendering — o metodă de formare a imaginii în care toate etapele pipeline-ului grafic sunt executate pe procesorul central prin calcule matematice. Spre deosebire de GPU, unde rasterizarea și texturarea sunt încorporate în blocuri specializate, CPU le execută prin instrucțiuni universale SSE/NEON.

Istoric, întregul rendering era software — primele interfețe grafice (Xerox Alto, 1973) și jocurile 3D (Quake, 1996) erau randate pe CPU. Termenul «software renderer» s-a consolidat ca sinonim pentru CPU Rendering. Tranziția la accelerarea hardware a început odată cu apariția acceleratoarelor 3D accesibile la sfârșitul anilor 1990, dar randarea software a rămas ca mecanism de fallback.

Conform Akamai (2025), CPU Rendering este utilizat în 35% din sesiunile web mobile ca mod principal de randare — pe dispozitive slabe, în emulatoare și când accelerarea GPU este dezactivată. Pe platformele iOS și Android, framework-urile UI (UIKit, Android View) randaează primele câteva cadre întotdeauna pe CPU până la inițializarea comenzilor GPU.

Procesoarele moderne suportă instrucțiuni SIMD (SSE4.2, AVX-512, ARM NEON), care imită parțial paralelismul GPU. Cu toate acestea, numărul fizic de nuclee (4–12) și absența blocurilor specializate de rasterizare limitează performanța CPU Rendering la grafică complexă.

Etapele randării software

Pipeline-ul software include aceleași etape ca și cel hardware: transformarea vertexurilor, tăierea, rasterizarea, texturarea și afișarea pixelilor. Diferența constă în faptul că fiecare etapă este implementată software prin cod C++ sau asamblare, nu prin blocuri fixe ale GPU-ului.

Transformarea vertexurilor în CPU Rendering se realizează prin înmulțirea matricelor — 4x4 pentru proiecție și modelare. La 10 000 de poligoane, aceasta înseamnă 40 000 de înmulțiri de vectori pe cadru — o sarcină pe care CPU o gestionează în 5–10 ms cu cod optimizat. Rasterizarea este cea mai grea etapă, necesitând calculul acoperirii pixelilor pentru fiecare triunghi.

În procesoarele mobile, ARM NEON accelerează randarea software prin instrucțiuni vectoriale de 128 de biți. Conform ARM (2025), un software renderer optimizat NEON funcționează de 3–4 ori mai rapid decât implementarea scalară pe Cortex-X4 la aceeași frecvență de ceas.

Cum funcționează randarea software?

Randarea software începe cu pregătirea scenei pe CPU: geometria (vertexuri, poligoane) este transformată din coordonate mondiale în coordonate de ecran prin operații matriciale. Apoi se efectuează tăierea — eliminarea geometriei în afara câmpului de vedere al camerei.

Rasterizarea CPU împarte fiecare triunghi în pixeli prin algoritmul de linii de scanare (scanline) sau coordonate barycentrice. Pentru fiecare pixel se calculează culoarea ținând cont de texturi, iluminare și transparență. Rezultatul este scris în framebuffer — un tablou de pixeli în memoria RAM.

Diferența cheie față de randarea GPU — absența paralelismului la nivel de pixeli. CPU procesează pixelii secvențial sau cu un paralelism redus prin 4–8 nuclee. Pentru un cadru 1080p (2 milioane de pixeli) cu texturare, sunt necesare 15–30 ms pe CPU față de 2–5 ms pe GPU.

// Rasterizare CPU simplificată a unui singur triunghi
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;
            }
        }
    }
}

Funcția parcurge bounding box-ul triunghiului și verifică apartenența fiecărui pixel prin coordonate barycentrice. Pentru milioane de pixeli, o astfel de buclă se execută în milisecunde pe CPU, dar pentru scene complexe cu mii de triunghiuri, timpul crește liniar.

Comparație între randarea CPU și GPU

Diferența dintre CPU Rendering și GPU Rendering este determinată de arhitectura procesoarelor. CPU este optimizat pentru sarcini secvențiale cu predicție de ramificare, iar GPU — pentru paralelism masiv cu mii de fire. Această diferență fundamentală determină domeniile de aplicare ale fiecărei abordări.

CPU Rendering câștigă în determinism — aceleași date de intrare produc întotdeauna același rezultat. Acest lucru este esențial pentru framework-urile UI, unde fiecare pixel trebuie să coincidă cu designul. GPU poate introduce erori din cauza rotunjirii în virgulă mobilă în diferite drivere.

Pentru grafica 2D cu complexitate redusă (100–500 de primitive), CPU Rendering este adesea mai rapid decât GPU datorită absenței costurilor suplimentare pentru transferul de date prin magistrală și compilarea shaderelor. Conform Google Android Team (2025), randarea software în sistemul View din Android durează 2–3 ms pentru un ecran tipic față de 3–5 ms cu accelerare hardware pe GPU.

Unde se utilizează CPU Rendering

Randarea software rămâne necesară în scenariile în care GPU-ul nu este disponibil, este de prisos sau nu asigură determinismul necesar. Să analizăm principalele domenii de aplicare ale CPU Rendering în dezvoltarea modernă.

Framework-uri UI și pregătirea cadrelor

Android View randaează toate elementele UI pe CPU, apoi transmite rezultatul GPU-ului pentru compunere. Fiecare View apelează onDraw(Canvas), care desenează pe Bitmap prin CPU. Abia după aceea, HWUI compune straturile pe GPU. Aceasta asigură un comportament determinist al UI independent de driverul GPU.

UIKit în iOS începe, de asemenea, cu randarea pe CPU. Core Animation randaează CALayer în backing store pe CPU, apoi trimite texturile către GPU. Conform WWDC 2024, faza software ocupă 30–50% din timpul de randare a cadrului, restul fiind compunerea GPU.

SVG și grafică vectorială

Randarea SVG se execută în mod tradițional pe CPU, deoarece necesită construirea curbelor Bezier complexe și umplerea lor. Bibliotecile precum librsvg și Skia procesează SVG pe CPU, împărțind curbele în triunghiuri și colorându-le. Conform Google Chrome Team (2025), Skia pe CPU randaează pictograme SVG în 0.3–1.5 ms pe procesoarele mobile moderne.

Randarea PDF

Documentele PDF conțin grafică complexă încuibată: fonturi, elemente vectoriale, imagini raster și transformări. Aplicațiile mobile randaează PDF pe CPU prin framework-uri precum PDFKit (iOS) și PdfRenderer (Android). Precizia de afișare și suportul pentru standardul PDF 2.0 necesită procesarea software a fiecărui element.

CPU Rendering pe platformele mobile

Platformele mobile implementează CPU Rendering ținând cont de arhitectura ARM și consumul limitat de energie. Să vedem cum funcționează randarea software pe Android și iOS.

Android: Canvas pe CPU

Android Canvas cu accelerarea hardware dezactivată funcționează complet pe CPU. Clasa Canvas conține metode pentru desenarea primitivelor care sunt executate prin Skia — biblioteca 2D a Google. Skia suportă backend-uri software și GPU, comutând prin flag-ul hardwareAccelerated.

Canvas-ul software creează un Bitmap în memoria RAM, desenează comenzi pe el prin Skia Software Renderer și apoi îl afișează pe ecran. Toate operațiile sunt executate pe CPU cu utilizarea instrucțiunilor NEON pentru optimizare. Conform Skia Team (2025), accelerarea NEON oferă o creștere de performanță de 40–60% pentru operațiile de blend și mascare.

// Randare software prin 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 este creat în memoria CPU, pe el se execută comenzile de desenare, apoi imaginea rezultată este afișată prin ImageView. Această abordare este utilizată pentru watermarking, grafice și imagini dinamice unde controlul complet asupra fiecărui pixel este important.

iOS: Core Graphics pe CPU

Core Graphics — framework-ul Apple pentru grafică raster și vectorială, care funcționează în principal pe CPU. CGContext execută toate operațiile de desenare în mod software, utilizând bibliotecile optimizate ale Apple. Core Graphics suportă Quartz 2D — un motor cu o istorie de 25 de ani.

Pe iOS, Core Graphics transmite rezultatul către Core Animation pentru compunerea pe GPU. Conform Apple Engineering (2025), Core Graphics procesează 80% din desenarea UI pe CPU în UIKit, iar compunerea Metal adună texturile gata pe GPU. UIGraphicsImageRenderer este un wrapper modern pentru randarea imaginilor raster pe CPU.

Optimizarea randării software

Optimizarea CPU Rendering este esențială pentru performanță, deoarece randarea software este principalul consumator de cicluri CPU în framework-urile UI. Să analizăm metodele cheie de accelerare a randării software.

Memorarea în cache a rezultatelor

Cea mai eficientă metodă este să nu redesenezi ceea ce nu s-a schimbat. Dacă conținutul este static, randaează-l o singură dată în Bitmap sau CGLayer și copiază rezultatul final. În Android, acest lucru este implementat prin View.setLayerType(LAYER_TYPE_SOFTWARE) cu un Bitmap memorat în cache. În iOS — prin drawsAsynchronously și CALayer.shouldRasterize.

Minimizarea zonei de redesenuare

Folosește dirty rectangles — urmărește care zone ale ecranului s-au modificat și redesenează numai pe acestea. Android ViewSystem calculează automat regiunea invalidată. iOS CALayer utilizează setNeedsDisplayInRect pentru a limita zona de redesenuare.

Operații pe biți și SSE/NEON

Pentru operațiile cu pixeli (blend, mascare), utilizează instrucțiuni SIMD ale CPU. Android Skia utilizează automat NEON pentru procesoarele ARM. iOS Core Graphics este vectorizat prin Accelerate framework. Conform Google (2025), operațiile blend optimizate NEON în Skia se execută de 3–5 ori mai rapid decât codul scalar.

// Amestecare de pixeli optimizată 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);
    }
}

Instrucțiunile NEON procesează 16 pixeli (128 de biți) într-o singură operație. În combinație cu pipeline-ul ARM Cortex-X4, acest lucru oferă o capacitate de până la 500 de milioane de pixeli pe secundă la copierea și amestecarea software — suficient pentru un ecran FullHD la 60 FPS.