| Zobrazit předchozí téma :: Zobrazit následující téma |
| Autor |
Zpráva |
]semo[
Založen: 29. 07. 2007
Příspěvky: 1525
Bydliště: Telč
|
 Zaslal: 17. prosinec 2010, 13:27:33 Předmět: podivný glClear |
 |
|
Čau,
po čase mám jeden praktický dotaz. Optimalizuji zrovna mojí OpenGL aplikaci. Všiml jsem si, že když ji spustím, zároveň začne explorer.exe žrát zhruba 5-10% CPU - ale to až po chvíli (2-3 sec!). Tím pak vznikají nepříjemný škuby. Když explorer.exe killnu, funguje vše jak má.
Zjistil jsem, že to nejspíš způsobuje volání glClear pro Color Buffer - vypnutý render a 100 volání glClear(GL_COLOR_BUFFER_BIT) vytíží explorer slušně, zatímco glClear(GL_DEPTH_BUFFER_BIT) vůbec. Nevidím tolik pod pokličku driverům, takže neznám přesně, jak je okení systém s OpenGL provázán. Navíc podobně blbé výsledky dává i mazání fullscreenovým quadem, což už nechápu vůbec.
Zkoušel jsem hledat na zahraničních fórech - bez úspěchu. Zkoušel jsem všelijak jinak vytvářet a nastavovat okno a OpenGL context, vše marné.
Mám dobře zajetý AMD Opteron 1.8 GHz, 1GB Ram, ATI X1600 (256MB VRam) a asi 2 dny starý ovladače, Windows XP Professional SP3.
Máte-li někdo nějaký nápad, budu rád!
(Bude-li mi někdo chtít poradit něco ve stylu: přepiš to do Direct3D, ať se neobtěžuje, děkuji.)
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory |
|
| Návrat nahoru |
|
 |
Vilem Otte
Založen: 18. 09. 2007
Příspěvky: 462
Bydliště: Znojmo - Sedlesovice, Kravi Hora
|
| Zaslal: 17. prosinec 2010, 13:54:46 Předmět: |
|
|
Ten problém vypadá opravdu divně, vyjímkou by mohlo být, pokud bys nekreslil double (případně) triple - bufferingem, v té chvíli by jsi kreslil přímo do okna a mohlo by to dělat neplechu (jenže by to také blikalo) ... protože jediná věc, která může zatížít Explorer.exe je SwapBuffers afaik ... ale ten jej zatěžuje furt stejně minimálně.
Je také možné, že se jedná a driver bug (nevylučoval bych to), ale kdoví. Zkusil bych starší ovladače pro tvoji GPU, jestli mají stejný problém - jestli ne, tak potom je to jasné.
Další otázkou ještě je, zda to způsobuje přímo ta aplikace? Jestli důvod není právě uvnitř windows kernelu (tuto možnost bych také nevylučoval, všichni přece známe windows).
Možná by bylo lepší zkusit poslat dotaz na OpenGL.org discussion boards - tam by mohli vědět co to způsobuje, a případně jak to odstranit.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. |
|
| Návrat nahoru |
|
|
]semo[
Založen: 29. 07. 2007
Příspěvky: 1525
Bydliště: Telč
|
| Zaslal: 17. prosinec 2010, 14:10:23 Předmět: |
|
|
Jak si tak ladím, tak se k tomu SwapBuffers dostávám, takže máš recht. Když např. po glClear() zavolám glFinish(), tak explorer už nevytěžuju. Takže se jedná asi o čekání na dokončení glClear, který může při větším rozlišení nějaký čas trvat (ale stejně mi je divný, že je to v řádech milisekund).
EDIT: ty milisekundy beru zpět.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 17. prosinec 2010, 15:16:31 Předmět: |
|
|
Dělá to i ve fullscreenu?
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
nou
Založen: 28. 07. 2007
Příspěvky: 1047
|
| Zaslal: 17. prosinec 2010, 15:24:30 Předmět: |
|
|
na opengl.org fore som cital o pomalom clClear na 3x4 monitoroch. problem bol ale vo Windows 7 aero.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú. |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 17. prosinec 2010, 15:43:30 Předmět: Re: podivný glClear |
|
|
| ]semo[ napsal: |
| Mám dobře zajetý AMD Opteron 1.8 GHz, 1GB Ram, ATI X1600 (256MB VRam) a asi 2 dny starý ovladače, Windows XP Professional SP3. |
Nechápu, jak můžeš mít 2 dny starý ovladače, když podpora pro tu kartu de facto skončila v březnu 2009.
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
]semo[
Založen: 29. 07. 2007
Příspěvky: 1525
Bydliště: Telč
|
| Zaslal: 17. prosinec 2010, 16:05:54 Předmět: |
|
|
no jakože sem je stáh před dvěma dny a jsou tím pádem nejposlednější
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory |
|
| Návrat nahoru |
|
|
]semo[
Založen: 29. 07. 2007
Příspěvky: 1525
Bydliště: Telč
|
| Zaslal: 17. prosinec 2010, 16:15:48 Předmět: |
|
|
Ve fullscreenu to dělá, zdá se, taky. Už tim trávím druhej den a začíná mě to nebavit, asi to radši testnu na jiných kompech. Přesto ale stále přijímám rady :-).
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory |
|
| Návrat nahoru |
|
|
Vilem Otte
Založen: 18. 09. 2007
Příspěvky: 462
Bydliště: Znojmo - Sedlesovice, Kravi Hora
|
| Zaslal: 17. prosinec 2010, 17:27:14 Předmět: |
|
|
| citace: |
| ale stejně mi je divný, že je to v řádech milisekund |
Ještě rychleji asi, mě trvá buffer-clearing v softwarovém realtime raytraceru 2.67 ms při vektorizovaném SSE, při AoS SSE o něco méně - kdy v obou případech už narážím na problém přístupu do pamětových sektorů. ... rozlišení 1280x720, rgb32f formát (tedy HDR floating-point).
EDIT: Tedy pro vysvětlení, nešlo tady o schopnost fillrate, ale o schopnost přístupu do paměťových sektorů, jelikož ty jsou po 512 bytech (jo, dělal jsem nějaký hobby OS-development, tak trošku o tom vím), a problém je na světě ... dokonce screen clearing pomocí více jader (nedejbože více vláken na jedno jádro) najednou je pomalejší než s 1 jádrem a pouhým jedným vláknem!
Příkladem je tento nejrychlejší kód buffer-clearingu pro vektorizované SSE (omlouvám se za "dirty assembly"):
| kód: |
__asm
{
movss xmm0, r
movss xmm1, g
movss xmm2, b
shufps xmm0, xmm1, 0x00
shufps xmm2, xmm2, 0x00
shufps xmm0, xmm2, 0x88
mov eax, viewportWidth
mov ecx, viewportHeight
mul ecx
mov ecx, eax
mov edx, viewportBuffer
traversal:
prefetchnta [edx+16]
movaps [edx], xmm0
add edx, 16
dec ecx
jnz traversal
}
|
Což je v praxi pouhých pár instrukcí - 3 movss, 3 shufps, 4 mov, 1 mul, 1 movaps * počet pixelů, 1 add * počet pixelů, 1 dec * počet pixelů + 1 jnz * počet pixelů - 1 ... prefetchnta natáhne vždy příští pixel do cache při současném cyklu, aby jej mohl zaplňovat (což zvyšuje docela brutálně rychlost na všech CPU) ... algoritm je psaný balancovanou optimalizací - tedy na AMD/Intel moderních architekturách běhá co nejrychleji může (C/C++ proceduře to trvalo ceých 16 ms).[/code]
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. |
|
| Návrat nahoru |
|
|
|
Hlavní strana
FAQ
Test
Hledat
Seznam uživatelů
Uživatelské skupiny
Registrace
Ke Stažení
Nastavení
Přihlášení
Calendar
