Keresés

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

  • Jack@l

    veterán

    válasz Abu85 #20 üzenetére

    Butaságot beszélsz, nincs olyan hogy amd vagy nv-re optimalizálnak egy opencl kódot, olyan van, hogy gpu-ra, olyan is van hogy 1 bizonyos gpu-ra, vagy konkrét cache/cu méretre darabolják a részfeladatokat.
    Meg olyan is van egy programnál, hogy lekérdezi az opencl device nevét, és ha van benne amd akkor engedi futtatni...
    Plusz ami opencl 1.2 kompatibilis kód, az valószínűleg nem fog futni nv kártyán, ha az csak ocl 1.1-et tud.

    [ Szerkesztve ]

    A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

  • Jack@l

    veterán

    válasz Abu85 #22 üzenetére

    Mondom hogy nem, látom nem hiszel Fiery -nek és azoknak az embereknek akik már dolgoztak opencl-el(beleértve magamat is)...
    Nincs portolás, egy opencl kód van, max lehetnek kompiler switch-ek a különböző cache méretek kihasználására.
    Ugyanaz a kernel fut minden eszközön, a cpu-n is.

    [ Szerkesztve ]

    A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

  • Jack@l

    veterán

    válasz Abu85 #24 üzenetére

    SPIR-t se érted mire jó konrétan úgy látom. Az egy köztes bináris, arra jó hogy ne plain textben kelljen tárolni az opencl kódot... (azt amit a driver fordít az adott eszközre első futtatáskor)
    Semmi másra nem jó, csak hogy ne lophassák el egyszerűen a forráskódodat.

    [ Szerkesztve ]

    A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

  • BatchMan

    senior tag

    válasz Abu85 #24 üzenetére

    Elfogadva tényként, hogy az egyes OpenCL változatok egyediek, nem bírom megérteni, miért nem lehet az egyes implementációkat úgy megcsinálni, hogy a futási eredményük ne különbözzön.
    Azért Open az open, hogy mindenkinek egyforma legyen a futási eredménye, és biztosítsa az átjárhatóságot - csökkentve a programozók munkáját, de felvállalva, hogy a hatékonysága kisebb, mint egy típus-hardverre szabott kódszabványnak.

  • Jack@l

    veterán

    válasz Abu85 #26 üzenetére

    Erről azért beszélj Fiery-vel... Nem szeretném, ha nagy népbutítás lenne ezen a téren is egy magát szakmainak mondó oldalon. (legyen az akár szándékos, vagy tudatlanságból fakadó)

    [ Szerkesztve ]

    A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

  • con_di_B

    tag

    válasz Abu85 #24 üzenetére

    A SPIR absztrakcios szintje valojaban nem sokkal melyebb, mint az OpenCL C forraskodoke, ezen tenyleg nem segit semmit. Ha melyebbet, "egysegesebbet" akarsz, akkor ott van a HSA IL, de valojaban az is virtualis gep, szoval a hatekony mapping az aktualis architekturara ugyanugy gyartospecifikus marad.

    A kod megvedesere pedig nem kinalt szabvanyos opciot az OpenCL. Az egyetlen lehetoseged az volt, hogy minden egyes architekturara/driver verziora stb. kulon csomagolsz binarist a programoddal, de ez nem megoldas, foleg, hogy a jovobeni kompatibilitas meg adott gyarton belul sem garantalt.

    [ Szerkesztve ]

  • con_di_B

    tag

    válasz Abu85 #24 üzenetére

    Igazad van, hogy komplex problema, de a cel altalaban az, hogy egy forraskoddal le lehessen fedni minden gyartot, mert megis ki a fene akarna a sajat karbantartasi koltsegeit megtobbszorozni feleslegesen? Aztan, hogy mennyire kell megiscsak elagazni a gyakorlatban, az is egy masik problema.

    Ha eleve ugy kezdesz el egy uj projectet, hogy azt mondod, hogy oke, OpenCL 1.1, mert azt a hulye is tudja, es desktopon minimum annyit megcsinalsz, hogy mindig teszteled Intel CPU-n, GPU-n, AMD CPU driverrel (nem is feltetlenul AMD CPU-n!), AMD GPU-n, es NVIDIA-n, es ugy haladsz, h mindig utanajarsz amikor az egyik elkezd nem mukodni, akkor olyan nagy bajod nem lesz, es ha betartod a fokozatossag elvet, akkor ez tenyleg minimalis erofeszites.

    Azt szoktak elrontani a sracok, hogy kipreselnek magukbol par tizezer sort (device oldali kodrol beszelek), aztan vinnek at mashova, es csak annyit latnak, h "nem fut", "lassu", akarmi, aztan ha egy het bogyoreszes utan is lassu, akkor inkabb letiltjak a francba. De ez ugyanaz a tortenet, mint amiert mindig azt magyarazom, hogy akkor is cross-platform kell fejleszteni valamit, ha nem felhasznaloi igeny (egyelore!), hogy cross-platform legyen, mert kesobb megterul.

    Az, hogy a teljesitmeny mennyire hordozhato, reszben az is fejlesztesi metodus kerdese. Altalanossagban nyilvan nem hordozhato, de ha mondjuk valaki a "make it work, make it right, make it fast" diszciplina sorrendiseget nem ugy ertelmezi, hogy veletlenul sem profilozza/meri le, hogy mit csinalt, mondjuk ugy a megjelenes elotti ket hetig bezarolag, akkor azert meg idoben fel fog tunni, ha valami valahol nem stimmel, es akkor meg program design szinten lehet ra reagalni, ha muszaj. Vagy kuldeni a bug reportot az Intelnek, hogy mar megint ugyesek voltak.

    A hordozhatosag kesobb persze nyilvan fuggvenye annak is, hogy mennyire akarjuk csutakra optimalizalni adott szoftvert, de amennyi hulyeseget ezen a fronton mar lattam elkovetni (aminek a vegen a generikus kod gyorsabb lesz, mint a hardver specifikusan "optimalizalt"), illuzioink azert ne legyenek. Amit generikus koddal el lehet erni, az doszt eleg lesz, 90%-ban.

    [ Szerkesztve ]

  • con_di_B

    tag

    válasz Abu85 #37 üzenetére

    A SPIR csak a "fogyasztast" szabvanyositja, a generalast nem, viszont ahogy te is mondtad, mivel mindenki a Clang-et hasznalja, addig lenyegeben a generalas is tekintheto egysegesnek, pipa.

    Viszont ez meg mindig csak a front-end! Minden ami izgalmas, platform-specifikus, es tenyleges optimalizacionak tekintheto, az ez utan tortenik!

    Vannak bizonyos problemak, amiket ez megold, ugyanis a regebbi OpenCL C specifikaciok (szerintem nem, de a kozertelmezes szerint) nyitva hagytak par kerdest, peldaul, hogy pontosan mikor tortenik scalar-to-vector upcast implicite stb. amikben lehettek ertelmezesi elteresek, ha meg mindenki ugyanazt a front-endet hasznalja, akkor legalabb emiatt nem kell szivni.

    Viszont az, hogy par hete azert kellett frissitenem az Intel GPU drivert az elozo "legujabbrol", mert egy ponton tul mindenen elhalt ami 64bites integereket hasznalt (core feature), szoval sanszos h a conformance testen se felelt volna meg, es tudtommal az a verzio is mar vidaman hasznalta a Clang-ot, szoval eselyes, hogy a back end halt ki alola, de mivel hiba uzenetet elfelejtett dobni... Szoval, igen, szerintem is logikus, hogy emiatt majd jobbnak kene lennie egy kicsit a dolgoknak, de ez inkabb arra lesz jo, hogy egyaltalan valahogy fusson a kod, de a teljesitmenyt erinto (back-end) reszletekre ennek semmilyen hatasa nincs.

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