Ik zit met een probleem waarbij ik elke monitor refresh een update moet uitvoeren op een gerenderde scene. Het punt is dat het renderen van een frame soms/meestal langer duurt dan een monitor refresh cycle. (ie. 100Hz -> 10ms, frame rendering bv 30ms). Nou is de standaard GPU pipeline gewoon sequentieel, en kan ik niet elke 10ms die update uitvoeren, en tegelijkertijd in de achtergrond de frame renderen. (elke 10ms update frame, en als bv na 50ms de nieuwe frame klaar is dan switch ik) Is er een manier met moderne hardware om twee dingen echt tegelijk te renderen? Voor zover ik weet is SLI geen oplossing, omdat er dan nog steeds maar 1 pipeline is, alleen met meerdere vertex/pixel units. Kan ik twee videokaarten laten samenwerken dat ze elkaar buffers kunnen gebruiken? Eentje rendered rustig naar een hardware back buffer, de andere doet elke 10ms een update op de front buffer, en als de eerste klaar is worden de buffers geswitched.
Als je hier gewoon twee threads voor gebruikt ("back buffer" en "front buffer" threads) lijkt me dat zolang de "front buffer" thread sleeping is tot een vsync de "back buffer" thread gewoon CPU èn GPU processortijd krijgt. Ik denk niet dat je daar 2 videokaarten voor nodig hebt net zoals je ook meerdere processen op 1 CPU kunt draaien.Zoijar schreef op dinsdag 04 april 2006 @ 11:42:
... Kan ik twee videokaarten laten samenwerken dat ze elkaar buffers kunnen gebruiken? Eentje rendered rustig naar een hardware back buffer, de andere doet elke 10ms een update op de front buffer, en als de eerste klaar is worden de buffers geswitched.
Je moet gebruik maken van de cached en pas de cache invalide maken op moment dat je klaar bent met renderen. Dan doet de video kaart dit automatischZoijar schreef op dinsdag 04 april 2006 @ 11:42:
Ik zit met een probleem waarbij ik elke monitor refresh een update moet uitvoeren op een gerenderde scene. Het punt is dat het renderen van een frame soms/meestal langer duurt dan een monitor refresh cycle. (ie. 100Hz -> 10ms, frame rendering bv 30ms). Nou is de standaard GPU pipeline gewoon sequentieel, en kan ik niet elke 10ms die update uitvoeren, en tegelijkertijd in de achtergrond de frame renderen. (elke 10ms update frame, en als bv na 50ms de nieuwe frame klaar is dan switch ik) Is er een manier met moderne hardware om twee dingen echt tegelijk te renderen? Voor zover ik weet is SLI geen oplossing, omdat er dan nog steeds maar 1 pipeline is, alleen met meerdere vertex/pixel units. Kan ik twee videokaarten laten samenwerken dat ze elkaar buffers kunnen gebruiken? Eentje rendered rustig naar een hardware back buffer, de andere doet elke 10ms een update op de front buffer, en als de eerste klaar is worden de buffers geswitched.
Backup not found (R)etry (A)bort (P)anic<br\>AMD 3400+ 64, 2 GB DDR, 1,5 TB Raid5
Wat ook kan:
De video kaart kan een groter beeld aan dan wat je ziet. De negative y range kan een videokaart gewoon gebruiken. Je kan in de negative y je rendering doen (gebruik makend van de gpu) en dan als je klaar bent de buffer van negative y naar positive y transleren.
De video kaart kan een groter beeld aan dan wat je ziet. De negative y range kan een videokaart gewoon gebruiken. Je kan in de negative y je rendering doen (gebruik makend van de gpu) en dan als je klaar bent de buffer van negative y naar positive y transleren.
Backup not found (R)etry (A)bort (P)anic<br\>AMD 3400+ 64, 2 GB DDR, 1,5 TB Raid5
Een GPU is niet multi threadable. Maw, wanneer ik een opdracht geef om iets te renderen dat 50ms duurt en meteen daarna voor iets dat 10ms duurt, dan begint de GPU pas aan dat stukje van 10ms nadat de gehele 50ms klaar zijn (uit de pipeline). Ik _moet_ elke 10ms iets renderen, maar ik moet ook nieuwe frames maken die 50ms duren. Meteen op het moment dat ik begin met renderen van de 50ms frame krijg ik pas weer control na 50ms en mis ik dus 5 updates.
Het is trouwens niet het double buffering probleem, dat kan je GPU idd zelf. Maar ik moet elke monitor frame (10ms) het beeld aanpassen, en tegelijkertijd nieuwe frames maken (50ms). Stel bv dat je een counter wilt afbeelden met het monitor frame nummer. Als het renderen van de counter maar 5ms duurt is het simpel: verhoog de counter, render hem naar je backbuffer, en roep swapbuffers aan; de volgende monitor frame staat er dan een verhoogde counter op je beeld. Maar stel nu dat je onder deze counter nog een object afbeeld dat 20ms duurt om te renderen. Dan kan je dat tweede object maar eens per 2 monitor frames updaten. Dat is op zich niet erg, maar je kan dus niet _tussendoor_ steeds die counter ook renderen (met 1 videokaart). Nou vroeg ik me af of SLI hier een speciale modus voor biedt, of dat je op een andere manier 2 kaarten kan laten samenwerken.
Het is trouwens niet het double buffering probleem, dat kan je GPU idd zelf. Maar ik moet elke monitor frame (10ms) het beeld aanpassen, en tegelijkertijd nieuwe frames maken (50ms). Stel bv dat je een counter wilt afbeelden met het monitor frame nummer. Als het renderen van de counter maar 5ms duurt is het simpel: verhoog de counter, render hem naar je backbuffer, en roep swapbuffers aan; de volgende monitor frame staat er dan een verhoogde counter op je beeld. Maar stel nu dat je onder deze counter nog een object afbeeld dat 20ms duurt om te renderen. Dan kan je dat tweede object maar eens per 2 monitor frames updaten. Dat is op zich niet erg, maar je kan dus niet _tussendoor_ steeds die counter ook renderen (met 1 videokaart). Nou vroeg ik me af of SLI hier een speciale modus voor biedt, of dat je op een andere manier 2 kaarten kan laten samenwerken.
SLI werkt idd niet, maar je kunt de kaarten ook afzonderlijk van elkaar aanspreken. Een andere mogelijkheid is misschien een eigen scan line interleaving scheme. Gewoon de hoogte van je buffer bijvoorbeeld door x (in N) delen, en dan met een stretch blit de rest uitrekken. Als je elke frame je camera exact een beeldlijn verplaatst render je bovendien steeds interleaving scanlines, die je uiteindelijk weer bij elkaar kunt voegen om een heel beeld te krijgen. Kun je daar niets mee?
(Hou er trouwens rekening mee dat die timings helemaal niet zo gegarandeerd zijn. Niemand zegt dat als jij een glFinish oid doet dat de frame dan ook echt klaar gaat zijn, huidige hardware heeft de neiging een aantal frames vooruit de bufferen. In games iig, hoe het in jouw situatie is weet ik natuurlijk niet precies
. Het is wel af te vangen, bijvoorbeeld door pixels te gaan opvragen (dan moet ie wel klaar zijn met renderen), maar dan kun je rekenen op behoorlijke stalls)
(Hou er trouwens rekening mee dat die timings helemaal niet zo gegarandeerd zijn. Niemand zegt dat als jij een glFinish oid doet dat de frame dan ook echt klaar gaat zijn, huidige hardware heeft de neiging een aantal frames vooruit de bufferen. In games iig, hoe het in jouw situatie is weet ik natuurlijk niet precies
[ Voor 15% gewijzigd door .oisyn op 04-04-2006 14:53 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ja ik dacht ook al aan zo iets. Even voor de duidelijkheid, je bedoelt nu dat ik de grote frame van 50ms dus als het ware ophak in zeg 10 render stukjes die elk bv 7ms duren, toch? En dan eens in de zoveel tijd die buffers bij elkaar pak om een nieuwe frame te maken. Probleem is dat het me erg complex lijkt, en misschien niet makkelijk te integreren met bestaande systemen... het liefste knal ik er gewoon twee quadro kaarten in met wat buffer synchronizatie..oisyn schreef op dinsdag 04 april 2006 @ 14:51:
SLI werkt idd niet, maar je kunt de kaarten ook afzonderlijk van elkaar aanspreken. Een andere mogelijkheid is misschien een eigen scan line interleaving scheme. Gewoon de hoogte van je buffer bijvoorbeeld door x (in N) delen, en dan met een stretch blit de rest uitrekken. Als je elke frame je camera exact een beeldlijn verplaatst render je bovendien steeds interleaving scanlines, die je uiteindelijk weer bij elkaar kunt voegen om een heel beeld te krijgen. Kun je daar niets mee?
Heb ik aan gedacht ja. Dwz, het probleem is in me opgekomen, maar heb geen duidelijke oplossing. Occlusion query kwam meteen in me op om te wachten tot de pipeline leeg is. Dat vertraagt de boel natuurlijk wel. Weer lijken twee kaarten me ideaal als ik een signaal kan krijgen wanneer de front buffer veranderd is, dan leest de 2e kaart deze uit in zijn eigen interne render buffer en gaat weer lekker elke 10ms updates doen. Maar ik weet dus niet hoe.(Hou er trouwens rekening mee dat die timings helemaal niet zo gegarandeerd zijn. Niemand zegt dat als jij een glFinish oid doet dat de frame dan ook echt klaar gaat zijn, huidige hardware heeft de neiging een aantal frames vooruit de bufferen. In games iig, hoe het in jouw situatie is weet ik natuurlijk niet precies. Het is wel af te vangen, bijvoorbeeld door pixels te gaan opvragen (dan moet ie wel klaar zijn met renderen), maar dan kun je rekenen op behoorlijke stalls)
Hoewel die stall misschien niet eens erg is, aangezien frame N+1 toch frame N nodig heeft. Mijn probleem is equivalent aan steeds het verschil tussen (monitor) frame N en N+1 te moeten renderen. Als het beeld gelijk blijft, dan is N+1 iets anders dan N, en op zijn beurt moet N+2 dus weer iets anders zijn dan N+1. Zo krijg je een reeks van verschillende beelden per monitor frame. Op het moment dat er een nieuw beeld (render frame) klaar is, moet die gebruikt worden.
Sorry voor de slechte uitleg, maar ik ben nog een beetje aan het brainstormen over oplossingen. Het is een zuiver parallel probleem. Een oplossing is om virtuele threading op een GPU te implementeren... maar dat zie ik niet zo zitten. Wordt ook te traag lijkt me. (wel een mooi paper misschien, hmmm...
[ Voor 1% gewijzigd door Zoijar op 04-04-2006 15:16 . Reden: d's en t's drama... ]
Pagina: 1