Keresés

Új hozzászólás Aktív témák

  • Abu85

    HÁZIGAZDA

    válasz LordX #4 üzenetére

    De az a baj, hogy erről vita van. Ha a szabványban megengedett implementációs különbség meggátolja a programfuttatást magas szintű kód szállításával, akkor az rossz. És ezen nem segít az, hogy a Khronos szerint egyértelmű a specifikáció xy gyártók szerint pedig nem. Erre jött a SPIR-V.

    Bugok vannak az összes fordítóban, ez nem lesz újdonság. De a problémák zöme a magas absztrakciós szinthez kapcsolódott, így ha azon segítünk, akkor a gondok mennyisége kezelhető szintre csökken.

    A SPIR-V-nek nem célja a programozási problémák megoldása. Az a programozó feladata. A cél az, hogy ha megírtál egy szabványos kódot, akkor az tuti fusson. A kód sebességét nem fogja javítani.

  • Fiery

    veterán

    válasz LordX #4 üzenetére

    "Az implementációs különbség meg olyan, hogy egyik esetben 64 szál lehet egy workgroupban, a másikban 256 ..."

    Pontosan. A problema csupan az, hogy egyesek -- es itt nem akarok ujjal mutogatni -- azt gondoljak, hogy a GPU-kban levo rengeteg eroforrast olyan egyszeru kihasznalni, hogy radobsz egy bazinagy tömböt a GPU-ra, es majd az megoldja a rengeteg warppal meg rengeteg regiszterrel a kerdest. Ez a trivialis megkozelites, ami nyilvan egyszeru feladatoknal -- pl. egy szazmillio+ megapixeles foto konverzioja szinesrol fekete-feherre -- me'g mukodhet is. De amint valami igazan erdekeset kezd az ember csinalni a GPU-kkal, bejonnek az architekturalis sajatossagok (meg a compiler bugok), amikkel ha nem kezd az ember valamit, akkor bizony nem lesz olyan fantasztikus a gyorsulas egy jol optimalizalt x86 kodhoz kepest, mint az ember azt várná naivan. Es itt nem kell embertelenul komplex feladatokra gondolni. Pl. mar egy pofonegyszeru AES adat titkositasnal is bejonnek az architekturalis sajatossagok.

Új hozzászólás Aktív témák