CPU Rendering: ano ito, mga prinsipyo at paano gumagana ang software rendering

Ano ang CPU Rendering?

CPU Rendering — isang paraan ng pagbuo ng imahe kung saan ang lahat ng yugto ng graphics pipeline ay ginagawa sa central processor gamit ang mathematical calculations. Hindi tulad ng GPU, kung saan ang rasterization at texturing ay naka-embed sa mga specialized block, ginagawa ng CPU ang mga ito sa pamamagitan ng universal SSE/NEON instructions.

Sa kasaysayan, lahat ng rendering ay software — ang mga unang graphical interface (Xerox Alto, 1973) at 3D games (Quake, 1996) ay ni-render sa CPU. Ang terminong «software renderer» ay naging kasingkahulugan ng CPU Rendering. Ang paglipat sa hardware acceleration ay nagsimula sa pagdating ng abot-kayang 3D accelerators noong huling bahagi ng 1990s, ngunit ang software rendering ay nanatili bilang fallback mechanism.

Ayon sa Akamai (2025), ang CPU Rendering ay ginagamit sa 35% ng mga mobile web session bilang pangunahing rendering mode — sa mahihinang device, sa emulators at kapag naka-off ang GPU acceleration. Sa iOS at Android platforms, ang UI frameworks (UIKit, Android View) ay laging nagre-render ng unang ilang frame sa CPU hanggang sa ma-initialize ang GPU commands.

Ang mga modernong processor ay sumusuporta sa SIMD instructions (SSE4.2, AVX-512, ARM NEON) na bahagyang ginagaya ang parallelism ng GPU. Gayunpaman, ang pisikal na bilang ng mga core (4–12) at kawalan ng specialized rasterization block ay naglilimita sa performance ng CPU Rendering sa kumplikadong graphics.

Mga yugto ng software rendering

Software pipeline ay kinabibilangan ng parehong yugto gaya ng hardware pipeline: vertex transformation, clipping, rasterization, texturing at pixel output. Ang pagkakaiba ay ang bawat yugto ay implementado sa software sa pamamagitan ng C++ o assembly code, hindi sa pamamagitan ng fixed GPU blocks.

Ang vertex transformation sa CPU Rendering ay ginagawa sa pamamagitan ng matrix multiplication — 4x4 para sa projection at modeling. Sa 10,000 polygons, ito ay 40,000 vector multiplications bawat frame — isang load na kayang hawakan ng CPU sa loob ng 5–10 ms na may optimized code. Ang rasterization ang pinakamabigat na yugto, na nangangailangan ng pagkalkula ng pixel coverage para sa bawat triangle.

Sa mobile processors, pinapabilis ng ARM NEON ang software rendering sa pamamagitan ng vector instructions na 128 bits ang lapad. Ayon sa ARM (2025), ang NEON-optimized software renderer ay gumagana ng 3–4 na beses na mas mabilis kaysa sa scalar implementation sa Cortex-X4 sa parehong clock frequency.

Paano gumagana ang software rendering?

Software rendering ay nagsisimula sa paghahanda ng scene sa CPU: ang geometry (vertices, polygons) ay kino-convert mula sa world coordinates patungo sa screen coordinates sa pamamagitan ng matrix operations. Pagkatapos ay isinasagawa ang clipping — pagtanggal ng geometry sa labas ng field of view ng camera.

Ang rasterization ng CPU ay hinahati ang bawat triangle sa mga pixel sa pamamagitan ng scanline algorithm o barycentric coordinates. Para sa bawat pixel, kinakalkula ang kulay na isinasaalang-alang ang textures, illumination at transparency. Ang resulta ay isinusulat sa framebuffer — isang array ng pixels sa RAM.

Ang pangunahing pagkakaiba sa GPU rendering ay kawalan ng parallelism sa antas ng pixel. Pinoproseso ng CPU ang mga pixel nang sequential o may maliit na parallelism sa pamamagitan ng 4–8 core. Para sa isang 1080p frame (2 milyong pixels) na may texturing, kailangan ng 15–30 ms sa CPU kumpara sa 2–5 ms sa GPU.

// Pinadaling CPU rasterization ng isang triangle
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;
            }
        }
    }
}

Ang function ay lumilibot sa bounding box ng triangle at sinusuri ang pag-aari ng bawat pixel sa pamamagitan ng barycentric coordinates. Para sa milyong-milyong pixels, ang ganitong loop ay tumatakbo sa millisecond sa CPU, ngunit para sa kumplikadong scenes na may libu-libong triangles, ang oras ay tumataas nang linear.

Paghahambing ng CPU at GPU rendering

Ang pagkakaiba sa pagitan ng CPU Rendering at GPU Rendering ay tinutukoy ng arkitektura ng mga processor. Ang CPU ay na-optimize para sa sequential tasks na may branch prediction, ang GPU — para sa mass parallelism na may libu-libong threads. Ang pangunahing pagkakaibang ito ay tumutukoy sa mga lugar ng aplikasyon ng bawat approach.

CPU Rendering ay nananalo sa determinism — ang parehong input data ay laging nagbibigay ng parehong resulta. Ito ay mahalaga para sa UI frameworks, kung saan ang bawat pixel ay dapat tumugma sa disenyo. Ang GPU ay maaaring magdulot ng mga error dahil sa floating-point rounding features sa iba’t ibang drivers.

Para sa 2D graphics na may mababang complexity (100–500 primitives), ang CPU Rendering ay madalas mas mabilis kaysa GPU dahil sa kawalan ng overhead para sa data transfer sa pamamagitan ng bus at shader compilation. Ayon sa Google Android Team (2025), ang software rendering sa View system ng Android ay tumatagal ng 2–3 ms para sa tipikal na screen kumpara sa 3–5 ms na may hardware acceleration sa GPU.

Saan ginagamit ang CPU Rendering

Software rendering ay nananatiling kailangan sa mga scenario kung saan ang GPU ay hindi available, sobra o hindi nagbibigay ng kinakailangang determinism. Tingnan natin ang mga pangunahing lugar ng aplikasyon ng CPU Rendering sa modernong development.

UI frameworks at paghahanda ng frame

Android View ay nagre-render ng lahat ng UI elements sa CPU, pagkatapos ay inililipat ang resulta sa GPU para sa composition. Bawat View ay tumatawag ng onDraw(Canvas), na gumuguhit sa Bitmap sa pamamagitan ng CPU. Pagkatapos lamang nito, kino-compose ng HWUI ang mga layer sa GPU. Tinitiyak nito ang deterministic na pag-uugali ng UI na independyente sa GPU driver.

UIKit sa iOS ay nagsisimula rin sa CPU rendering. Core Animation ay nagre-render ng CALayer sa backing store sa CPU, pagkatapos ay nagpapadala ng textures sa GPU. Ayon sa WWDC 2024, ang software phase ay tumatagal ng 30–50% ng frame rendering time, ang natitira ay GPU composition.

SVG at vector graphics

SVG rendering ay tradisyonal na ginagawa sa CPU, dahil nangangailangan ito ng pagbuo ng mga kumplikadong Bezier curves at pagpuno sa mga ito. Ang mga library tulad ng librsvg at Skia ay nagpoproseso ng SVG sa CPU, hinahati ang curves sa triangles at kinukulayan ang mga ito. Ayon sa Google Chrome Team (2025), ang Skia sa CPU ay nagre-render ng SVG icons sa loob ng 0.3–1.5 ms sa mga modernong mobile processors.

PDF rendering

PDF documents ay naglalaman ng kumplikadong nested graphics: fonts, vector elements, raster images at transformations. Ang mga mobile application ay nagre-render ng PDF sa CPU sa pamamagitan ng frameworks tulad ng PDFKit (iOS) at PdfRenderer (Android). Ang accuracy ng display at suporta sa PDF 2.0 standard ay nangangailangan ng software processing ng bawat elemento.

CPU Rendering sa mga mobile platform

Mobile platforms ay nag-i-implement ng CPU Rendering na isinasaalang-alang ang ARM architecture at limitadong konsumo ng kuryente. Tingnan natin kung paano gumagana ang software rendering sa Android at iOS.

Android: Canvas sa CPU

Android Canvas na naka-off ang hardware acceleration ay gumagana nang buo sa CPU. Ang Canvas class ay naglalaman ng mga method para sa pagguhit ng primitives na isinasagawa sa pamamagitan ng Skia — ang 2D library ng Google. Sinusuportahan ng Skia ang software at GPU backends, lumilipat sa pamamagitan ng flag na hardwareAccelerated.

Ang software Canvas ay gumagawa ng Bitmap sa RAM, gumuguhit ng mga command dito sa pamamagitan ng Skia Software Renderer, pagkatapos ay ipinapakita ito sa screen. Lahat ng operations ay ginagawa sa CPU gamit ang NEON instructions para sa optimization. Ayon sa Skia Team (2025), ang NEON acceleration ay nagbibigay ng 40–60% performance improvement para sa blend at masking operations.

// Software rendering sa pamamagitan ng 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)

Ang Bitmap ay ginagawa sa CPU memory, ang mga drawing command ay isinasagawa dito, pagkatapos ang resultang imahe ay ipinapakita sa pamamagitan ng ImageView. Ang approach na ito ay ginagamit para sa watermarking, graphs at dynamic images kung saan mahalaga ang buong kontrol sa bawat pixel.

iOS: Core Graphics sa CPU

Core Graphics — framework ng Apple para sa raster at vector graphics, na pangunahing gumagana sa CPU. Ginagawa ng CGContext ang lahat ng drawing operations sa software mode gamit ang highly optimized libraries ng Apple. Sinusuportahan ng Core Graphics ang Quartz 2D — isang engine na may 25-taong kasaysayan.

Sa iOS, inililipat ng Core Graphics ang resulta sa Core Animation para sa composition sa GPU. Ayon sa Apple Engineering (2025), pinoproseso ng Core Graphics ang 80% ng UI drawing sa CPU sa UIKit, at ang Metal composition ay nagtitipon ng mga ready textures sa GPU. Ang UIGraphicsImageRenderer ay isang modernong wrapper para sa rendering ng raster images sa CPU.

Optimization ng software rendering

Optimization ng CPU Rendering ay mahalaga para sa performance, dahil ang software rendering ay pangunahing kumokonsumo ng CPU cycles sa UI frameworks. Tingnan natin ang mga pangunahing method para pabilisin ang software rendering.

Caching ng resulta

Ang pinaka-epektibong method ay huwag i-redraw ang hindi nagbago. Kung static ang content, i-render ito nang isang beses sa Bitmap o CGLayer at kopyahin ang ready result. Sa Android, ito ay implementado sa pamamagitan ng View.setLayerType(LAYER_TYPE_SOFTWARE) na may naka-cache na Bitmap. Sa iOS — sa pamamagitan ng drawsAsynchronously at CALayer.shouldRasterize.

Pag-minimize ng redraw area

Gumamit ng dirty rectangles — subaybayan kung aling mga area ng screen ang nagbago at i-redraw lamang ang mga ito. Android ViewSystem ay awtomatikong kumakalkula ng invalidated region. iOS CALayer ay gumagamit ng setNeedsDisplayInRect para limitahan ang redraw area.

Bit operations at SSE/NEON

Para sa pixel operations (blend, masking), gamitin ang SIMD instructions ng CPU. Android Skia ay awtomatikong gumagamit ng NEON para sa ARM processors. iOS Core Graphics ay vectorized sa pamamagitan ng Accelerate framework. Ayon sa Google (2025), ang NEON-optimized blend operations sa Skia ay tumatakbo ng 3–5 beses na mas mabilis kaysa scalar code.

// NEON-optimized pixel blending (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);
    }
}

Ang NEON instructions ay nagpoproseso ng 16 pixels (128 bits) sa isang operasyon. Sa kombinasyon sa ARM Cortex-X4 pipeline, ito ay nagbibigay ng throughput na hanggang 500 milyong pixels per second para sa software copying at blending — sapat para sa FullHD screen na may 60 FPS.