Keresés

Hirdetés

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

  • Fiery

    veterán

    válasz Thrawn #34 üzenetére

    Hogyne lehetne :) Az AIDA64 benchmarkjai es a stresszteszt modul mar most is nativ 64 bites. Ezek azok a reszei a szoftvernek, ahol gyakorlati jelentosege is van a 64 bitnek, nem csupan egy jol hangzo marketing szoveg. Minden mas marad 32 biten, amig maradhat. Bizunk benne, hogy a Microsoft me'g egy jo darabig megtartja a WoW feluletet a Windowsokban, es igy sokaig marad 32 biten az AIDA64 nagy resze.

    HSA benchmarknak meg akkor lenne ertelme, ha hirtelen alkalmatlan vagy keves lenne a mostani OpenCL benchmark szett. Azaz, ha mondjuk megjelenne egy csomo HSA-ready hardver, rendes HSA runtime-mal, amin viszont nem vagy nem jol futna az OpenCL benchmarkunk. Vagy ha lenne olyan hardver, ami csak HSA-ready lenne, de nem tamogatna OpenCL-t. Kizarolag az AMD APU-ira fejleszteni HSA benchmarkot, ami raadasul lenyegeben ugyanaz lenne, mint a mostani OpenCL benchmark, nem lenne egy okos dontes. Nem vagyunk mi annyira izgalmas piaci szereplo, hogy pont mi kezdjuk el tolni az AMD szekeret. Mar most is nagyon jo eredmenyeket produkalnak az AMD GPU-k az OpenCL benchmarkjainkban, legyen ennyi eleg ;)

  • Jack@l

    veterán

    válasz Thrawn #42 üzenetére

    Arról már lekésett:
    https://github.com/HSAFoundation/Hetero-Mark

    @Fiery: pedig úgy tudtam az intel nagyon ráfeküdt az opencl-re az utóbbi években, nvidia szokás szerint nem igazán a cuda miatt

    [ 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 Thrawn #46 üzenetére

    Ezzel szűrik ki az egységsugarú felhasználókat... :) (ők úgyis csak agyatlanul puffognának hogy nem fut a gépükön)

    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ó.

  • Fiery

    veterán

    válasz Thrawn #42 üzenetére

    "Szívesen nézegetnék olyan HSA benchmarkokat, ahol egymás mellett lehetne látni és elemezgetni a "with HSA" és "without HSA" eredményeket."

    Ott az AIDA64 GPGPU benchmark panel: pont ezert raktuk egymas mellé a GPU-s es a CPU-s eredmenyeket. Rendkivul jol latszik, hogy oriasi potencial van a GPU-kban, nagysagrendekkel gyorsabban tudjak vegezni a szamitasokat, ez vitan felul all. Csak epp ami egy benchmarkban mukodik, az nagy semmit nem er, ha a gyakorlatban meg amiben me'g mukodik es hasznalhato, az egy masik benchmark :) Ez kb. olyan mint egy taxi, amivel csak versenypalyan szabad kozlekedni. Vagy egy vonat, ami csak az allomas egyik vegebol a masikig hasznalhato.

    Mi azert nem akarjuk elkezdeni, mert nincs mit elkezdeni. Az nem a mi stilusunk, hogy fogunk egy mar letezo benchmarkot, atnevezzuk, es azt mondjuk, hogy ez egy uj cucc, "world's first". Mert ez lenne, ha a meglevo OpenCL benchmarkokat atvinnenk HSA-ra. A kiindulasi alap, az OpenCL benchmark kernel ugyanaz lenne, csupan a futtatokornyezet lenne mas. Es az eredmenyek is kozel azonosak lennenek, sot. Amikor legutoljara neztuk, a Kaveri HSA path-en atnyomott OpenCL benchmarkok, azaz a HSA compiler altal eloallitott kod valojaban lassabb es bugosabb volt, mint amit az AMD sajat GPU-s OpenCL compilerei tudtak. Ami nem is csoda, hiszen a GPU-s OpenCL compilernek van nehany ev elonye kiforrottsagban.

    Nyilvan teljesen mas lenne a helyzet, ha me'g sosem foglalkoztunk volna GPGPU-val vagy OpenCL-lel. Akkor lehetne specifikusan HSA-ra fejleszteni a benchmarkokat, bar akkor meg a legacy tamogatas okan kellene igazsag szerint kiemelni a HSA-bol az OpenCL kerneleket, es a nem-HSA-ready konfigokon atkuldeni a hagyomanyos OpenCL runtime-on. Es vegul ugyanoda lyukadnank ki, mintha forditva csinalnank, azaz megint nem lenne sok ertelme.

    "A szekértolás pedig kétoldalú lenne ugyebár :)"

    Olyasmire gondolsz, mint amit az AMD a Fury Nano kapcsan muvelt az IT mediaval? ;] Nothx, akkor inkabb ne toljon minket senki.

    [ Szerkesztve ]

  • Fiery

    veterán

    válasz Thrawn #51 üzenetére

    Bar az is remek lenne, ha lehetne aggregalni a CPU es GPU teljesitmenyet, SZVSZ mar az is hatalmas elorelepes lenne, ha a GPU-t konnyen munkara lehetne fogni a HSA-val. Tehat en ugy gondolom, egymas mellett latni is nagyon jo az eredmenyeket. Azon egyebkent gondolkoztunk, hogy ossze is lehetne az eredmenyeket adni, hiszen ugyanazt szamolja mindket oszlop. Csak epp az csalas lenne, hiszen a Turbo Boost es hasonlo megoldasok miatt egy APU sosem lenne kepes az osszteljesitmenyre. Vagy a CPU-t tudod kihajtani, vagy a GPU-t, de a ketto egyutt nem tudna olyan gyors lenni, mint a 2 eredmeny osszege.

    Mi nem kifejezetten Nanot kertunk, hanem barmilyen Furyt, de nem kaptunk. Szerencsere mi legalabb nem okkal nem kaptunk, hanem csak nem jutott. De egy olyan draga es nehezen gyarthato kartyanal, mint a Fury szeria, meg is ertem, ha nekunk nem jut. Az, hogy a mediaban nem jutott mindenkinek, az egy mas tortenet, azzal se lenne gond, ha kisorsoltak volna a kartyakat.

  • Fiery

    veterán

    válasz Thrawn #57 üzenetére

    A CPU es GPU egyszerre dolgoztatasa még bonyolultabb, mint ha OpenCL-lel hajtod meg a GPU reszt. Ha ugyanis a CPU-t is OpenCL-lel kezeled, akkor kulon parancssor kell hozza, kulon kotextus, adott esetben kulon kernel, kulon build, es _kulon_ compiler fogja forditani a kerneledet! Tehat eloallhat egy olyan "vicces" helyzet, hogy az OpenCL kernel remekul fut a GPU-n, de az azzal parhuzamosan futo CPU kod viszont hibas eredmenyt ad. Vagy az egyik szalon fut a GPU kod, mikozben a masik szalon vegtelen ciklusba kerul a CPU kernel forditasa. Remek dolgok ezek :)

    Az persze megoldhato, hogy a GPU-n OpenCL kernelt futtatsz, a CPU-n pedig nativ x86 kodot. Csak akkor 2 kodbazis, mindent kulon kell megirni, es persze okostan kell megoldani a multi-threadinget, hiszen az egyik CPU-n futo szalnak vezerelnie kell az OpenCL munkafolyamatot is (queuing). Hidd el, agyrem az egesz, nem tulzok.

    A Fury Nano temaban szerintem az lett volna az elfogadhato megoldas, ha idoben szallitja a kartyakat a review site-oknak az AMD, es megmondja nekik, hogy van 1 hetetek ra, aztan villamgyorsan kuldjetek vissza. Majd kikuldik a kovetkezo site-nak, stb. Igy 10 kartyaval, ha idoben indulnak, le lehetett volna fedni 40 site-ot is siman. Nyilvan nem egyszeru logisztika. Alternativ megoldas lett volna, amit emlitettem: be kell ismerni, hogy nincs eleg kartya, valamivel meg kell magyarazni, es ki kell sorsolni a kartyakat a site-ok kozt.

    [ Szerkesztve ]

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