Hirdetés

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

  • con_di_B

    tag

    válasz lenox #149 üzenetére

    No-no-no, nézd vissza, hogy én mikor mit állítottam pontosan. Pl. már a #82-es hsz-emben is benne van, hogy bivalynak ezután is a felsőkategóriás diszkrét GPU lesz bivaly. (Csak ott kiegészítettem egy optimista jövőképpel. :))

    1-2) Ergo, én azt mondom, hogy meglepően jó lesz. De azért azt ne várjuk, hogy eléri akár a bokáját is a Cayman-nak, ennyire még egy cég sem volt hülye, hogy a 100eFt-os csúcskártyája tudását odaadja neked egy-két dolláros feláron. (Nem is tudná, de nyilván NAGYON nem is akarja.)

    A késleltetés érzékenységnél meg maradok annál amegfogalmazásomnál, hogy sokkal többször, mint gondolnád.

    (Egyébként akkor nem érdekelhetnének az AMD cuccai GPGPU szempontból, mert EZ az architektúra (GPU-n belül), eleve pont, hogy csak "bizonyos extrém esetben" versenyképes mondjuk a Fermi-vel. :D )

    3) Persze, ugyanazt mondjuk.

    Szóval, én eddig is ezt mondtam, azt, hogy kihalnának a diszkrét GPU-k, amíg össze se mérhető a rendszermemória sávszélessége egy sajátkártyás cuccéval, addig erre aligha kerül sor. Viszont ez a piacnak csak kis része, amelyik felhasználó igényel ilyen kártyát. Ilyen szempontból még meg is lehet érteni ha valaki azt mondja "el fog tűnni", de én pont nem mondtam, ne rajtam verd le. :)

    "Na ne kezdj el visszakozni, szo sem volt ugyanannyi penzrol meg tdp-rol vagy helyrol, pontosan a felsokategorias gpu-krol volt szo" - de ezt mi értelme egyáltalán összehasonlítani? Csodák nincsenek, azért felső kategóriás, hogy jobb legyen ennél. A legalja diszkrétekkel kell/szabad összevetni.

    Ami viszont vitatéma volt a fórumban, hogy most mérföldkő-e vagy sem. Szerintem teljesen védhető az álláspontod, de vmelyik hsz-emben meg írtam, hogy akkor innentől kezdve minden újonnan vásárolt PC-szerű gépben ott fog mosolyogni egy egész korrekt OpenCL implementáció. NEKEM ez mérföldkő. x600-as VGA-nál gyengébbet meg soha nem vettem, szóval mint VGA engem speciel hidegen hagy majd az asztali verziója is, de az nagyon jó, hogy van, és hangyányi igazítással viszi ugyanazt a kódot. (Elvben. Aztán majd meglátom amikor szüttyögni kell vele, milyen lesz.) Egyébként meg ha ez nem az, akkor nem tudom mi. Anno az integrált memóriavezérlőt is mérföldkőnek tekintettük, pedig az egy triviálisabb dolog ennél.

  • freeapro

    senior tag

    válasz DRB #117 üzenetére

    Dehogynem: single core > multi core > hetrogen

    Hogy értsd, hogy miről beszélek: próbáltam DX játékot csinálni, a doc és a példák alapján vertex buffereket csináltam az objektumokra, kiszámoltam a mátrixokat és szépen egyesével kipakoltam a képernyőre. Állati lassú lett. Ekkor elkezdtem mégegyszer átnyálazni az SDK docot és többszázoldalas nyomtatásban tényleg ott volt az egysoros megjegyzés, hogy a graf kártyák azt szeretik, ha nem csak úgy összevisza küldjük az adatokat, hanem az azonos objektumokat egyszerre batchben szeretik kiiratni.
    Hiába pár sor a kódodban egy API hívás ha mögötte több száz soros driver kódot kell végrehajtani és rendszerek között kell kommunikálni aminek nagy overheadje van, akkor azt másképp kell csinálni.
    De ha egy chipeben lesz az egész, lehet, hogy újra elővehetem a programomat és most jól fog futni... :)

    Ennél jobban már tényleg nem tudom elmagyarázni..

  • freeapro

    senior tag

    válasz lenox #145 üzenetére

    A kesleltetes alatt a latency-re gondolsz? Mert ugye azt mar irtam fent, hogy egy opencl kernel launch kesleltetese tobb 100-szor annyi, mint a pcie busze, tehat tul sok jelentosege nincs.

    Bocs, de ezek nem összehasonlítható dolgok. A PCIe busz latency-t a belső adatbusz latency-vel hasonlítsd össze, az opencl API hívás idejét meg egy DX API hívás végrehajtási idejével.

  • erdoke

    titán

    válasz Abu85 #150 üzenetére

    Várjuk meg, mit mond a MS ezzel kapcsolatban. Nem vagyok benne biztos, hogy a CES folyamán részletes információkkal szolgálnak arról, hogy pontosan milyen lesz a Windows 8, illetve hogy külön lesz ARM-es változat, vagy egybegyúrják az egészet. Program oldalról is kérdéses az egész, virtualizációval pont a hely- és energiatakarékosság veszik el.

    A legjobb aláírás a héten

  • freeapro

    senior tag

    válasz lenox #145 üzenetére

    Ennek az APU design-nak a bottleneckje a memoriabusz. A gpu-t etetni kell adattal. Vajon ez hogy fog jobban menni, ha a cpu/gpu parosnak osszesen van elmeleti 27 GB/sec-je, vagy ha osszesen 180 GB/sec-je van. Szerintem a masodik esetben, szerinted az elsoben... Emlekszel, mi volt felirva az nv abrajara amire hivatkozol? 1.4 TB/sec.

    Itt is keversz dolgokat. A Fusion egy átfogó neve a heterogén fejlesztéseknek, ami most kijött az a Brazos platform, a low end vége a fejlesztésnek, amit nettopokba meg táblagépekbe szánnak. Ezt felesleges hasonlítani a high-end gpu-khoz. Ha majd kijön a liano, akkor közelebb lesznek az értékek, de az is gyengébb lesz mint egy direkt high end gpu a megfelelő feladatra és a megfelelően optimalizált programmal.
    De a lianoban majd lehet vegyesen használni a az integrált gpu-t a diszkrét gpu-val. Például fizika számításra integrált gpu-t használsz, mert kisebb adatmennyiségnek többször neki kell futni (ütközés számítás), majd a renderelés lépést batchelten el lehet küldeni a diszkrét gpu-nak.
    A teljes rendszer így is gyorsulni tud.

  • lenox

    veterán

    válasz Abu85 #150 üzenetére

    Nem, nem neztem meg, mert nincs jelentosege, az egesz amiatt jon fel, hogy lehet-e a mobil eszkozben x16, igen lehet. Es igen, jol latod, hogy a meret a lenyeg, erted, nem a maximalis teljesitmeny. Eddig is ezt mondtam.

    Konkrétan az események szinkronjára gondolok. Az egy buszon keresztül nagyon fáj. Eddig ezért nem használták a fejlesztők, mert olyan késleltetések mellett, ami van a buszon értelmetlen. A rendszerszintű integráció értelmet ad ennek.

    Ez szerintem tevedes, pl. en is hasznaltam. Nyilvan en csak egy vagyok, de ettol meg lehetett hasznalni, aki akarta hasznalhatta, nem tulzottan valtozik semmi azzal, hogy most joval kisebb latency van, illetve annyi valtozik vele, hogy bizonyos algoritmusok ezzel hatekonnya valhatnak, kar, hogy csak limitalt teljesitmeny mellett van igy, ha nagyobb teljesitmeny kene, akkor nincs kis latency opcio, mert muszaj diszkret gput hasznalni, azzal ugyanis gyorsabb a rendszer.

    Én nem a Fusionról beszéltem, amikor az integráció értelmét elemeztem, hanem a konkrét előnyökről, amiért minden vállalat erre megy. Bár szerinted minden cég idióta mérnököket alkalmaznak. :))
    Nem tudom mire velni, hogy tovabbra is ugy teszel, mintha nem ertened, hogy nem csak egy cel lehet, pl. a max teljesitmeny biztos nem volt cel 2011-re, nem is ertek el, ettol meg uzletileg ennek van ertelme. En a mernokoket biztos nem idiotaztam le, de a mernokok tul szoktak latni a marketing rizsan. Spec en mar 2006-ban is kerdeztem az amd-seket, amikor jottek fusion-t prezentalni, hogy jo, de mit csinaljak vele, ha nem raknak ala gyors memoriabuszt, akkor ez tul gyors nem lesz. Mondjuk ok nem is ertetlenkedtek ennyit, mint te, hanem mondtak, hogy igen, de nem is az a celja.

    De a köztük lévő kommunikáció lassú, és a buszok fejlődése sokkal lassabb, mint ahogyan a lapkák fejlődének

    Igy van. Ezzel egyutt ha kiherelt memoriarendszert raksz az integralt chiped ala, akkor nem gyorsulni fog, hanem lassulni. Ahhoz, hogy gyorsuljon kell nagy memoriasavszelesseg is. Ezt kene mar felfogni. Persze sejtem, hogy valojaban mar reg egyetertesz, csak kotod az ebet a karohoz.

    #151:

    A késleltetés érzékenységnél meg maradok annál amegfogalmazásomnál, hogy sokkal többször, mint gondolnád.

    Ahogy tetszik, nyugodtan lenezhetsz, szerintem van mar akkora szakmai elismertsegem, hogy ebbe ne halljak bele :).

    #153:
    Bocs, de ezek nem összehasonlítható dolgok. A PCIe busz latency-t a belső adatbusz latency-vel hasonlítsd össze, az opencl API hívás idejét meg egy DX API hívás végrehajtási idejével.

    Ok, majd elgondolkozom rajta. De szerintem nincs igazad, mivel a vegrehajtasi ido nem csak pcie latencybol all, tehat erdemes tudni, hogy ennek a latencynek mekkora jelentosege van az egesz processing szempontjabol, tehat hogy hogy viszonyul a tobbi idohoz. Pont ezert erdekes, hogy mar pl. az opencl kernel launch overheadjehez kepest is elhanyagolhato, ugyhogy erre hivatkozva allitani, hogy a diszkret gpu-s rendszerek annyival lassabbak, mint az integraltak, hogy foglalkozni sem erdemes veluk, eleg erdekes.

    #155:
    Mit keverek szerinted? Pontosan mit mivel? Amugy abban egyetertunk, hogy a high-end gpu-k erosebbek, nem pont ezt mondom mar sok hozzaszolason keresztul?
    Kulonben pont most portolok fizika szamitast gpu-ra, szerintem kepben vagyok.

  • Abu85

    HÁZIGAZDA

    válasz lenox #156 üzenetére

    Tehát, akkor szerinted az Intel teljesen feleslegesen dolgozott, amikor az új generációs Atomot lekicsinyítették. Ehhez képest, azért volt olyan netbook, amibe alig fért bele a termék. Ez a netbook nem születhetett volna meg a régi Atommal.
    Nem, te azt mondtad, hogy az integrációnak nincs előnye. Persze az már fejlődés, hogy eljutottunk oda, hogy a méret lett a lényeg. Pár hsz még és meglátod az integráció előnyét. :)

    És mégis ki mondta, hogy a második vagy a harmadik generációs Fusion alatt már nem lesz combos memóriaalrendszer? Az előnyök a rendszerszintű integrációval kézzel foghatóak. Ezt látja a piac összes szereplője. Ha szerinted nincs előny, akkor csak lehülyézed a mérnököket, mert mindenki ilyen irányba fejleszt. Most akkor mi van? Van előnye az elgondolásnak, vagy hülyék a mérnökök, hogy ilyen irányba mennek. A kettő kizárja egymást.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • lenox

    veterán

    válasz Abu85 #157 üzenetére

    Erdekes, hogy pl. a #128-ban tudtad meg idezni tolem, hogy szerintem milyen elonye van az integracionak, de mostanra meg mar ugy tudod, hogy szerintem nincs elonye, es nyomatod, hogy kit hulyezek le ezzel mar tobb hozzaszolas ota. Terelesnek jo, de amugy nem tartom melto hozzaallasnak, gondolkozz el ezen szerintem. Legyszi a nevemben mostantol ne hulyezz le senkit, majd en megteszem, ha ugy latom jonak, koszi.

    És mégis ki mondta, hogy a második vagy a harmadik generációs Fusion alatt már nem lesz combos memóriaalrendszer?

    Egyelore nem tudok senkirol, aki mondta volna, de azt, hogy mi hianyzik meg az igazi fejlodeshez, azt spec. en mar pont mondtam, ez az egyik. Ugyhogy en varom is, hogy lesz, teljesen logikus lepes lenne. Aztan arrol lehet otletelni, hogy ez azert draga lesz entry level alaplapra tenni, de kell, ezert fel lehet rakni a memoriarendszert a gpu/cpu integralt chippel egy kartyara, es azt bedugni az alaplapba, vagyis hogy idovel az en tippem szerint nem a gpu fog lekoltozni a cpuba, hanem a cpu fog felkoltozni a 'grafkartyara', legalabbis a desktopon. De monduk ez csak egy tipp.

    [ Szerkesztve ]

  • dezz

    nagyúr

    Jobb lett volna úgy a cím, hogy Beindult az AMD fúziója. ;)

    [ Szerkesztve ]

  • Abu85

    HÁZIGAZDA

    válasz lenox #158 üzenetére

    Már megint eljutottunk egy lényeges kérdéshez. Szerinted van előnye a rendszerszintű integrációnak? Mert az az érzésem, hogy elbeszélünk egymás mellett. Nem a Brazosra gondolok, hanem úgy általánosságban.

    Az, hogy mi költözik hova nézőpont kérdése. A lényeg ugyanaz, hogy a CPU és a GPU egy lapkában lesz, és komplett platformot ad. Aztán mellé rakhatsz akármit, akár két foglalatot is csinálhatsz az alaplapon, a lehetőségek határtalanok, ám az alapkoncepció mindig az integráció.

    dezz: ezen ne múljon. :)

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • freeapro

    senior tag

    válasz lenox #156 üzenetére

    DirectX, OpenCl egy szoftveres API. Ha eddig DX-ben kiadtad a Draw parancsot, az először felinicializálta (PCIe csatornán keresztül) a diszkrét GPU-t egy adott feladatra, aztán átnyomta a VB-t a PCI csatornán, átküldte a paramétereket PCI csatornán. Ha ez hatékony lenne, akkor nem írták volna le, hogy batch-ben köldd az adatokat megspórolva az inicializálást minden objektumra és VB küldést.

    Ez hogy fog kinézni fusion-ban? Driverek, oprendszerhívások és I/O műveletek helyett majd valami microcode fut le az APU-ban. Adat utaztatás helyett majd valami közös cache adatcsere lesz (nem a Brazos-ban!).

    A többszáz wattot zabáló csúcs diszkrét GPU-kat nyilván nem fogja lehagyni, hiszen a csúcsteljesítményért a legújabb csúcs játékodért hajlandó vagy pazarolni, de SOKKAL HATÉKONYABBAN MŰKÖDIK!

    Ez a lényege! Érted? És mivel ott van a prociban és egyszerű használni egy csomó ma még előre sem látható lehetőség van benne.

    Pl gondolj bele ma hány grafikai és fizikai engine van a piacon. Kevés. Agyon kell optimalizálni, hogy működjön valahogy, ami pénz és idő igényes. Ezt csak nagy gyártók engedhetik meg maguknak. Így a PC játékpiacon ma csak drága és kevés játék van. Okostelefon fronton sokkal élvezetesebb és egyszerűbb játékok vannak amiket lényegesen kisebb cégek csinálnak.

    [ Szerkesztve ]

  • lenox

    veterán

    válasz freeapro #161 üzenetére

    Na pont a directx-hez szinte semmit nem ertek, bocs. OpenGL, OpenCL, Cuda az oke. Szoval ha az opengl-re gondolok egyreszt nem gondolnam, hogy belathato idon belul driver nelkul mukodjon csupan mikrokoddal, de nem is ez a lenyeg, hanem hogy jo nagy szoftver overheadje van, nem a pcie latency az erdekes.

    Szerintem en is pont azt irtam, hogy fogyasztas szempontjabol kiraly, csak el kene olvasni. Nekem annyi nem tetszik, hogy itt ajnarozzatok az integraciot, hogy ez mar lehetove teszi a heterogen processinget, ami eddig ertelmetlen volt, mert a pcie busz visszafogta. Egyreszt eddig is koszoni mukodott, masreszt ez a mostani egy igen pici lepes ebbol a szempontbol.

    #160 Termeszetesen van, mar irtam is, hogy milyen kellene legyen a killer rendszer, a mostani sok szempontbol jo, spec heterogen processing hatekonysaga szempontjabol eleg kis lepes az eddigiekhez kepest, lasd eddigi hozzaszolasaim, hogy miert. Ehhez kepest te ugy allitod be, mintha eddig semmit nem lehetett volna csinalni, most meg mar mindent, ezzel en nem ertek egyet.

  • Abu85

    HÁZIGAZDA

    válasz lenox #163 üzenetére

    Működött a heterogén programozás CPU és GPU-ra, de az APU hatékonyabb. A mostani lépés az első ebből a szempontból, az AMD-nek volt bátorsága meglépni. De idén még több gyártó meglépi ugyanezt, csak nem PC-s architektúrával.

    Én a hírben azt állítottam, hogy a fúziós (integrációs) modellel egy csomó út nyílik meg előtted. A cikk első fele ezt taglalja. Nyilván ez fontos kérdés, mert a júzer látja, hogy mindenki integrál, de senki som érti miért.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Bogyó bá'

    nagyúr

    válasz Abu85 #164 üzenetére

    Mi lehet az oka, hogy a processzorgyártók nem a chipkészletektől próbálnak "megszabadulni", a processzorba integrálva azt? Néha nagyobb fogyasztású, mint maga a processzor (pl. Intel Atomos chipkészletek...) Korszerűtlen gyártástechnológiájuk miatt (65nm - 90nm) a fizikai méretük is túl nagy, sőt többnyire még az alaplapi "hang-kodek" is külön IC. Miért nem ezeket a viszonylag egyszerű áramköröket építik egybe a processzorral?

    Galilei halott! Már Einstein sem él! ...és én is nagyon szarul érzem magam...

  • Abu85

    HÁZIGAZDA

    válasz Bogyó bá' #165 üzenetére

    Az északi híd már teljesen ott van a prociban, hiszen ha megnézed a Fusiont, és az Intel Sandy Bridge rendszerét, akkor integrálva van a memóriavezérlő, és a PCI Express vezérlő. Most a GPU-n volt a sor. Az ultra alacsony fogyasztású rendszereknél egy éven belül elérhetjük a teljes integráltságot, vagyis a PC-ben is megjelenik a SoC. Az ARM-os rendszerek már ilyenek.
    A déli hí integrálásával az fő baj, hogy aránylag sok extra lábkivezetésre van szükség. Az ilyen Atom jellegű dizájnba 500 maximum 550 láb fér bele. Ha ennél több, akkor az jelenleg már nem jó.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Bogyó bá'

    nagyúr

    válasz Abu85 #166 üzenetére

    Tudom, hogy a fizikailag kialakítható lábak száma korlátozó tényező, de pont egy netbook/nettop kategóriájú (ahol leginkább számítana a méret és fogyasztás) gépet amúgy sem szokott az ember ezernyi perifériával bővíteni. 1 db SATA port, sztereó hang, 3-5 db USB (3 db külső + 1 db a beépített kártyaolvasónak + 1 db a webcamnak)
    a legtöbb esetben elegendő lenne...

    [ Szerkesztve ]

    Galilei halott! Már Einstein sem él! ...és én is nagyon szarul érzem magam...

  • Abu85

    HÁZIGAZDA

    válasz Bogyó bá' #167 üzenetére

    A lábak számától függ a nyomtatott áramkör bonyolultsága is. Jelen pillanatban ennyire van lehetőség. Ha nagyon méret állnak rendelkezésre, akkor nyilván lehetne többet tenni, jobban integrálni, de a Brazos egy kis kiterjedésű platform, vagyis egy fizikai mérethatárba be kell férni. A jelenlegi technológiák mellett ennyi lehetséges. Annyira a SATA nem probléma, inkább a PCI Express csatornák száma fontos. A Brazosban 4+4 van egy-egy lapkában. Nyilván a jövőben lehet még jobban integrálni, de jelenleg egy Hudson M1 komplexitású déli híd integrálásával nem jársz jobban.
    Amit leírsz az jó egy netbookba, de notebookba, nettopba, SFF PC-be és alaplapra több kell. A Brazos a netbook mellett még ezekre a piacokra is nevez.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • con_di_B

    tag

    válasz lenox #156 üzenetére

    Ahogy tetszik, nyugodtan lenezhetsz, szerintem van mar akkora szakmai elismertsegem, hogy ebbe ne halljak bele.

    Csigavér, attól még, mert nem értek egyet veled mindenben, még nem nézlek le. Én legalábbis. :) Tetszettek a demóid egyébként. Forrást nem akarsz fölrakni?

    [ Szerkesztve ]

  • lenox

    veterán

    válasz con_di_B #169 üzenetére

    Nem volt eddig erdeklodes egyaltalan. Mondjuk ha jol ertem te akartal engem bevezetni a gpuk rejtelmeibe es nekem sem tartott par oranal tovabb, ugyhogy feltetelezem magadtol is menne, de mondd, hogy mire vagy kivancsi.

  • con_di_B

    tag

    válasz lenox #170 üzenetére

    Arra, hogy hol bottleneck-es AMD-n, csak szakmai érdeklődés, de nem muszáj akkor, ha még mindig így állsz ehhez a beszélgetéshez. Ha kódot szeretnék lopni, nyilván nem így kezdeném. :D

  • dezz

    nagyúr

    válasz DRB #117 üzenetére

    "Pont ugyan úgy kell programozni ezt is, mint ahogy eddig is kellett egy CPU(akár több magos)+ diszkrét GPU párost."

    Most miért is ismételgeted ezt, dacára annak, hogy már többször is leírták, személy szerint neked, hogy nem így van? :U (Főleg, hogy ezt már a HD3xxx-től méred.) Esetleg elkerülte a figyelmedet con_di_B #82-es hsz-e? Idézem:

    "A HD3000-es szériánál még csak a Stream volt (Close To Metal?), a HD4000-esek tudnak OpenCL 1.0-át, atomi műveletek és osztott memória támogatás nélkül (= félkarú óriás), és csak a HD5000 után beszélhetünk elfogadható OpenCL támogatásról"

    Tudod, mi volt a Close To Metal? Egyfajta ASM kódolás... A OpenCL már nem ilyen, de az 1.0 meglehetősen kezdetleges volt. Oké, hogy HD5000-től már volt 1.1, no de arra alapuló IGP még nem létezett.

    Továbbá, az OpenCL (vagy akár a DirectCompute) alkalmazása is teljesen más, mint a CPU-s többszálúsítás.

    Ha mindezt továbbra sem érted, hát tényleg maradj a kaptafánál, akarom mondani a multimédiánál... ;)

    lenox: Világos, hogy sok feladatnál sokkal többet számít a nagy memóriasávszél, mint a késleltetések (bár általában nem árt, ha az utóbbi elfedhető). Ezek főleg olyan műveletek, ahol nagyon sok adattal, de nem túl bonyolult műveleteket kell végezni. Végülis a játék-grafika is ilyen. De vannak olyanok is, ahol kevesebb adattal, de jóval bonyolultabbakat. Ilyen lehet adott esetben pl. a ray-tracing (meg ugyebár itt fontos a véletlenszerű memóriahozzáférés hatékonysága is, tekintve pl. a VRAM és a main ram eltérő időzítéseit). Ezeknél elég lehet az a 27 GB/s (feltételezem, ez a Llanora vonatkozik), illetve később "jelentősen több". (Meg ha most nincs, később biztos lesz hozzáférés a L3-hoz is.)

    A Zacate-t (és az Ontariot) meg nyilván az IGP-k és low-end kártyák szintjén kell megítélni ilyen szempontból, nyilván nem egy súlycsoport egy komolyabb GPU-val, akármennyire is egy APU.

    Elég baj, ha ilyen sokáig tart 1-1 számítási feladat indítása a GPU-n, ezen később bizonyára jelentősen javítanak majd, pl. az OpenCL1.2-ben.

    [ Szerkesztve ]

  • lenox

    veterán

    válasz dezz #172 üzenetére

    Veletlenul talaltam:

    http://www.gdiamos.net/papers/cudaLatency.pdf

    Erdekessegkeppen az a konkluzio, hogy a pcie bandwidthnek es latencynek alig van hatasa a teljesitmenyre... Ezt mar hallottam valakitol :). Nyilvan fentartassal erdemes kezelni, mert erosen alkalmazasfuggo.

    [ Szerkesztve ]

  • nandon

    tag

    Engem lelkesít ez az AMD-s cucc... Vannak kétségeim, de az a szoftveres támogatás felfutási ütemével kapcsolatos... :)
    Egyébként meg, az AMD nem engedhet meg magának túl nagy bakikat, mert ő a kisebb :)

    Ezt világosan mutatja az x86 elmúlt 10 esztendeje (K7-K8-Ati felvásárlás-K10).
    Az AMD piaci részesedése akkor sem tükrözte a technikai erőviszonyokat, amikor az AMD birtokolta a "legerősebb asztali CPU" címet.

    RISC86 Power

  • con_di_B

    tag

    válasz lenox #173 üzenetére

    "Even though the results presented in this paper strongly
    suggest that existing CUDA applications are not sensitive to
    the latency or bandwidth of the GPU-CPU link, it may be
    that applications developers are forced to spend extra efforts
    to achieve this property when designing CUDA applications.
    It is still the case that most CUDA applications are developed
    and deployed on discrete GPU systems due to their significant
    share of the total GPU market."

    Szóval ahogy mondtad, ők is óvatosan fogalmaznak azért.

  • Brown ügynök

    senior tag

    Ígéretes. Ezek a mérnökök megérdemlik a "Jómunkásember" címet.

    "hacsak nem jön a jó tündér break utasítás képében..."

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