Uendelig treg rendering av grafikk i SDL (MAC)

[Gjest]

Hei.

 

Jeg har nylig prøvd å overføre SDL prosjektene mine over til mac. Programmerer i C og bruker gcc til kompilering. Men når jeg kompilerer så tegner den grafikken så utrolig sakte. Det tar ca en halvtime å tegne en 50x50 px kvadrat f.eks.. Er det noen som har en ide på hva problemet er? På Windows/Linux, så tar tegningen bare et sekund (eller mindre).

 

 

Takk

[LonelyMan]

lol

 

Bustebart, selv et sekund er ekstremt mye for et 50x50 kvadrat. Jeg kan tegne et 1920x1200 kvadrat 200 ganger i sekundet ved et helt vanlig forsøk uten noen form for optimalisering. Om du bruker et sekund eller rundt der på å tegne 50x50 kvadrat da burde du vurdere om du skal trekke deg fra programmering, eventuelt bytte bibliotek.

Endret 12. oktober 2012 av LonelyMan

[LonelyMan]

Klikk venstre musknapp for å tegne kvadrat.

Kvadrat.rar

[GeirGrusom]

GDI

[LonelyMan]

Bitblittingen er GDI men kvadratrutinen har jeg skrevet selv, og jeg skrev den på 1 minutt, uten optimalisering.

 

Om du bruker GDI til å tegne kvadrater vil det gå mye saktere.

Endret 12. oktober 2012 av LonelyMan

[LonelyMan]

Forsøker ikke å være ekkel, men om det tar noe som 900 millisekunder for et 50x50 pixel så er noe alvorlig galt eller de som skrev rutinene må ha blitt slått kraftig i hodet med noe hardt. Du utnytter omtrent 0.3% av prosessoren om du tegner så sakte.

Endret 12. oktober 2012 av LonelyMan

[GeirGrusom]

Forsøker ikke å være ekkel, men om det tar noe som 900 millisekunder for et 50x50 pixel så er noe alvorlig galt eller de som skrev rutinene må ha blitt slått kraftig i hodet med noe hardt. Du utnytter omtrent 0.3% av prosessoren om du tegner så sakte.

Burde i utgangspunktet ikke bruke CPU-en til å tegne grafikk, men dersom man skal gjøre det, så er SDL et mye bedre valg enn GDI (som er et legacy Windows API). Skal man gjøre det riktig så bruker man GPU-en til dette, ikke CPU-en.

 

edit: TS kan kanskje vise oss noe kode, så har vi noe å gå etter.

Endret 12. oktober 2012 av GeirGrusom

[LonelyMan]

Det er feil at man skal bruke gpu'en til dette, man skal bruke cpu'en for å opprettholde kompatibelt program. Bruker du gpu'en så er det ikke like mye kompatibelt. Og direct3d er ikke alltid raskere, den er som regel kun raskere på komplekse grafiske operasjoner, ikke på simple grafiske operasjoner. Jeg har sett tilfeller hvor cpu'en gjør en raskere jobb. Men det viktigste er å opprettholde det kompatibelt. Det er derfor vi har GDI til å begynne med. Du kan bruke GDI+ hvis du vil også, men noen operasjoner er raskere i GDI enn i GDI+. I generelle programmer skal man styre unna gpu, med mindre det er et komplekst grafisk program. Vil forøvrig nevne at GDI benytter seg av endel hardware aksellerasjon, men denne aksellerasjonen er kompatibelt med de fleste grafikkkort, om ikke alle.

Endret 12. oktober 2012 av LonelyMan

[GeirGrusom]

Det er feil at man skal bruke gpu'en til dette, man skal bruke cpu'en for å opprettholde kompatibelt program. Bruker du gpu'en så er det ikke like mye kompatibelt. Og direct3d er ikke alltid raskere, den er som regel kun raskere på komplekse grafiske operasjoner, ikke på simple grafiske operasjoner. Jeg har sett tilfeller hvor cpu'en gjør en raskere jobb. Men det viktigste er å opprettholde det kompatibelt. Det er derfor vi har GDI til å begynne med. Du kan bruke GDI+ hvis du vil også, men noen operasjoner er raskere i GDI enn i GDI+. I generelle programmer skal man styre unna gpu, med mindre det er et komplekst grafisk program. Vil forøvrig nevne at GDI benytter seg av endel hardware aksellerasjon, men denne aksellerasjonen er kompatibelt med de fleste grafikkkort, om ikke alle.

Skal du tegne grafikk så bruker du hardwaren til dette hvis du kan. Dette går vesentlig raskere enn det CPU-en er istand til. Selv å fylle inn et rektangel går fortere. Du kan benytte OpenCL og DirectCompute til dette.

[efikkan]

Bustebart: kan vi få se koden det er snakk om?

[Gjest]

Hei igjen.

 

Ser det har vært litt aktivitet, takker for svar/evt diskusjoner. Tror jeg dropper å prøve dette på mac i første omgang. På windows pc, tegner den opp over 1000 trekanter på svært, svært kort tid. Har lest litt rundt på nett og noe slår meg at det kan ha noe med at SDL og Quartz X11 i en kombinasjon med gcc på mac ikke er så gode venner. C koden er det ikke noe galt med..

[efikkan]

Jeg har gjerne lyst til å se på koden.

 

Men det skal nevnes at SDL i seg selv er noe makkverk. Jeg har sett gjennom deler av implementasjonen, så det vil ikke forundre meg at ytelsen er helt elendig under visse forhold.

[LonelyMan]

Skal du tegne grafikk så bruker du hardwaren til dette hvis du kan. Dette går vesentlig raskere enn det CPU-en er istand til. Selv å fylle inn et rektangel går fortere. Du kan benytte OpenCL og DirectCompute til dette.

 

Hvis du kan ja. Generelle programmer i windows kan ikke alle bruke gpu'en, task svitsjingen og bufre blir mistet hele tiden, skjermkortet har begrenset med ressurser og kan ikke fungere til alle programmer. GDI lagrer ressurser i systemminnet. Du skal kun bruke gpu til veldig spesielle programmer og til de fleste spill da spill kjører i fullskjermmodus er det lite annet du vil foreta deg i mest sannsynlig grad. Om alle skulle fulgt ditt eksempel så ville ressursbruken gått tom for lenge siden. Etter hva jeg ser har du heller ikke kodet mye gpu arbeid som jeg kan se. Jeg har kodet mye av det og jeg vet hvordan det fungerer.

[GeirGrusom]

Hvis du kan ja. Generelle programmer i windows kan ikke alle bruke gpu'en, task svitsjingen og bufre blir mistet hele tiden, skjermkortet har begrenset med ressurser og kan ikke fungere til alle programmer. GDI lagrer ressurser i systemminnet. Du skal kun bruke gpu til veldig spesielle programmer og til de fleste spill da spill kjører i fullskjermmodus er det lite annet du vil foreta deg i mest sannsynlig grad. Om alle skulle fulgt ditt eksempel så ville ressursbruken gått tom for lenge siden. Etter hva jeg ser har du heller ikke kodet mye gpu arbeid som jeg kan se. Jeg har kodet mye av det og jeg vet hvordan det fungerer.

Haha morsommen. Hvor GPU-en lagrer ressureser er helt og holdent opp til driveren. Du vet det flagget i Direct3D om hvor buffer skal lagres? Det er et hint. Driveren tar ikke nødvendigvis hensyn til dette.

GPU-en er der for at du skal benytte den. Windows bruker GPU-en uansett til å rendre, og hvis du har et dedikert grafisk program av et slag, så bruk den. Du skal ikke tenke på hva andre programmer måtte finne på (dette står også til kontrast i Nibbles opplegget ditt hvor du mente at det var greit å la to kjerner stå på 100% CPU-bruk for å hente inn verdiløs data hvor 99.9% ble forkastet allikevel)

 

Du starter med å angripe TS fullstendig uprovosert, uten at du engang har analysert problemet. Du har bare konkludert "Oi et sekund! Det var tregt. Du burde flippe burgere istedet!".

- Hvordan vet du at problemet er i TS sin kode?

- Hvordan konkluderte du med at det var tegningen av selve rektangelet var tregt?

Du hadde null tilgjengelig informasjon, men klarte likevel å bruke det til å fornærme TS.

 

Dessuten er kritikk fordi noe er feil uten noe påskudd om rettelse lite produktivt. Alle skriver feil, hele tiden, og den beste løsningen er at flere kan ta en kikk på det du har gjort.

 

Du poster her utelukkende for å få validering for programmene du skriver, og kritikk er du overhode ikke interessert i, men det er off-topic.

[Zeph]

Hald diskusjonen til emnet er de greie. Les gjerne gjennom retningslinjene av og til.

[LonelyMan]

Hvor GPU-en lagrer ressureser er helt og holdent opp til driveren. Du vet det flagget i Direct3D om hvor buffer skal lagres?

 

Ja flagget vet jeg om. Hva med det? Det fins i stort sett alle directx interface. Og de fleste som programmerer det setter det til hardware FORDI de bruker et system som er designet for hardware bruk. Hele poenget faller bort om du ikke setter flagget til å prioritere hardware. Du bruker GPUen og ressursene den tilbyr av en grunn, og det er fordi hardwaren tilbyr ressurser der. Om du ikke bruker det så faller hele poenget bort. Og dessuten om du velger å lagre vertex i systemminnet så vil du likevel måtte flytte de til grafikkkortet før du bruker dem igjen, forskjellen er bare at du har dem tilgjengelig begge plasser og det er enda større sløseri. Grunnen til at programmer skal skrives i GDI er fordi GDI håndterer ressursene effektivt på tvers av alle programmer som kjører. Om du har 10 programmer som kjører samtidig og du skal svitsje gpu bruk mellom de så vil du miste bufre og må laste dem om og om igjen fra systemminnet, og da faller hele poenget bort. Det fungerer godt om programmet ditt skal kjøre alene på maskinen men nå har vi multi tasking på moderne maskiner så det er ikke tilfelle lengre.

 

..også til kontrast i Nibbles opplegget ditt hvor du mente at det var greit å la to kjerner stå på 100% CPU-bruk for å hente inn verdiløs data hvor 99.9% ble forkastet allikevel

 

Du tenker helt feil her, den polle tråden forkaster data om den står på 0,1% eller om den står på 100%. Og begge stod ikke på 100%, bare den ene. Begge tilfeller forkaster data, poenget er å ha raskest mulig tasterespons, det er en prioritering. De prosentene du får opp i oppgavebehandlingen er bare kosmetikk i dine øyne. Etter jeg så diskusjonen din om akkurat dette så så jeg en diskusjon av steve hutchesson (han som vedlikeholder masm32) og han argumenterte for akkurat samme prinsipp, nøyaktig prikk lik som jeg designet det. Han har programmert assembler i 40 år iallefall så jeg tror du skal hysje litt her.

 

Det som er enda mer verdt å merke seg er at den tråden hvor jeg laget det nibbles programmet du snakker om, så kom du inn og skulle belære meg hvordan man bruker GetASyncKeyState, så skriver du, korrekt sitert: "du burde bruke AND eax, 0x80000000". Etter jeg så det så skjønte jeg med en gang at du aldri har brukt denne api funksjonen noe i det hele tatt, du har sikkert skumlest på msdn i api dokumentasjone og så har du sikkert skumlest dette "If the most significant bit is set, the key is down", men det du glemte å lese var at det var en short det var snakk om, og da skal du bruke 0x8000, du bommet med 4 sifre her. Om du hadde brukt denne api funksjonen i det hele tatt i fortiden ville du husket dette, det er helt elementært, stort sett det eneste du gjør med api funksjonen er å sjekke dette bitet, men at du kom med helt feil data her betyr jo bare at du kun har skumlest på funksjonen og sikkert aldri brukt den noe annet enn i et simpelt eksempel en gang i historien din. Man glemmer ikke hvordan man bruker denne funksjonen da som sagt stort sett det eneste du gjør er å bruke dette bitet. Har du glemt det, så kan du ikke funksjonen i det hele tatt og har iallefall ingen øvelse i å bruke den. Det er utrolig sykt gjort å komme inn i en tråd og påstå at noe er helt feil og så poster du absolutt feil løsning på problemet som ikke kan fungere under noen omstendigheter, og appåtil aldri har brukt funksjonen selv. Veldig lame oppførsel.

 

- Hvordan vet du at problemet er i TS sin kode?

 

Når folk poster problemer så er det rimelig å anta at det er TS sin kode, alt annet blir å anta med mindre sannsynlighet.

 

- Hvordan konkluderte du med at det var tegningen av selve rektangelet var tregt?

 

Fordi TS skrev, sitert korrekt: "så tegner den grafikken så utrolig sakte". Les ord 26-32 i trådstarters innlegg om du har vanskelig for å lese.

 

Du hadde null tilgjengelig informasjon

 

Jeg hadde all informasjon tilgjengelig i kontekst av hva jeg skrev.

 

Du poster her utelukkende for å få validering for programmene du skriver,

 

Dette er postuleringer fra din side som du ikke kan dekke som jeg heller ikke kan svare på. Dette er antakelser og ubeviselige påstander. Verdt å merke seg at du klager om at jeg angriper trådstarter, så avslutter du innlegget med å angripe meg.

Endret 18. oktober 2012 av LonelyMan

[GeirGrusom]

Postuleringer... Hva la du akkurat ut i "Lære assembly"? Jepp. En binærfil uten kildekode. Hva kan du være ute etter da? Ihvertfall ikke kritikk eller saklig diskusjon.

[LonelyMan]

Jeg har lagt ut dusinvis med kode i assembler forumet. Klip nå igjen med deg. Om du leser nøye så står det at kildekoden er der om noen spør (om du tenker på sistnevnte)

Endret 20. oktober 2012 av LonelyMan

[LonelyMan]

Hei igjen.

 

På windows pc, tegner den opp over 1000 trekanter på svært, svært kort tid.

 

Den rutinen jeg skrev som jeg postet, den tegner 625000 firkanter på et sekund, over en halv million firkanter hvor hver firkant er 100x100 pixler. Jeg kan tegne trekanter på litt over halve tiden så der er jeg over en million, og det er med egen kode. Og dette er uoptimalisert. Jeg kan optimalisere den ved å bruke sse, men jeg frykter at bottlenecken ligger i minnebussen så sse vil ikke hjelpe så fryktelig mye, men litt kanskje.

Endret 22. oktober 2012 av LonelyMan