Kandidatuppsats IT-Forensik och Informationssäkerhet
Datorkluster för framställning av 3d-modellerad grafik
Stellan Salomonsson
Sammanfattning
Sammanfattning
3D-modellerad grafik har blivit ett viktigt verktyg för att visualisera projekt inom arkitektur, för att skapa fotorealistiska visualiseringar är åtgången av en dators processorkraft stor där beräkningen av dessa 3D- modeller till färdig bild eller animation blir en flaskhals för arkitektföretagets visualiseringsavdelning. Stora animationsföretag har länge använt sig av datorkluster för att kunna hantera processorbehovet hos programvara för grafisk formgivning och detta är en lösning som i mindre skala även passar sig för 3D- grafiker arbetandes inom arkitektur. Mitt examensarbete har varit införandet av ett sådant datorkluster på arkitektfirman White Arkitekters huvudkontor i Göteborg. Lösningen har till stor del eliminerat den flaskhals som tidigare existerade och har gett 3D-grafikerna möjligheten att göra mer avancerade projekt samt att kräva bättre bildkvalité av de olika programvaror som används.
Förord
Följande rapport är ett examensarbete omfattande femton poäng inom ämnet datateknik på högskolan i Halmstad. Arbetet är utfört på White Arkitekter AB i Göteborg och jag vill tacka företaget och speciellt de teknikansvariga för att ha gett mig förtroendet för att göra detta arbete.
Jag vill också speciellt tacka avdelningen för visualisering och särskilt Andreas Laessker som har varit kontaktperson på företaget och hjälpt mig med testning och utvärdering.
Jag vill också tacka mina opponenter och klasskamrater Andreas Flygare och Ali Celik som har bidragit med värdefulla synpunkter på min rapport.
Stellan Salomonsson juni 2011
Innehållsförteckning
Innehållsförteckning
Förkortningar...1
1 Inledning...2
1.1 Bakgrund ...2
1.2 Syfte...2
1.3 Avgränsningar...2
1.4 Precisering av arbetsuppgift ...2
2 Teknisk bakgrund...2
2.1 Programvara...2
2.2 Rendering – CPU eller GPU ?...3
3 Översikt av systemet...3
4 Val av hårdvara...4
4.1 CPU ...4
4.2 RAM...5
4.3 HDD ...5
4.4 Moderkort ...5
4.5 Chassi ...5
4.6 Kylning...5
4.7 Switch...5
5 Val av mjukvara...5
5.1 Deadline...6
6 Konfiguration...6
6.1 Renderingsnod...6
6.2 Nätverk ...6
6.3 Felsökning och finjustering...6
7 Resultat...8
8 Slutsats... 9
9 Fortsatt arbete... 9
Referenser...10
Förkortningar
1
Förkortningar
GPU ... Graphic processing unit CPU... Central processing unit CG ... Computer graphics
NURBS... Non-uniform rational B-spline LGA ... Land grid array
PCI-E... Peripheral component interconnect express PSU ... Power supply unit
HDD ... Hard disk drive
UNC... Universal naming convention
SATA ... Serial advanced technology attachment SSD... Solid state drive
mATX... micro advanced technology extended
EFI/BIOS... Extensible firmware interface/Basic input output system PXE... Preboot execution environment
1 Inledning
White Arkitekter AB är ett av nordens största arkitektföretag med huvudkontor i Göteborg. De har börjat integrera visualiseringen av projekt i sitt arbetsflöde istället för att anlita externa visualiseringskontor. På Göteborgskontoret finns det sju personer som arbetar med mer avancerade 3D-modelleringsprogram.
Visualiseringen är viktig i tävlingar om kontrakt där olika arkitektföretag visar upp sina idéer för ett byggnadsprojekt eller när en beställare eller arkitekt vill ha en visualiserad bild.
1.1 Bakgrund
För att skapa fotorealistisk datorgrafik måste beräkningar göras utifrån den tredimensionella värld som har skapats inom ett datorprogram, denna beräkning kallas inom datorgrafik för rendering. Renderingen har att göra med hur ljus reflekteras mot olika ytor eller diverse andra optiska effekter. För att uppnå fotorealism från datorgenererad grafik finns det en mångfald av algoritmer som går under samlingsnamnet
”Global Illumination”[1] exempel på algoritmer är t.ex. ”Ray Tracing”[2] eller ”Radiosity”[3] vilka är i olika grad alla krävande av en dators processor.
Innan införandet av ett datorkluster för rendering (mer känt som en ”renderingfarm” inom CG- samfundet) har all rendering utförts på arbetsdatorerna. Detta har inneburit förlorad arbetstid om renderingen har varit tvungen att göras under arbetstimmarna eftersom beräkningarna tar upp datorns processorkraft så att fortsatt effektivt arbete försvåras. Det har också inneburit en lång väntetid vilket har gjort nödvändigt att renderingen utförs över natten då potentiella fel i processen kanske inte upptäcks.
1.2 Syfte
Syftet är att, genom datateknik och systemvetenskap, effektivisera arbetsprocessen för 3D-grafikerna samt att ge större möjlighet för att utveckla den datorgrafiska visualiseringens roll hos White Arkitekter.
1.3 Avgränsningar
Renderingsfarmen är konfigurerad för tre olika programvaror (Rhinoceros 3d, Adobe After Effects och 3d Studio Max Design 2010 och 2011). Tester kommer att utföras endast på 3d Studio Max eftersom tider som uppnås med den är även representativa för Rhinoceros 3d. After Effects är ännu inte i bruk på företaget och kommer därför inte att testas. Ytterligare en stor del av de anställda på företaget med en fjärde programvara skulle kunna dra nytta av renderingsfarmen men har uteslutits från användandet pga.
budgetrestriktioner, med ett ökat antal renderingsnoder är det ett stöd som i framtiden kan läggas till.
Arbetet utforskar inte andra sätt att effektivisera arbetsflödet som t.ex. genom GPU-baserad rendering för förhandsgranskande renderingar[3] utan fokuserar endast på slutprodukten.
IT-säkerhetsaspekter och nätverkskonfigurationer kommer inte i någon större utsträckning diskuteras i rapporten för att skydda företagets nätverk.
1.4 Precisering av arbetsuppgift
Arbetet består av att köpa in passande utrustning, installera hårdvara och mjukvara, konfigurera mjukvaran samt renderingsnodernas roll i nätverket, testa funktionaliteten och utvärdera resultatet.
2 Teknisk bakgrund
2.1 Programvara
Här följer en kort beskrivning av den programvara som renderingsfarmen är anpassad för:
• 3D Studio Max Design 2011
3DS Max Design är en populär tredimensionell animations- och modelleringsprogramvara för visualisering och design som är riktad mot användare inom arkitektur.[4]
Teknisk bakgrund/Översikt av system
3
• Rhinoceros 3D 4.0
Rhinoceros 3D är ett NURBS-baserat[5] modelleringsprogram som har blivit populärt bland designföretag för sin låga inlärningskurva och sitt överkomliga pris i jämförelse med liknande programvaror.[6]
• After Effects CS5
After Effects är ett program för att skapa visuella effekter i film och för behandling av rörlig grafik.[7]
• VRay 1.5
VRay är en renderingsmotor som finns som plug-in till många 3D-program, den har blivit populär för visualisering av arkitektur pga. den höga grad av fotorealism som den kan åstadkomma.[8]
2.2 Rendering – CPU eller GPU ?
När en dator renderar en bild eller en serie bilder i form av en animation använder renderingsmotorn traditionellt sett sig av antingen moderkortets CPU eller grafikkortets GPU, utveckling görs även på att kombinera dessa två komponenters beräkningskapacitet.[9] GPU:n är bra på att rendera snabbt när det kommer till mindre avancerade renderingar men har problem när fotorealistiska bilder av en högre komplexitet ska framställas. Man kan säga att GPU:ns fördel vid beräkningar är bredd medan CPU:ns fördel är djup.[10]
3 Översikt av systemet
Nätverksrendering kan göras på två snarlika sätt, genom ”distributed bucket rendering”(DBR) vilket delar upp bilden i s.k. ”buckets” (renderingsregioner) och skickar dessa över nätverket för att renderas på någon av noderna. Vid den här sortens nätverksrendering styrs processen av arbetsdatorn som därför också måste ta del i renderingen. En processorkärna kan simultant rendera två buckets åt gången.
Renderingsregionernas storlek kan ofta justeras med den renderingsmotor som används, en ökad storlek kan minska nätverkstrafiken. DBR finns inbyggt i många renderingsmotorer och är tänkt som ett enklare sätt för att nätverksrendera, i första hand, stillbilder.[22]
Ett mer effektivt sätt att distribuera renderingen är att använda sig av en renderingsmanager. En programvara där man kan styra olika variabler i renderingen för att optimera den efter sina behov. Vid DBR skapas det mycket ”overhead” från nätverkstrafiken dels eftersom regionerna som renderas är förhållandevis små och dels eftersom kontakt måste bibehållas med arbetsdatorn. Paket skickas därför konstant över en switch som delas av slutanvändarna. Vid nätverksrendering över en renderingmanager kan man ange en större storlek på regionerna som noderna ska rendera och här tar istället programvaran över kontrollen av renderingen. Detta gör dels att man helt kan avlasta sin arbetsdator och det minskar även nätverksbelastningen eftersom noderna endast behöver ha kontakt med servern när renderingen har startats. Den här sortens rendering är särskilt användbar vid rendering av animationer men är också ett alternativ till DBR av stillbilder och kallas då ”split scanline-”, ”strip-” eller ”tile-rendering”.[23]
Två olika sorters nätverksrendering:
Bild 1
4 Val av hårdvara
För att skapa renderingsfarmen fick jag en budget på 35 000 kr. 10 000 kr av budgeten undanhöll jag för kostnader av mjukvara. Istället för att köpa färdiga datorer som innehåller många komponenter som är överflödiga för en renderingsnod valde jag ut de olika komponenter som noderna skulle bestå av och genom att montera ihop dem på egen hand kunde jag lägga mer pengar på hårdvarans prestanda. Utöver kostnaden för själva noderna och deras programvara behövde jag även inhandla en switch för att koppla ihop farmen med nätverket. Alla val är gjorda med framtida uppgraderingar i åtanke.
4.1 CPU
Den viktigaste komponenten på en renderingsnod är CPU:n eftersom det är den som kommer att utföra renderingen. Eftersom 3D-grafikernas arbetsdatorer använder Intel I7 processorer ville jag använda en processor som bygger på samma generella struktur för att undvika oförutsedda avvikelser i hur arbetsdatorernas och renderingsnodernas processorer renderar en bild.
Hyperthreading[13] används med fördel vid rendering av bilder vilket därför bör stödjas av processorn.
Integrerad grafik och låg strömförbrukning är egenskaper som minimerar kostnaderna per nod.
”Xeon” är en Intel processor som bygger på samma mikroarkitektur (Nehalem) som I7 processorn men är avsedd för servrar och är en perfekt kandidat för att användas i en renderingsfarm. Fördelar är bl.a. att den drar mindre energi samt att den kan monteras på ett moderkort med stöd för dubbla processorer.[11]
Nackdelen är priset vilket fick mig att undersöka andra alternativ. För att få ut högsta prestanda i relation till pris föll därför valet på andra generationens Intel I7 processor.[12]
Val av Hårdvara/Mjukvara
5
4.2 RAM
För att tillgodose processorn med tillräckligt RAM-minne vid rendering räcker det rimligtvis med 1 - 2 GB minne per processorkärna, desto mer komplex en rendering är desto mer minne kommer det å andra sidan att behövas. Jag valde att överdimensionera och installera 16 GB per nod för att vara säker på att noderna inte kommer att behöva använda sig av en växlingsfil på hårddisken, vilket skulle ha en negativ påverkan på renderingshastigheten. Mängden minne är även tillräcklig för att klara av en eventuell uppgradering av processorn.
4.3 HDD
Hårddisken var ett område där jag kunde spara in pengar eftersom det fanns kasserade datorer på företaget vars diskar jag kunde använda. 80 GB SATA hårddiskar är tillräckligt för syftet eftersom de endast ska hålla operativsystem och den mjukvara som tidigare har nämnts. Läshastigheten påverkar därför endast boot-tiden av operativsystemet samt starttiden av de installerade programmen vilket i sammanhanget är försumbara tider som inte rättfärdigar en investering i ssd-diskar.
4.4 Moderkort
Val av moderkort dikteras av processorns sockel, vilket i det här fallet är LGA 1155.[14]
Eftersom jag valde en processor med integrerad grafik behövde moderkortet också ha en bildskärmsanslutning för att dra nytta av detta. Andra egenskaper som jag ville att moderkortet skulle ha är integrerad nätverkskontroller med wake-on-lan för att kunna fjärrstarta noderna samt dubbla pci-e anslutningar för eventuell GPU-baserad rendering. Jag ville också att det skulle få plats i ett minitower- chassi. Därför föll valet på ett mATX-kort från Asus.[15]
4.5 Chassi
Eftersom det inte finns gott om utrymme i serverrummet där farmen ska stå ville jag minimera platsen som tas upp av noderna samtidigt som deras skal ger utrymme för att installera eventuella grafikkort eller kraftigare kylning i framtiden. Därför passade ett minitower chassi med medföljande PSU bäst in i min budget.[16]
4.6 Kylning
Den medföljande fläkten till processorn kunde inte hålla temperaturen under det gränsvärde som Intel anger i sin dokumentation (73° C)[25]. Eftersom den här gränsen är väl tilltagen och för att processorn är designad för vanliga arbetsdatorer är det ett förståeligt resultat. Men eftersom noderna kommer arbeta på 100 % av sin kapacitet längre tider och deras stabilitet är mycket viktig var det därför nödvändigt att köpa kraftigare kylning. Med den nya kylaren går temperaturen sällan över 50° C.
4.7 Switch
För att koppla ihop noderna med nätverket behövdes en switch, jag valde en “unmanaged” 16-ports gigabit switch pga. det lägre priset. Management av nätverkstrafiken behövs inte i det första ledet och 16 portar ger utrymme för utökning av farmen.
(Specifikationer för all hårdvara finns i bilaga 1)
5 Val av mjukvara
De program som används för rendering styr valet av operativsystem, Linux var uteslutet eftersom det inte har stöd för dessa program och eftersom företaget genomgripande använder Windows och för närvarande är i processen av att uppgradera från Windows XP till Windows 7 var det naturliga valet att installera Windows 7 på noderna. För att underlätta administration, felsökning, kontroll av energiförbrukning samt för att öka användarvänligheten och ge möjligheten till effektivare rendering valde jag att låta en renderingsmanager styra farmen. Det finns många olika sådana på marknaden[26] och efter att ha undersökt deras för- och nackdelar testade jag de mest lovande kandidaterna. Den som stod ut
bland mängden var ”Deadline Render Management System” pga. sitt intuitiva gränssnitt och välutvecklade stöd för olika 3d-program.
5.1 Deadline
Deadline är ett kö- och managementsystem för nätverksrendering med stöd för den programvara som Whites 3D-grafiker använder. Deadlines huvuddelar är en monitor som installeras på arbetsdatorerna, en slavapplikation som installeras på noderna och en mapp på filservern, ”Deadline Repository”, dit renderingsnoderna läser och skriver för att kunna organisera sig och arbeta som en grupp.[17]
Deadline ger också möjligheten att integrera överlämnandet av renderingar till farmen i de olika 3D- programmen som används vilket ökar användarvänligheten. Deadline kan också konfigureras för att starta och stänga av noderna efter behov för att spara energi och monitorn finns även som en applikation till Android- och Iphone-mobiltelefoner.[24]
6 Konfiguration
6.1 Renderingsnod
Efter montering av den första renderingsnoden som jag senare använde till att utföra tester på startade jag upp den och gick in i moderkortets EFI BIOS[18] och stängde ner de funktioner som noden inte gör användning av som t.ex. HD audio. Jag ställde in den för att använda sig av PXE boot[27] vid start för att installera operativsystemet från företagets deploymentsystem. Efter att ha installerat Windows 7 och fört in noden i en egen grupp i företagets domän stängde jag ner de Windowstjänster som är onödiga att köra på en renderingsnod. (Se bilaga 2)
VRay, den huvudsakliga renderingsmotorn som används går att installera som en renderingsslav. Det gäller både för Vray for Rhino[19] och VRay for 3ds Max.[20] För varje licens man har av VRay får man använda upp till tio slavmaskiner. Jag installerade de här två programmen och såg till så att de kunde kommunicera med licensdatorerna. Jag installerade också 3ds Max, Rhino och After Effects samt Deadline (Deadline Slave) på noden och också en gratis programvara för att mäta CPU-temperaturer.[21]
3ds Max och After Effects går att installera utan att aktiveras så att man slipper betala en licens på varje renderingsnod. De har tagit hänsyn till användare med en renderingsfarm och gjort det möjligt att köra programmen i ett renderingsläge utan licens. Utvecklarna av Rhino 3d har tyvärr inte gjort det och det skulle därför krävas en licens på varje nod för att installera deras programvara. Därför uteslöt jag Rhino från att rendera över Deadline och användarna får istället endast använda sig av DBR.
Jag konfigurerade Windows, genom registerinställningar[28], till att logga in automatiskt vid uppstart och autostarta renderingsprogrammen. Jag såg också till så att de nödvändiga resurserna på nätverket fanns tillgängliga vid uppstart samt konfigurerade noderna med fast IP-address.
6.2 Nätverk
För att neka tillträde till Internet för noderna och för att segmentera farmen på nätverket skapade jag ett nytt vlan[29] och blockerade även noderna i företagets brandvägg. Jag konfigurerade även licensservern för fem av Deadlines slavlicenser.
6.3 Felsökning och finjustering
Vid de första testrenderingarna saknades texturer vid DBR. Anledningen till att texturer kan saknas trots att de är placerade på filservern är att VRays DBR är känslig för sökvägar med mappade partitioner.
Därför behöver man göra om sökvägarna till UNC innan man renderar över nätverket.[30]
Konfiguration
7
Vid tile rendering över Deadline kunde man urskilja synliga linjer mellan de renderade regionerna:
Bild 2
Bild 3
Anledningen är att ljuset i en region påverkas av ljuset i en annan. Det här är ett problem som uppstår när man använder sig av tile rendering och existerar inte i DBR. Lösningen är att först beräkna ljuset (”Irradiance map” och ”Light cache”) för hela bilden vilket måste göras på endast en dator och sen placera dessa filer på servern och låta noderna hämta ljusinställningarna från dessa filer. Man behöver också använda ”pixel padding” vilket betyder att varje region renderar ett antal pixlar utanför den angivna regionen för att sedan kunna smälta ihop regionerna på ett bättre sätt, sammansättningen av regionerna görs automatiskt av Deadline men kan även göras manuellt. Antalet regioner som man renderar kan också ha en viss inverkan på tiden som går åt till rendering.
Eftersom en viss region kan ta avsevärt längre tid än en annan är det en bra idé att dela upp bilden i fler regioner än vad man har noder så att noderna inte står sysslolösa och väntar på att den tyngsta regionen ska renderas färdigt. Därför bör man dela upp en bild i minst 2 gånger antalet noder.
Statistik från Deadline:
Bild 4
7 Resultat
Det snabbaste sättet att rendera på är av naturliga skäl DBR, eftersom man använder både renderingsfarmens och sin egen arbetsdators processorkraft. En scen som tidigare renderades på 8 timmar och 20 minuter på en av 3D-grafikernas datorer renderas nu på 2 timmar med DBR och på 2 timmar och 10 minuter över Deadlines tile rendering. Vi gjorde även ett test med den absolut högsta inställningen man kan ha i VRay för att jämföra mellan arbetsdator och renderingsfarm:
Resultat renderingsfarm, 12 timmar 20 min
Bild 5
Resultat/Slutsats/Fortsatt arbete
9
Resultat lokal rendering, ca 13 -14 timmar
Bild 6
Som vi kan se så klarade inte arbetsdatorn av att göra denna rendering utan kraschade programmet med mindre än 50 % renderat.
8 Slutsats
Tidsvinsten är påtaglig vid användning av nätverksrendering, renderingsfarmen består av fem noder och har en prislapp som är långt under kommersiella produkter med snarlik prestanda. Den ledande försäljaren av liknande hårdvarulösningar har en prislapp som är ca 40 % över hårdvaran för min farm samtidigt som prestandan hos deras system är lägre. [31]
Den ökade beräkningskraften ger grafikerna möjligheten att skapa skarpare bilder och bidrar till utvecklingen av nya och mer avancerade former av visualisering. Den andra stora fördelen är att grafikern kan fortsätta använda sin arbetsdator till det den är menad för, inte rendering utan kreativt skapande.
9 Fortsatt arbete
Det finns många funktioner som kan läggas till genom Deadline som jag inte har haft tid att konfigurera, så som ”power management” och stöd för smart phones. Eftersom teknikutvecklingen går så snabbt kommer det också alltid finnas en anledning till att uppgradera hård- och mjukvara och anpassa lösningen till ny teknik. Det skulle också vara av intresse att automatisera de moment som måste göras av 3d- grafikern vid inställning av nätverksrendering för att underlätta förfarandet. Det kan göras genom antigen Python[32] med hjälp av Deadline eller med MaxScript[33] i 3d Studio Max.
Referenser
[1] http://www.cs.princeton.edu/courses/archive/fall02/cs526/lectures/global.pdf [2] http://en.wikipedia.org/wiki/Ray_tracing_(graphics)
[3] http://en.wikipedia.org/wiki/Radiosity_(3D_computer_graphics) [4] http://usa.autodesk.com/3ds-max/
[5] http://en.wikipedia.org/wiki/Non-uniform_rational_B-spline [6] http://www.rhino3d.com/
[7] http://www.adobe.com/products/aftereffects.html [8] http://www.chaosgroup.com/en/2/index.html [9] http://www.randomcontrol.com/arion [10] http://blog.renderstream.com/?p=442 [11] http://www.cpu-world.com/CPUs/Xeon/
[12] http://www.sweclockers.com/recension/13224-intel-sandy-bridge-core-i7-2600k-core-i5-2500k [13] http://www.intel.com/technology/platform-technology/hyper-threading/
[14] http://en.wikipedia.org/wiki/LGA_1155
[15] http://www.asus.com/Motherboards/Intel_Socket_1155/P8P67_PRO/
[16] http://www.antec.com/pdf/manuals/NSK3480_manual_EN.pdf [17] http://www.thinkboxsoftware.com/deadlineoverview/
[18] http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Evolution-of-BIOS-EFI-the- Framework-and-beyond/
[19] http://software.asgvis.com/index.php?option=com_content&view=article&id=296&Itemid=233 [20] http://www.vray.com/vray_for_3ds_max/
[21] http://www.techpowerup.com/realtemp/
[22] http://vray.us/vray_documentation/vray_distributed_rendering.shtml [23] http://forums.cgsociety.org/archive/index.php/t-626688.html [24] http://www.thinkboxsoftware.com/deadline-feature-set/
[25] http://www.intel.com/support/processors/pentium4/sb/cs-007999.htm
[26] http://joomla.renderwiki.com/joomla/index.php?option=com_content&view=article&id=161&Ite mid=85
[27] http://sv.wikipedia.org/wiki/Preboot_Execution_Environment
[28] http://www.computerperformance.co.uk/windows7/windows7_auto_logon.htm [29] http://sv.wikipedia.org/wiki/VLAN
[30] http://vray.info/tutorials/vray_distributed_rendering_and_backburner/part3.asp [31] http://www.bhphotovideo.com/c/product/673189-
REG/BOXX_Technologies_86898_renderBOXX_10300_Dedicated_Rendering.html [32] http://www.python.org/
[33] http://www.3dtrue.com/max/2.html
* Länkar kontrollerade juni 2011
Bilaga 1 – Hårdvaruspecifikationer
RENDERINGSNOD:
Processor:
INTEL CORE I7 2600K 3.40GHZ 8MB S-1155
Moderkort:
ASUS P8P67 PRO
CPU-kylare:
COOLER MASTER HYPER 212 PLUS
Ram:
CORSAIR 8GB DDR3 XMS3 INTEL I5/I7 PC10666 1333MHZ (2X4GB)
Chassi:
ANTEC NSK3480 380W SILVER/BLACK MICROTOWER
SWITCH:
HP PROCURVE SWITCH 1410-16G
PROCESSOR I 3D-GRAFIKERNAS ARBETSDATORER:
INTEL I7 920 2,67GHZ
Bilaga 2 – Avstängda windowstjänster
Application layer gateway service Windows audio endpoint builder Windows audio
BitLocker Drive Encryption Service Bluetooth Support Service
Certificate Propagation Smart Card
Smart Card Removal Policy Adaptive Brightness BranchChache
Desktop Window Manager Session Manager Themes
Print Spooler Protected storage
Quality Windows Audio Video Experience Tablet PC Input Service
Telephony WebClient
Windows Biometric Service Windows Search
Windows Media Player services, receiver scheduler and network sharing Windows error reporting
Windows update
Bilaga 3 – Bild på renderingsfarm
En bild på renderingsfarmen uppställd i serverrummet hos White Arkitekter Göteborg:
