[C#] Multi-threading

[Mischa_NL]

Hallo allemaal.

Sinds vandaag ben ik in de wondere wereld van threads gedoken maar een aantal punten worden mij niet helemaal duidelijk:

Ik heb een XNA game en tijdens mijn update() update ik alleen als ik gelopen heb. Dit doe ik via een aparte thread.
Nu kan ik dat op 2 manieren realiseren: De thread in een while loop zetten en dmv set() en Waitone() controleren. Of ik kan de thread iedere keer opnieuw aanmaken. Ikzelf dacht aan het eerste.

Ik heb een stukje code geschreven maar ik gok dat het helemaal omslachtig is dus hier als volgt:

code:

    public int ClipCount = 10;

    struct clipmap
    {
        ClipStream stream;
    }

    init_app()
    {
         Clips = new clipmap[10];
         for (i = 0; i<CipCount;i++)
             Clips[i].stream = new ClipStream();
    }

    frame_update()
    {
        for (int i = 0;i<ClipCount;i++)
        {
            if (conditions met)
            {
                stream[i].wh.set()
            }
        }
    }

    public class ClipStream
    {
        public Thread t;
        public EventWaitHandle wh = new AutoResetEvent(false);

        public ClipStream()
        {
            t = new Thread(new ThreadStart(UpdateThread));
            t.IsBackground = true;
            t.Start();
        }

        public void Update()
        {
            wh.Set();   // let the update thread do its work
        }

        private void UpdateThread()
        {
            while (true)
            {
                Console.WriteLine("test");
                wh.WaitOne();
            }
        }
    }

Hier gebeurt dus het volgende:
ik maak een nieuwe class aan en daarin een nieuwe thread die de update moet verzorgen.
Iedere keer als ik update roep ik de update() aan en deze op zijn beurt laat de thread een keer test schrijven.

Is dit omslachtig of kan het beter?

[MLM]

Ervanuitgaande dat je tussen lijn 47 en 48 ook echt iets doet dat tijd kost, is de setup op zich werkbaar. Maar als je meer clips gaat gebruiken (orde van grootte: duizenden), krijg je wel erg veel threads die moeten starten en stoppen de hele tijd, wat veel overhead gaat opleveren (contextswitches). In dat geval kan je beter overwegen om slechts een paar worker threads te gebruiken die alle clips updaten (indien nodig). Er kunnen nooit meer threads tegelijk draaien dan je cores hebt in je computer, dus meer threads dan dat aantal is niet ideaal (maar nog altijd beter dan minder).

Hoe dan ook, uit jouw voorbeeld is niet veel duidelijk, wat is je huidige performance probleem, en in hoeverre is dat parallelliseerbaar?

Sidenote: Bij een game is het vaak een probleem om goed te multithreaden, je kan bijvoorbeeld niet zomaar vanuit meerdere threads tegelijk renderen (of je levert heel veel performance in, omdat XNA zelf serialized, dat weet ik niet). Ik weet niet wat je exact van plan bent, maar je moet wel nadenken over welke stukken van je code je kan parallelliseren, en hoeveel je dat gaat opleveren.

[Mischa_NL]

Het probleem is dat ik hoogtedata voor elke clipmap moet streamen vanaf harddisk.

Ik render elke clipmap iedere frame, dit zijn er hoogstens 20. Echter kan ik niet de complete hoogtedata in memory stoppen. Daarom wil ik voor iedere clipmap deze data vanaf harddisk streamen op het moment dat de speler beweegt.
Als de stream thread het niet bijhoud, kan ik de resolutie omlaag zetten tot de thread weer bij is, zonder dat dat framerate in elkaar duikelt. Het leek me dus een perfecte oplossing om dit async met de render en update thread te laten lopen!

Tussen 47 en 48 moet dus de data van harddisk gestreamt gaan worden.

[Verwijderd]

kan je niet met een halve seconde vertraging steamen? dan zie je dit soort grensgevallen bijtijds.
dan neem je 1 thread die de data binnenhaalt, en X die hem afspelen

edit:

[ Voor 4% gewijzigd door Verwijderd op 14-10-2009 22:30 ]

[Mischa_NL]

Verwijderd schreef op woensdag 14 oktober 2009 @ 22:26:
kan je niet met een halve seconde vertraging steamen? dan zie je dit soort grensgevallen bijtijds.
dan neem je 1 thread die de data binnenhaalt, en X die hem afspelen

edit:

Afspelen = 1 thread want dat gebeurt door xna. GPU en batchen etc. renderen is MEGAsnel. Updaten is het trage.
Daarom als de update traag wordt hapert de rendering want de gameloop duurt langer. Op het moment dat ik aparte threads gebruik voor de streaming (asynchrone streamclass) is dit probleem weg. Streamer streamt op zijn eigen tempo en zolang hij niet klaar is: no problem.
Margoed is maar een hpyothese ik hoor graag andere oplossingen!

[farlane]

Mischa_NL schreef op woensdag 14 oktober 2009 @ 22:19:
Het probleem is dat ik hoogtedata voor elke clipmap moet streamen vanaf harddisk.
...
Tussen 47 en 48 moet dus de data van harddisk gestreamt gaan worden.

Meerdere threads die tegelijk vanaf disk willen lezen, ik ben bang dat je niet de performance boost krijgt die je verwacht.

[Mischa_NL]

farlane schreef op woensdag 14 oktober 2009 @ 22:45:
[...]

Meerdere threads die tegelijk vanaf disk willen lezen, ik ben bang dat je niet de performance boost krijgt die je verwacht.

nogmaals: ik heb niet de waan dat dat lezen vanaf disk sneller zal gaan. De enige waan die ik heb is om een gedeelte van de update, de stream, te scheiden van de hoofdthread om performance in deze thread niet te beïnvloeden.

overigens denk ik WEL dat er snelheidswinst te behalen valt door dit op te delen in verschillende thread aangezien ze slechts weinig data van disk ophalen en dit ook nog vanuit verschillende bestanden doen! en het lijkt me niet dat mijn applicatie meer dan 15 mb per seonde zal moeten streamen...
minimaal 0, gemiddeld 256*2*10pixels en maximaal 256*256*10.
En ik wil er dus voor zorgen dat die max stream asynchroon loopt, zodat de hoofdthread er geen last van ondervind. Zodra de streamthread het lage-resolutie-terrein gestreamt heeft kan de mainthread verder. de rest mag later komen en op elk moment klaar zijn!

[ Voor 39% gewijzigd door Mischa_NL op 14-10-2009 23:51 ]

[NC83]

(256 * 256 * 10 * 32) / 8 / 1024 / 1024 = 2,5 MB aan data ervan uit gaande dat je 32 bits values per pixel hebt dat hoef je echt niet te streamen.

En waarom zou je niet de low res data laden en dan pas de stream threads in zetten om de high res data op te halen. Daarnaast zou je ook met blocks kunnen werken waardoor je er hier altijd 9 van in het geheugen hebt en de 3 bij streamed die je nodig hebt wanneer de speler zijn huidige block verlaat.

Kun je iedere clipmap zien in iedere frame want anders ben je teveel aan het renderen en dat kost ook tijd.

[ Voor 10% gewijzigd door NC83 op 15-10-2009 10:38 ]

[Niemand_Anders]

Waarom stream je eigenlijk de data naar de harddisk in de eerste plaats? Kun je de data niet in een Memorystream oid plaatsen? Eventueel zou je bij de start van je applicatie de data van de harddisk kunnen lezen en deze slechts periodiek opslaan naar de harddisk of zelfs pas als de applicatie sluit..

[Phyxion]

Als ik het een beetje lees gaat het om heightmaps om een terrein te renderen?

[ Voor 200% gewijzigd door Phyxion op 15-10-2009 12:02 ]

[R4gnax]

Phyxion schreef op donderdag 15 oktober 2009 @ 12:00:
Als ik het een beetje lees gaat het om heightmaps om een terrein te renderen?

Lijkt er idd. wel op. In dat geval is Mischa_NL's probleem thread management noch disc access, maar gewoon een slecht design. Google maar eens op 'paged terrain', Mischa.

[roy-t]

Hoewel er veel oplossingen zijn voor terreindata is dit misschien even leuk om te lezen:

http://www.thezbuffer.com/articles/469.aspx

[.oisyn]

Beetje suf, al die microsoft forum links op die pagina zijn dood.

[Phyxion]

.oisyn schreef op donderdag 15 oktober 2009 @ 14:29:
Beetje suf, al die microsoft forum links op die pagina zijn dood.

Inderdaad, zat net ook al even te kijken.

Misschien makkelijk als TS even aangeeft waar het voor is, want volgens mij is dit wel wat overdone.

[Mischa_NL]

Oke ik zal het even een stuk uitgebreider formuleren:

Ik maak bij mijn terrain rendering gebruik van een aangepaste versie Clipmaps. Voor degenen die er niet bekend mee zijn: http://http.developer.nvi...2/gpugems2_chapter02.html .

Echter snap ik het nut niet om terrain te upsamplen etc of gebruik te maken van residuals. Waarom niet gewoon het terrein in LOD levels op disk opslaan en deze streamen.

Als volgt: ik start de applicatie, en maak een clipmapsysteem aan van 10 clipmaps elk 256*256.
Ik heb dus 10 lodlevels. dat wil dus zeggen textures als volgt:
lod1 - 1 meter per vertex
lod2 - 2 meter per vertex
lod3 - 4 meter per vertex
lod4 - 8 meter per vertex
enzovoort. dit houdt dus in dat ik de hoogste resolutie gewoon kan mipmappen voor lagere resolutie!

stel dat ik de resolutie 1 meter = 1 pixel zou gebruiken dan krijg ik dus het volgende:
lod1 - per vertex = 1 pixel op finest texture - 1 op lodtex
lod2 - per vertex = 2 pixels op finest texture - 1 op lodtex
lod3 - per vertex = 4 pixels op finest texture - 1 op lodtex
lod4 - per vertex = 8 pixels op finest texture - 1 op lodtex

Voor terrein zal dit het meest logisch zijn omdat een hogere resolutie niet te vertalen valt naar vertices. Echter bij textures zal dit wel het geval zijn en kan dus 1 primitive theoretisch een oneindige resolutie hebben (pixel shader). Dit gaat ZEKER een memory probleem worden lijkt me.

Ook is het denk ik onmogelijk om de totale heightmap op te slaan in memory. En ookal is het mogelijk dan lijkt het mij memory verspilling. handiger lijkt het me om slechts op te slaan in memory: voor elk LOD level zijn eigen heightmap, dus altijd 256*256. Dit is uiteraard niet genoeg omdat ik anders alsnog instant moet kunnen streamen bij elke beweging, daarom denk ik dat het inderdaad verstandig is: current tile + omliggende tiles te streamen:

code:

-------------
|   |   |   |
-------------
|   | C |   |
-------------
|   |   |   |
-------------

Op deze manier heb ik altijd de huidige tile + de omliggende tiles gecached. verschuift de speler buiten de huidige tile, dan zal hij in het gunstigste geval 3 tiles moeten gaan streamen en in het ongunstigste (diagonalen) 5 tiles.
Op deze manier heb ik nooit het hele terrein in memory en kan ik dus theoretisch oneindig grote heightmaps maken, zonder te hoeven upsamplen!

Maar het zou goed kunnen dat ik vele malen te ingewikkeld aan het denken ben...

[Phyxion]

Een heightmap ala 256x256 met alleen grijstinten is niet echt groot hoor, en anders is het wel zo klein dat je zoiets makkelijk moet kunnen inladen wanneer je het nodig hebt.

[Mischa_NL]

Phyxion schreef op donderdag 15 oktober 2009 @ 17:18:
Een heightmap ala 256x256 met alleen grijstinten is niet echt groot hoor, en anders is het wel zo klein dat je zoiets makkelijk moet kunnen inladen wanneer je het nodig hebt.

Maar ben ik nou gek of ga je dat terugzien in de frametime wanneer ik dit niet thread?

[ Voor 3% gewijzigd door Mischa_NL op 15-10-2009 17:25 ]

[.oisyn]

Phyxion schreef op donderdag 15 oktober 2009 @ 17:18:
Een heightmap ala 256x256 met alleen grijstinten is niet echt groot hoor, en anders is het wel zo klein dat je zoiets makkelijk moet kunnen inladen wanneer je het nodig hebt.

Nee, maar je hebt dus niet maar 1 zo'n heightmap - elke LOD level patch is zo groot. Dus als je 8 levels hebt, waarbij elk hogere LOD twee keer zoveel detail heeft, dan gaan er dus 256x256 LOD0 patches in een enkel LOD7 patch. En aangezien een LOD patch 256x256 samples bedroeg, heb je dus een totaal detail van 65536x65536 = 4 miljard height samples.

[Mischa_NL]

.oisyn schreef op donderdag 15 oktober 2009 @ 17:30:
[...]

Nee, maar je hebt dus niet maar 1 zo'n heightmap - elke LOD level patch is zo groot. Dus als je 8 levels hebt, waarbij elk hogere LOD twee keer zoveel detail heeft, dan gaan er dus 256x256 LOD0 patches in een enkel LOD7 patch. En aangezien een LOD patch 256x256 bedroeg, heb je dus een totaal detail van 65536x65536 = 4 miljard height samples.

.oisyn held. Zo duidelijk kreeg ik het weer niet verwoord!
En met terrain streaming kan ik het dus beperken tot: 256*256*Cliplevels*9 samples in memory. wat dus voor 10 clips neerkomt op: 5.898.240 samples. Wellicht nog steeds teveel? In dat geval zou ik de patches kleiner kunnen maken dan de cliplevels (bv) 128x128 en slechts een ring van 128 pixels om extra cachen:
(128*4+ 128*8) * 10 * 9 = 138.240 samples!

Echter zal dat dan een afweging worden:
Grotere ring = meer memory, meer cache = goed voor snelle beweging
Kleinere ring = minder memory, minder cache = goed voor langzame beweging

edit/
Terrain is opgeslagen in 32bit heightmaps, dus per sample 32 bit.
Voor de goede gang van zaken zou dat dus zonder cache:
476mb raw data zijn wat constant wordt laten zien op fines detail.
cache ik op LOD level manier 1: 22,5 mb
manier 2 = 0.52mb

Nog een toelichting: zonder streaming is het dus niet te voorspellen hoeveel data je moet gaan inladen, want je weet de mapsize niet. Met streaming is er altijd een vast aantal MB's in cache en de rest verblijft rustig op harddisk.
Voordeel 2 is dat ik dmv deze streaming de data van ver van het camerapunt NIET in hoge resolutie in cache heb. Ik laad de data in op de resolutie die nodig is. Doe je dat niet dan heb je per clip ^2 teveel data per clipmap. het aantal vertices per meter/unit halveert dus ook de hoogtedata die ik ingeladen moet hebben.
Stream ik niet dan zal ik ALLES in finest detail in memory moeten zetten: mega overkill...

Zie ook deze image!

[ Voor 36% gewijzigd door Mischa_NL op 15-10-2009 18:19 ]

[R4gnax]

En dus moet je inderdaad een efficiente manier hebben om terrein gepagineerd in te laden.

Als je dan toch threads wilt gaan gebruiken, gebruik dan twee threads:

Één main thread die rendering, position updates, etc. afhandelt en één thread om background loading van resources van disk naar memory te faciliteren. Vervolgens kan een positie update gebruikt worden om te voorspellen in welke richting de camera zich zal gaan verplaatsen en welke map tiles daarvoor ingeladen moeten worden.

Je kunt dan tijdens het wandelen al beginnen in te laden. Wijzigt je voorspelling, dan stop je met het laden van de huidige resource en laadt je de nieuwe relevante tiles in.

Je zult dan hoogstens een stotter krijgen wanneer de camera zich te snel voortbeweegt of zich ineens de halve kaart over 'teleporteert' o.i.d.

[.oisyn]

Kun je in XNA niet gewoon async van disk lezen (overlapped IO heet dat onder windows)? Dan is die hele loading thread niet nodig. Dat is sowieso handiger, want dan kun je ook meerdere dingen tegelijk laden en kan het OS de loads schedulen voor betere seek times. Het reageren op loading-done-events doe je gewoon dan op een punt in je gameloop, scheelt je ook weer een hoop gezeur met synchronisatie.

Je zult dan hoogstens een stotter krijgen wanneer de camera zich te snel voortbeweegt of zich ineens de halve kaart over 'teleporteert' o.i.d.

Waarom zou je gestotter krijgen? 't Is niet alsof de renderer hoeft te wachten op die data. Als ie er niet is, dan kan het niet gerenderd worden. Daarom is het handig om de laagste LOD(s) wel altijd helemaal ingeladen te hebben, zodat je een fallback hebt.

[ Voor 9% gewijzigd door .oisyn op 16-10-2009 11:36 ]

[Phyxion]

.oisyn schreef op vrijdag 16 oktober 2009 @ 11:35:
Kun je in XNA niet gewoon async van disk lezen (overlapped IO heet dat onder windows)? Dan is die hele loading thread niet nodig. Dat is sowieso handiger, want dan kun je ook meerdere dingen tegelijk laden en kan het OS de loads schedulen voor betere seek times. Het reageren op loading-done-events doe je gewoon dan op een punt in je gameloop, scheelt je ook weer een hoop gezeur met synchronisatie.


[...]

Waarom zou je gestotter krijgen? 't Is niet alsof de renderer hoeft te wachten op die data. Als ie er niet is, dan kan het niet gerenderd worden. Daarom is het handig om de laagste LOD(s) wel altijd helemaal ingeladen te hebben, zodat je een fallback hebt.

Zit wel in C# (Voorbeeld), dan moet het in XNA ook kunnen.

[roy-t]

Phyxion schreef op vrijdag 16 oktober 2009 @ 11:48:
[...]

Zit wel in C# (Voorbeeld), dan moet het in XNA ook kunnen.

In XNA lees je niet letterlijk van disk maar gebruik je een (custom) ContentManager (standaard aangemaakt als Content) die bestanden voor je laad. Je zou waarschijnlijk wel een appart thread hiervoor kunnen starten die uit een queue van 'te laden bestanden' leest. Vergeet ook niet te ontladen. (Vooral als je ook naar de Xbox 360 wilt omdat er daar maar 1 generatie is in de garbagecollector van het compact framework).

Dus is kijken wat er gebeurt als je Content.Load<>() in een appart threadje zet .

[Phyxion]

roy-t schreef op vrijdag 16 oktober 2009 @ 13:39:
[...]


In XNA lees je niet letterlijk van disk maar gebruik je een (custom) ContentManager (standaard aangemaakt als Content) die bestanden voor je laad. Je zou waarschijnlijk wel een appart thread hiervoor kunnen starten die uit een queue van 'te laden bestanden' leest. Vergeet ook niet te ontladen. (Vooral als je ook naar de Xbox 360 wilt omdat er daar maar 1 generatie is in de garbagecollector van het compact framework).

Dus is kijken wat er gebeurt als je Content.Load<>() in een appart threadje zet .

Klopt maar het is zeker wel mogelijk. Beetje zoeken en er staan zelfs wel een aantal geschikte writers voor XNA. Het is dan wel write maar read zal niet dermate anders zijn dat het niet te doen is.

[roy-t]

Phyxion schreef op vrijdag 16 oktober 2009 @ 15:17:
[...]

Klopt maar het is zeker wel mogelijk. Beetje zoeken en er staan zelfs wel een aantal geschikte writers voor XNA. Het is dan wel write maar read zal niet dermate anders zijn dat het niet te doen is.

Ja het is mogelijk, (gewoon met de standaard readers en writers uit het .net framework) maar dan moet je via MSBUILD at runtime nog je data files compilen, makkelijker is gewoon je resources aan je project toe te voegen, ze te laten 'compilen' en ze dan te laden met de contentmanager en op de xbox heb je onder XNA geen toegang tot de hardeschijf en MSBUILD.

Ik kan me ook voorstellen dat er wat nieuwe writers en readers gewrapped zijn om XNA's functionaliteit heen, maar als deze volledig compatible zijn dan is het dus niet meer dan een wrapper .

[Mischa_NL]

Het coordinatensysteem voor welke imagechunks te laden heb ik reeds voor elkaar en is een kwestie van enkele regels! Echter nu komt dus het laden zelf.

Het werkt nu als volgt: er blijft per clipmap een eigen thread lopen. Opzich is dit niet verkeerd lijkt me: clipmaps zullen er hoogstens 10 a 15 zijn en hoewel men niet zoveel hdware treads heeft op het moment maakt het natuurlijk geen bal uit als de threads op dezelfde processor lopen!

Bij de prerender (voor elke frame 1 keer aanroepen) roep ik de update functie aan, en deze gaat streamen. Het enige wat nog niet werkt is: als de updat eniet klaar is en ik update weer weet ik eerlijk gezegd niet wat er gebeurd!

Hetgeen wat ik nu ga doen is een heightmap maken met verschillende LOD levels! Mijn idee is om ze in png op te slaan ivm ruimtebesparing.

Voor textures wil ik hetzelfde doen echter wil ik dan alleen de alphamaps op gaan slaan en op de een of andere manier in runtime deze samenstellen, ivm ruimtebesparing!

[NC83]

Die content manager die je noemt is niet meer dan een data lader van disc in XNA hoor. Dat je zelf geen code hoeft te schrijven om van disc bestanden op te halen wil niet zeggen dat dat niet in de back ground gebeurd. Daarnaast is die hele content pipeline te customizen.
De hele reden waarom je data eerst naar een ander formaat wordt omgezet is omdat XNA, dan niet te veel processing op de data hoeft uit te voeren om het te gebruiken. MAX, obj en dergelijke files zijn perfect om model data op te slaan maar heel erg slecht vanuit een runtime perspectief. Om beter load performance te krijgen transformmeer je je data bestanden naar een formaat dat sneller laad en dit is precies wat de content pipelin in XNA doet.

[roy-t]

Ik weet prima wat een content pipeline is en hoe de XNA versies daar van werken, behalve op de 360 kun je prima het wiel opnieuw uitvinden, maar waarom zou je? Verder gaat dit niet meer over het probleem van de TS, dus laten we daar even naar terug gaan, ik laat me zelf nu ook te veel afdwalen.

[ Voor 80% gewijzigd door roy-t op 17-10-2009 10:54 ]