Octane Out-of-Core crash do geometry: Vì sao 256GB RAM vẫn thất bại

Khi xử lý một lỗi crash bộ nhớ Out-of-Core do geometry trong Octane, các 3D artist và Technical Director thường gặp một nghịch lý khó hiểu: một workstation có 128GB hoặc 256GB RAM DDR5 tốc độ cao đột ngột sập trong lúc look-dev hoặc khi xuất batch cuối cùng, kèm một dòng log báo lỗi nghiêm trọng:

Mở Windows Task Manager ra thì thấy workstation chỉ dùng chưa tới 30GB RAM hệ thống. Vậy tại sao cơ chế phân trang Out-of-Core lại không xử lý được phần cấp phát bị tràn?

Câu trả lời nằm ở một giới hạn phần cứng cơ bản nhưng thường bị hiểu sai trong cộng đồng đồ họa 3D: OctaneRender không thể đẩy tọa độ hình học hay cấu trúc phân cấp tăng tốc ray tracing sang RAM hệ thống. Hiểu cách Octane phân chia bộ nhớ chính là điểm khác biệt giữa việc đâm vào bức tường sản xuất không thể vượt qua và việc giao các cảnh chất lượng broadcast đúng tiến độ.

Lầm tưởng phổ biến nhất trong giới làm VFX là chỉ cần bật Enable Out-of-Core trong Octane Preferences thì toàn bộ RAM hệ thống sẽ trở thành một kho VRAM ảo vô hạn. Trên thực tế, OTOY đã thiết kế một hệ thống phân cấp bộ nhớ tách biệt và rất chặt chẽ:

1.1. Cơ chế path tracing và độ trễ của OptiX BVH

Tại sao OctaneRender không chịu phân trang geometry qua bo mạch chủ? Ràng buộc này đến từ các quy luật quang học và cách tia sáng được truy vết trong path tracing:

• Tia nảy không theo trật tự: Khác với pipeline rasterize trong game chỉ xét các bề mặt hướng về camera frustum, một path tracer unbiased bắn ra hàng tỷ tia nảy lung tung khắp không gian 3D để tính phản xạ khuếch tán qua lại, caustics và tán xạ dưới bề mặt.

• Duyệt không gian dưới một micro giây: Để biết một photon đang nảy có cắt một tam giác hay không, các RT Core (Ray Tracing) phần cứng của GPU phải duyệt một cây bao không gian phức tạp gọi là Bounding Volume Hierarchy (BVH). RT Core duyệt cây này hàng triệu lần mỗi giây, đòi hỏi độ trễ bộ nhớ chỉ tính bằng vài nano giây.

• Nút thắt độ trễ của bus: Nếu cấu trúc OptiX BVH hoặc mảng vertex thô bị đẩy qua bus PCIe của bo mạch chủ sang RAM hệ thống, phần độ trễ dù rất nhỏ của giao tiếp PCIe cũng sẽ khiến các streaming multiprocessor (SM) đứng hoàn toàn. GPU sẽ mất 99% chu kỳ hoạt động để chờ các gói tọa độ hình học, làm treo cả hệ điều hành. Để giữ hiệu năng ở mức sản xuất, OTOY bắt buộc mọi đa giác, đường cong tóc và node BVH đều phải nằm trực tiếp trên chip GPU.

1.2. Những thứ “ngầm” ngốn VRAM: phần phụ trội của OptiX và framebuffer 4K

Artist thường ước tính dung lượng cảnh bằng cách xem kích thước file đa giác trên ổ đĩa, rồi lại bất ngờ khi VRAM cạn mà không rõ lý do. Có hai khoản cấp phát nền rất lớn chiếm VRAM vật lý trước cả khi bắt đầu shading:

• BVH của OptiX phình to: Biên dịch geometry thô thành cây tăng tốc OptiX BVH có thể duyệt được sẽ cộng thêm một khoản “thuế” bộ nhớ quản lý từ 20% đến 40% trên nền mảng vertex thô. Các mesh bị phân mảnh, nhiều cụm đa giác rời rạc làm độ sâu BVH tăng theo cấp số nhân, đòi hỏi lượng VRAM rất lớn.

• Framebuffer & AOV nhiều pass: Xuất file độ phân giải cao (như 4K UHD hoặc độ phân giải in 8K) với nhiều Render Pass float 32-bit (Cryptomatte, Z-Depth, Diffuse, Specular, Normal, Surface Position) cần những bộ đệm ảnh khổng lồ không nén. Một mảng AOV 4K lớn có thể chiếm sẵn 3GB đến 6GB VRAM vật lý chỉ để khởi tạo khung render, rất lâu trước khi tam giác đầu tiên của mesh được nạp vào bộ nhớ.

Crash VRAM do geometry không phải lỗi ngẫu nhiên của phần mềm; đó là lỗi phần cứng có tính xác định, xảy ra trong lúc biên dịch cảnh.

2.1. Vì sao RAM hệ thống vẫn không được dùng tới khi crash

Như vòng đời biên dịch ở trên cho thấy, việc cấp phát Framebuffer, lưới đa giác và OptiX BVH diễn ra trước khi texture của cảnh được nạp.

Nếu một cảnh dày đặc gồm 50 triệu đa giác thô cần 26GB VRAM vật lý cho geometry và việc tạo BVH trên một card 24GB (như RTX 3090 hoặc RTX 4090):

1. Yêu cầu cấp phát bộ nhớ thất bại ở Phase 3 (biên dịch BVH).

2. Driver NVIDIA CUDA runtime gặp lỗi cấp phát phần cứng (cudaErrorMemoryAllocation).

3. OctaneRender nhận cờ lỗi phần cứng nghiêm trọng và dừng tiến trình render.

Không có thời điểm nào trong chuỗi này Octane cố đẩy dữ liệu sang RAM hệ thống, vì trình quản lý phân trang Out-of-Core chỉ quản lý bộ đệm texture của vật liệu. 256GB RAM của workstation cứ nằm không trong khi job render bị crash.

2.2. 4 yếu tố ngầm làm geometry phình to

Việc VRAM bị geometry làm tràn gần như luôn đến từ bốn lỗi cấu hình cảnh phổ biến:

• Subdivision Surface (SubD) tăng theo cấp số nhân: Trong Cinema 4D, mỗi cấp của đối tượng Subdivision Surface nhân số đa giác lên 4 lần (4^n). Một mesh gốc 80.000 đa giác đặt Subdivision Render ở cấp 4 sẽ tạo ra:

  80.000 × 4^4 = 80.000 × 256 = 20.480.000 đa giác

  Để SubD ở cấp 4 hoặc 5 trên nhiều asset trong cảnh sẽ đẩy bộ nhớ geometry vượt giới hạn vật lý của card chỉ trong vài giây.

• Nhập file CAD & tessellation NURBS không giới hạn: Nhập file kỹ thuật cơ khí (.STEP, .IGES, .OBJ) thường kéo theo tessellation siêu dày. Những con vít, bu lông và các đường vát nhỏ bên trong có thể mang theo hàng trăm nghìn tam giác siêu nhỏ, ngốn hàng GB VRAM cho những chi tiết chỉ chiếm vài pixel trong khung hình cuối cùng.

• Cấu hình Cloner trong Cinema 4D sai (Standard và Multi-Instance): Rải 100.000 mảnh vỡ hoặc lá cây bằng Cloner tiêu chuẩn sẽ tạo ra các instance riêng lẻ. Cinema 4D và Octane coi mỗi instance là một asset đa giác độc lập, sinh ra hàng trăm nghìn draw call và nhân bản bộ đệm tọa độ cho đến khi VRAM cạn hẳn.

• Bản scan 3D & photogrammetry chưa xử lý: Dữ liệu photogrammetry thô và bản scan nhân vật 3D mật độ cao thường chứa mesh non-manifold, chưa retopology với 15 đến 30 triệu tam giác. Nếu không retopology hoặc bake displacement, những bản scan chưa tối ưu này sẽ lãng phí rất nhiều VRAM.

Khi geometry của cảnh vừa với VRAM vật lý và Out-of-Core đã đẩy thành công các texture 8K nặng và mảng UDIM sang RAM hệ thống, cảnh sẽ render mà không crash. Tuy nhiên, artist ngay lập tức gặp vấn đề thứ hai: cái giá độ trễ của Out-of-Core.

3.1. Cơ chế của tình trạng “GPU đói dữ liệu”

Khi một tia đang hoạt động chạm vào bề mặt có texture mà map diffuse 8K đã bị đẩy sang RAM hệ thống:

1. Ray tracer dừng thực thi tia đó trên luồng tính toán tương ứng.

2. Một tín hiệu ngắt được gửi qua bus PCIe của bo mạch chủ tới bộ điều khiển bộ nhớ của CPU.

3. Tile texture được yêu cầu sẽ được lấy ra từ RAM hệ thống, chia thành các gói dữ liệu và truyền qua các lane PCIe vào cache texture nhỏ của GPU.

Băng thông bộ nhớ GDDR7 cục bộ đạt tới 1.792 GB/s, trong khi một bus PCIe 4.0 x16 tiêu chuẩn chỉ truyền được 31,5 GB/s—chênh lệch băng thông 57x.

Khi hàng trăm luồng cùng lúc yêu cầu dữ liệu texture bên ngoài, bus PCIe bị bão hòa hoàn toàn. Các nhân tính toán tần số cao của GPU rơi vào những “khoảng trống” thực thi, chờ dữ liệu texture nhỏ giọt qua bo mạch chủ. Nhiệt độ và công suất GPU giảm xuống, nhưng thời gian render mỗi frame tăng từ 20% đến 40%.

3.2. Cái bẫy chia lane khi chạy nhiều GPU trên máy phổ thông

Trên các bo mạch chủ phổ thông (chipset desktop Intel LGA1700 hoặc AMD AM5), CPU chỉ cung cấp 16 đến 24 lane PCIe riêng:

• Cấu hình một GPU: Card đồ họa nằm ở khe chính, chạy đủ băng thông PCIe 4.0 x16 (31,5 GB/s).

• Cấu hình hai GPU: Bo mạch chủ tự động chia lane (bifurcation), hạ cả hai khe xuống PCIe 4.0 x8 / x8 (15,7 GB/s mỗi card).

Chạy nhiều card trên khe đã chia lane sẽ làm băng thông truyền texture giảm một nửa, khiến Out-of-Core càng chậm hơn. Các workstation thực sự dành cho sản xuất tránh giới hạn này bằng cách dùng nền tảng AMD Ryzen Threadripper PRO , cung cấp tới 128 lane PCIe riêng để mọi GPU lắp vào đều nhận đủ băng thông x16 không bị bóp.

Để bảo vệ các dự án thương mại nặng khỏi lỗi crash bộ nhớ, Technical Director nên áp dụng quy trình chuẩn 4 bước sau để lập ngân sách bộ nhớ:

Xem các thông số vận hành và ngưỡng bão hòa bộ nhớ ở từng phân khúc GPU:

Q1: Vì sao OctaneRender chỉ cho phân trang Out-of-Core với texture mà không cho đẩy geometry ra ngoài?

OctaneRender dựa vào các nhân NVIDIA OptiX Ray Tracing (RT) tăng tốc phần cứng, tính hàng tỷ phép giao tia–tam giác mỗi giây. Việc duyệt không gian này đòi hỏi độ trễ truy cập bộ nhớ dưới một micro giây. Vì RAM hệ thống truy cập qua bus PCIe của bo mạch chủ có độ trễ cao hơn đáng kể, việc phân trang bộ đệm vertex hay cây OptiX BVH sẽ khiến các nhân tính toán bị treo liên tục. Do đó, OTOY bắt buộc mọi cấu trúc hình học phải nằm 100% In-Core trên VRAM vật lý của GPU.

Q2: Thông số “GPU Headroom” trong Octane Preferences dùng để làm gì, và mức thiết lập tối ưu cho sản xuất là bao nhiêu?

GPU Headroom là vùng VRAM an toàn dành riêng cho các hoạt động của hệ điều hành, gồm Windows Desktop Window Manager (DWM), chu kỳ làm mới viewport và driver hiển thị chạy nền. Nếu GPU Headroom đặt về 0MB, Octane sẽ cố chiếm toàn bộ VRAM vật lý; chỉ cần hệ điều hành yêu cầu cấp phát bộ nhớ trong tích tắc cũng đủ làm driver CUDA crash ngay lập tức. Technical Director nên cấu hình GPU Headroom nghiêm ngặt trong khoảng 1.500MB đến 2.048MB.

Q3: Nâng cấp bo mạch chủ workstation lên PCIe 5.0 có loại bỏ được thiệt hại hiệu năng của texture Out-of-Core không?

Không. Dù khe PCIe 5.0 x16 tăng gấp đôi băng thông lý thuyết lên khoảng 63 GB/s so với PCIe 4.0, nó vẫn chậm hơn gần 28 lần so với bộ nhớ GDDR7 trên chip (~1.792 GB/s trên RTX 5090). Dù PCIe 5.0 giảm độ trễ truyền qua bo mạch chủ, luồng xử lý vẫn bị treo và GPU vẫn đói dữ liệu khi lấy các tile texture 8K độ phân giải cao, ước tính làm thời gian render tăng 10% đến 25%.

Q4: Làm sao artist phân biệt crash VRAM do geometry với timeout driver đồ họa thông thường?

Xem log ứng dụng trong Cinema 4D tại Extensions > Octane > Octane Log Window. Nếu log ghi rõ lỗi:

CUDA error: out of memory -> Failed to allocate device memory trong giai đoạn Building OptiX BVH hoặc Updating mesh data , thì crash chắc chắn do geometry và cấu trúc tăng tốc làm cạn VRAM, chứ không phải timeout driver ngẫu nhiên hay lỗi biên dịch shader.

Q5: Nếu cảnh sản xuất có geometry phức tạp không thể tối ưu thêm, cấu hình phần cứng nào giải quyết được nút thắt này?

Giải pháp kiến trúc hiệu quả nhất là chuyển cảnh sang các node bare-metal IaaS trên cloud được trang bị GPU NVIDIA RTX 5090 (32GB GDDR7). Khoảng VRAM vật lý dư +33% so với card 24GB đời trước đủ để giữ mesh đa giác dày đặc, cây OptiX BVH sâu và framebuffer multi-pass 4K hoàn toàn In-Core, tránh độ trễ của Out-of-Core và loại bỏ lỗi CUDA out-of-memory.

Q6: Render bằng nhiều GPU có gộp VRAM lại để chứa geometry lớn hơn trong Octane không?

Không. OctaneRender không gộp VRAM của nhiều card đồ họa. Geometry, mảng vertex và cây OptiX BVH phải được sao chép đầy đủ vào VRAM cục bộ của từng GPU đang chạy. Một workstation có hai card 24GB vẫn chỉ có trần geometry 24GB, không phải 48GB. Ngoài ra, NVIDIA đã bỏ hẳn cầu NVLink vật lý trên các kiến trúc Ada Lovelace và Blackwell hiện đại (RTX 4090 và RTX 5090). Nếu hệ thống có các GPU không đồng nhất (ví dụ một card 32GB và một card 24GB), Octane sẽ bị giới hạn theo card yếu nhất, giới hạn trần In-Core khả dụng của toàn hệ thống ở mức 24GB.