Verzija v1.29 vec razbija 3D podatke na "batch-eve" koji su otprilike ~1 GB velicine, tako da komotno drajver moze da se nosi sa tim i da ubacuje/izbacuje batch po batch u/iz video memorije tokom rendera. Sa ovom promenom prolaze renderi koji su 1.5-2x veci od VRAM-a bez problema.
Medjutim, svejedno, ako imas 64 GB+ 3D podataka i dalje ima problema :(
Jedna od nezgoda je sto bar matori OpenGL API nema uopste koncept "video" / "sistemske" i sl. memorije, to je poptuno apstrakovano od tebe. Kad kreiras VBO objekat (u kome drzis geometriju i indekse), GL drajver je zaduzen da vidi sta ce i kako ce sa njim da barata i na GL drajveru je da odluci kad i kako ce da sibne podatke na GPU. Stavise, nije nemoguce da GL drajver napravi i jos jednu lokalnu kopiju 3D podataka u sistemskom RAM-u koju kasnije DMA-uje na GPU po potrebi ili vraca sa GPU-a, zapravo mozda ovde lezi jedan od problema posto je ukupna kolicina RAM-a 128 GB a mozda mu za sve to treba puno non-pageable memorije.
Resenje za ovo bi bilo da ja manuelno radim "swap" 3D podataka tako sto cu imati, recimo, jedan ili par VBO-ova sa kojima zauzmem ceo (ili skoro ceo) VRAM a onda ja rucno kopiram nove podatke iz moje memorije (znaci ne VBO) tako da GL drajver nikada ne uzme vise od VRAM-a za svoje interne bafere, ali to je onda dodatan memcpy() sa moje strane za svako crtanje (+ mozda jos jedna kopija unutar drajvera ako drajver misli da je pametnije da podaci "stoje" jos malo u sistemskom RAM-u).
A da, jos jedan problem je AntTweakBar koji koristim za vizualizaciju retine koji trci u posebnom thread-u sa svojim posebnim GL kontekstom / prozorom ... izgleda je taj pun pogresnih GL poziva koje NVIDIA drajver uspesno "pegla" (samo baca warning-e u GL debuggeru), ali izgleda u ovoj situaciji ozbiljno pretrpane memorije stvari pocinju da bivaju nestabilne i ti problemi pocinju da se prelivaju i na moj kontekst koji crta glavnu vizualizaciju.
Izbacivanjem AntTweakBar-a (nova verzija ce imati skrivenu opciju -noretinatwbar, za ovakve situacije) stvari postaju malo stabilnije, CodeXL GL debugger se vise ne buni, ali i dalje nije garantovano stabilno da render prodje za sve frejmove.
--
Sve u svemu, pravo resenje bi bilo da se batali OpenGL kompletno i predje na Vulkan, sa postenim memorijskim menadzmentom ogromnih 3D podataka. Ali mislim da to necu raditi u skorije vreme.
DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos:
http://www.digicortex.net/node/17 Gallery:
http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! -
https://github.com/psyq321/PowerMonkey