Powf optimalizálás

Powf optimalizálás
2011-09-13T14:22:49+02:00
2011-09-13T17:10:27+02:00
2022-11-23T01:25:37+01:00
*deleted_57345013
A kérdés nagyon egyszerű, milyen jó közelítő megoldások léteznek a powf C függvény helyettesítésére?

Profilerezgettem a renderelőmet, és úgy néz ki a samplek jelentős része ezt a függvényt találta meg (21%), és a legtöbb esetben a BRDF számításom hívta őket.

3 esetben van hívva a függvény:
- 2.2-es hatványra emelés (inverz gamma korrekció)
- 1/2.2-es hatványra emelés (gamma korrekció)
- Tetszőleges, de gyakorta nagy hatványra emelés (BRDF számításhoz - irány, pdf, brdf érték stb)

Bogarásztam picit a neten, és amiket eddig találtam, azok a 3-ik esetben tönkrevágták az egészet (szignifikánsan világosabb lett a végeredmény).

Gondoltam körbekérdezek, hátha van valakinek a tarsoláyban egy nagyon trükkös megoldás :)

Ötletek?
Mutasd a teljes hozzászólást!
Hát ezt nézted-e?
A Fast Pow() Function

Egesz powerekre halal pontos, a tobbire kozelit, szal' lehet hogy, nem eleg jo...
Mutasd a teljes hozzászólást!

  • Azt próbálod mondani, hogy szerinted pontatlan a powf?
    PS: és miért az 'f' a végén? 'pow' a rendes neve
    Mutasd a teljes hozzászólást!
  • Az f lényegtelen, megszokásból írom oda, mert van egy ilyen definiált változata, ami float-ot vár inputnak, nem double-t.

    Azt mondtam, a közelítés volt nagyon pontatlan, nem pedig az eredeti.

    "Bogarásztam picit a neten, és amiket eddig találtam, azok a 3-ik esetben tönkrevágták az egészet (szignifikánsan világosabb lett a végeredmény)."
    Mutasd a teljes hozzászólást!
  • Hát ezt nézted-e?
    A Fast Pow() Function

    Egesz powerekre halal pontos, a tobbire kozelit, szal' lehet hogy, nem eleg jo...
    Mutasd a teljes hozzászólást!
  • Akkor miért nem használod az eredetit, ha az a jó? (Próbáld elképzelni, hogy nem mindenki gondolatolvasó, aki hozzászól a topikodhoz.)
    Mutasd a teljes hozzászólást!
  • Nekem egészen világos lett a kezdő posztból minden, nem tudom, miért értetlenkedsz. Lassú a program, és szeretné gyorsítani.

    Azt tudom javasolni, hogy ha első két esetben gyorsabb a helyettesítés, akkor az első két esetben használd azt, a maradékra meg keress egy nagy hatványokra jól működő algoritmust, vagy használd az eredetit.
    Mutasd a teljes hozzászólást!
  • Nem várom el senkitől sem, hogy gondolatolvasó legyen, mindössze azt, hogy el tudja olvasni a kérdést.

    "Profilerezgettem a renderelőmet, és úgy néz ki a samplek jelentős része ezt a függvényt találta meg (21%), és a legtöbb esetben a BRDF számításom hívta őket."

    És felhívom a figyelmed a topic címében található optimizálás szócskára. Azért, mert lassú, és az eddig talált megoldások nem voltak elég pontosak. Olyan megoldást keresek, ami gyorsabb és elég pontos.

    real_het - Köszi, megnézem majd, egyelőre más részeket gyorsítgatok :) .
    Mutasd a teljes hozzászólást!
  • real_het - Tetralius : köszönöm a válaszokat, mindkettőtöknek igaza volt, de csak egy választ tudtam sajnos elfogadni.

    Végső megoldás az volt, hogy alaposabban átkutattam a profilerezés adatait, és utólag kiderült, hogy mégsem abban a részekben történt a legtöbb hívás ahol néztem eredetileg (az egyik modul nem volt jól fordítva hozzá, emiatt ott nem mutatta közvetlen a hívó függvényeket), és így utólag kiderült rossz helyen számoltam. Át tudtam rakni ezeknek a számításoknak a nagy részét több szálra, és még ritkábban is hívom.

    Utólag visszagondolva elég nagy butaság volt, csak korábban más miatt raktam arra a helyre a számításokat, és közben sok-sok minden át lett írva :) .

    Mégegyszer köszönöm a hasznos hozzászólásokat.
    Mutasd a teljes hozzászólást!
  • Off: nyilván én vagyok hülye, de ha azt írta volna, hogy 'keresek egy függvényt, ami olyan, mint a 'powf', csak gyorsabb és pontatlanabb', akkor azért könnyebben megértettem volna. (Egyébként nem vagyok expert, de mintha a pow összesen három lebegőpontos utasításból állna: logaritmus, szorzás, exponenciális fv -- nem látom, hogy egy közelítő algoritmus hogyan lehetne annyival gyorsabb, ha nem használja ugyanezeket.)
    Mutasd a teljes hozzászólást!
  • Az FPU-n levo log2 az lehet, hogy 1 utasitasbol megvan, viszont az az egy utasitas 50-100 orajelen keresztul fut.
    Az a single osszeadas meg 1 clock, a szorzas meg 3 (idealis esetben az is 1 a 3 stage pipeline miatt).
    Mutasd a teljes hozzászólást!
  • Hát, azért logaritmus, exponenciális függvények vs sima szorzások / osztások között jelentős különbségek vannak...
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd