- LG C3: egy középkategóriás OLED tévé tesztje
- Fujitsu Siemens Amilo topic
- Hogy is néznek ki a gépeink?
- Milyen egeret válasszak?
- Fejhallgató erősítő és DAC topik
- Projektor topic
- Végre prezentálta a Snapdragon X szériát a Qualcomm
- Gaming notebook topik
- DUNE médialejátszók topicja
- Philips LCD és LED TV-k
Hirdetés
-
Júniusban végre bemutatkozhat az új Gears of War játék
gp Több mint négy és fél év telt el az utolsó rész óta, szóval ideje lenne megkapni a folytatást.
-
LG 34GS95QE-B: OLED paneles, ívelt gamer monitor
ph Félmillió forintba kerül az LG új, 240 Hz-es gamer monitora. Megnéztük, mit tud!
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
Új hozzászólás Aktív témák
-
Fiery
veterán
"Az AM1 platform egyébként az Intel, kivezetés alatt álló Bay Trail-D megoldásai ellen indul harcba"
Kivezetés? Epp ma irtatok egy uj Asus alaplaprol, amin Bay Trail-D SoC talalhato --> Passzív hűtésű, Mini-ITX méretű Intel Bay Trail alaplap az ASUS kínálatában is
Az egy dolog, hogy a B3 steppinges Bay Trail-M SoC-okat az Intel kivezeti, de attol me'g a Bay Trail-D vigan keszul tovabb, es nyilvan a C0 steppingen a Bay Trail-M is tovabb fog keszulni (sot, velhetoen mar most is gyartjak).
-
Duck663
őstag
"illetve Athlon és Sempron márkanévvel kerülnek majd a piacra"
Komolyan nem értem a marketingeseiket!
Van egy FX-ük, jó az olyan amilyen, de talán ahhoz kellene igazítani az elnevezést is.
Az APU-k mik? A8 meg A10? Lényegében nincs márkanevük.
Erre meg a már majdnem elfelejtett Athlont meg a Sempront aggatják?!
Inkább használnák a GX-et az APU-kra, amivel nyomatékosíthatnák, hogy az egy grafikára kihegyezett megoldás. Míg ezeknél az EX-et (efficient) amivel hogy hatékony. Jól és könnyen megjegyezhető és az FX mellé passzoló elnevezés lenne. Olyan lenne, mintha egy termékskálájuk lenne. Bár lehet ez számukra talán furcsa is lenne, hogy nem összevisszaság van...
Na meg a tok elnevezéshez is csak gratulálni tudok, véletlenül se megtévesztő! :S
Igen-igen, még mindig Win7-et használok, és ha így haladunk még 2030-ban is így lesz.
-
Fiery
veterán
Az AMD-nel ennel gazosabb termeknevek is vannak, pl. G meg R [link] [link]
A tokozas elnevezese pedig csupan atnevezes. A tokozas eredeti neve Socket FS1b, es mobil gepekbe tervezte az AMD eredetileg. A Gigabyte honlapjan az AM1 socketes alaplapok a Socket FS1b kategoriaba lettek bepakolva --> [link] Csak hogy egyertelmu legyen
[ Szerkesztve ]
-
arn
félisten
Kedves amd, a profit a nuc szeru gepekben van.
facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld
-
Fiery
veterán
Az APU nevekben az AMD nem az Intelt, hanem inkabb az Audit masolja szerintem, csak nem eleg ugyesen A rating szamozasnal az Intelt masoljak, de igyekeznek mindig 2-3 ezres elonyt tartani, ezzel sugallva, hogy mennyivel jobb a(z A10-)7850K, mint a (Core i7-)4960X
[ Szerkesztve ]
-
Fiery
veterán
Az FS1b eredetileg velhetoen a mobil Kaverihez keszult volna, de abbol (es utodjabol, a Carrizobol) vegul csak BGA tokozasu variacio kerul notebookokba, vagy inkabb ultrabookokba. A Kaveribol FP3 lesz, a Carrizobol pedig FP4. Ez utobbi 2 kozott a memoria tamogatas az alapveto kulonbseg, az FP4 mar DDR4-et is tamogat a megszokott DDR3 mellett.
[ Szerkesztve ]
-
Blindmouse
senior tag
Miért nem as i7 ellen küldenek valamit? [\trollmode]
3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace
-
mx/z
csendes tag
Meglep hogy már csak 1 hónapot kell várni a boltokba kerülésre,a kabini bevezetése
óta már eltelt 1 év is.[ Szerkesztve ]
-
ukornel
aktív tag
Szerintem, ha komolyan gondolják a Bay Trail elleni harcot, nem ártana kétcsatornás memóriavezérlő bele.
(Mondom ezt elégedett e-350 használóként)
-
Fiery
veterán
válasz Blindmouse #15 üzenetére
Mar megjelent, A10-7850K "Kaveri"-nek hivjak.
-
vinibali
őstag
ennek a SoC platformnak viszont szerintem tényleg bga-zva lenne értelme
BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/
-
dezz
nagyúr
Az Athlon, Sempron nevek még rendben vannak, na de mi a fenéért kell egy (kvázi) új foglalatot egy régi elnevezési struktúrába tenni? Aztán lesz majd AM2 és AM3 is!? (Amik már voltak.)
[ Szerkesztve ]
-
stratova
veterán
Legalábbis, ha nem terveznek 2 GHz-nél gyorsabb variánst, de Beema inkább a jó teljesítmény/fogyasztás irányába lép előre (ami nem feltétlenül baj, sőt) kimondott órajelhajhászás helyett.
Nem teljesen világos miért kell törölni a foglalatot a mobil vonalról. Számomra éppen az volt szimpatikus, hogy bár Intelnél lassan a legnagyobb példányszámban eladott APU-k többsége BGA, Trinitybõl még több volt az rPGA.[ Szerkesztve ]
-
Kronos3000
senior tag
Foglalat,elnevezés ide vagy oda,nekem tetszik ez a dolog.Az AM1 elnevezésen azért ledöbbenetem.Ha valami Mini Itx-es cuccot össze tudnék rakni belőle értékelhető teljesítménnyel,pláne normális áron,akkor az első vevők között lennék.ITT 60Usd-t említenek a lap+proci párosra,és ennyiért már bingo lenne.
[ Szerkesztve ]
Wasabi...
-
stratova
veterán
válasz Kronos3000 #23 üzenetére
Sokkal drágább nem is lehet az Bay Trail-D alapú lapra integrált Cerkás alaplapok várható árát figyelembe véve.
-
stratova
veterán
Mondjuk ahogy a "jelenlegi" Kabini kínálatot elnézem, nem árthat ha cserélhető vérmesebb példányra az az APU, már ha a konkurens termékpaletta órajeléből és CPU teljesítményéből indulunk ki. Ami viszont már most érdekes lehet, mi a legkisebb Kabini APU ami (ha képes ilyesmire) támogatja/támogatni fogja a HVEC gyorsítását.
-
Blindmouse
senior tag
http://www.tomshardware.com/reviews/a10-7850k-a8-7600-kaveri,3725-10.html
jah, főleg hogy még az i3-nál is lasabb sokszor. végkövetkeztetés: Athlon X4 740 and a Radeon HD 7750 gyorsabb, és olcsóbb. De várjunk mert a következő generáció majd milyen zsír lesz. Ezt halljuk 8éve az AMD-től.
Az a legnagyobb bajom, hogy eggyik gyártó sem képes épkézláb CPU-t letenni az asztalra évek óta. Videókártya nélkül, arra öszpontosítva amire kellene.[ Szerkesztve ]
3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace
-
dezz
nagyúr
válasz Blindmouse #27 üzenetére
"Az a legnagyobb bajom, hogy eggyik gyártó sem képes épkézláb CPU-t letenni az asztalra évek óta. Videókártya nélkül, arra öszpontosítva amire kellene."
Ez a két mondat a totális meggondolatlanság iskolapéldája. Mit gondolsz, van ennek valami köze a gyártástechnológiai határok feszegetéséhez? És, ha már így nem megy, másképpen nem is érdemes próbálkozni? Pl. a nagy tartalékokat hordozó GPU számítási teljesítményének kihasználásával?
Összteljesítményben 2x erősebb a 7850K, mint az i3 és az i7-est is lenyomja. Arról már nem az AMD tehet, hogy a programozóknak nincs elég motivációjuk.
ps. bahh, videókártya...
-
Fiery
veterán
A GPU szamitasi teljesitmenyenek kihasznalasahoz kellene elso korben egy olyan compiler keszito, aki nem impotens modon vegzi a munkajat. Adott egy viszonylag egyszeru OpenCL 1.x kernel, ami SHA-1 digest-et szamol (hash). Remekul fut minden AMD, Intel es nVIDIA GPU-n, a legujabb driverekkel. Gyanutlan juzer felrakja a Catalyst 14.1 vagy 14.2 betat, es onnantol az eddig jol mukodo szoftver random modra hibas hash-t szamol a VLIW-es Radeonokon (GCN-en tovabbra is jo, Catalyst 13.xx szinten jo VLIW-vel is). Persze az egesz nem derul ki, hiszen a hash tipikusan nem valami olyasmi, aminek az eredmenyet tudnad vagy akarnad ellenorizni. Ennyit a GPU szamitasi teljesitmenyenek kihasznalasarol. Es ez csupan egy a sok compiler bug kozul, amivel leginkabb az AMD es Intel OpenCL compilerei fertozottek. Ha ugyanezt a hash szamitast megcsinalod AVX2-vel vagy sima x86-tal, nincs folyamatosan valtozo compiler, es nincs driver frissiteskor alattomosan magatol elromlo eredmeny. Arrol meg aztan ne is beszeljunk, hogy milyen bonyolult, nehezkes es idegesito a GPU-s fejlesztesnel a hibakereses, a profilozas (amit az AMD OpenCL implementacioja szinten hibasan vegez) es az optimalizacio is. De ha az AMD eddigi buveszkedeseit vesszuk alapul, akkor az idei evet huzzuk at megint, es irjuk le a papirra a "
2008200920102011201220132014lesz a mi evunk. Alairas: AMD+GPGPU"-hoz a 2015-ot. A remeny hal meg utoljara.[ Szerkesztve ]
-
katt777
félisten
Egyetlen hasznos procijuk van, a 6800K.
dezz: "Összteljesítményben 2x erősebb a 7850K, mint az i3 és az i7-est is lenyomja." - Ezt a marhaságot honnan vetted? Még a 6800K-mat sem nyomta le. Ha a GPU-ra gondolsz, akkor sem állja meg a helyét. A HD4600 az i5-ömben mindössze 17%-kal lassabb a HD8670D-nél, miközben utóbbit alaposan tuningoltam (amennyire lehetett), előbbit meg alapon teszteltem. Annyival nem erősebb a 7850K IGP-je, hogy ennek a dupláját hozza.
[ Módosította: PROHARDVER! ]
Funkcionális analfabéták kíméljenek!
-
katt777
félisten
Azért váltottam le, mert összejött az i5-re való. Azelőtt meg éppen azért vettem, mert ez az egyetlen értelmes procijuk, és bőven ellettem volna vele akkor is, ha nem jön össze az i5, mert egy tuningolt 7870XT alatt sem dolgozott 80%-nál magasabb terhelésen. No de az árának majdnem a dupláját elkérni egy gyengébb (7850K) prociért... ez számomra inkább egy IQ-teszt.
Ja, és amíg nem teszteltem saját magam, én is azt hittem, hogy az Intel sokkal gyengébb IGP-vel bír, mint az AMD. Amire viszont az IGP megfelel (hogy valamiképp játsszon az ember, amíg nincs VGA-ja), arra mind2 OK, és mint említettem, HD4600 is tuningolható..Funkcionális analfabéták kíméljenek!
-
mckay
aktív tag
szuper hír
és a fórum is hasznos hozzászóval oké,
- nem elírás, vagyis az Intelnél nem vezetnek ki, hanem csak továbbra is be (méghozzá a C0-t)
- nem elírás, vagyis az AM1 tényleg új (és talán nem csak kabini)de mikor???????????
olvasom itt PH-n a jobbnál jobb híreket, aztán a nagykerekben meg semmi, még hónapokkal később sem
és ez megy évek óta
nem lehetne a híreket a magyar piacra igazítani? akkor már inkább ne is írjátok meg, ha úgyse lehet majd kapnipersze időtöltésnek jó, és örülök hogy megint akadt egy apropó, hogy arról beszélgessünk, hogy merre megy a hajó, és hogy az AMD lemarad-e róla vagy sem
de a kis boltomban ezeket az infókat (amiket munkaidőben szívok magamba) nem tudom pénzre váltani
a disztribnél ugyanis semmi ilyesmi nem volt, és fogadjunk, hogy nem is lesz
márpedig ha nem tudom a polcra tenni, akkor halott infó, nem hoz nekem profitotstratova,
persze, azért köszi a képet, csak hát pont a képeid miatt jött le végleg az ékszíj nálam
merthogy ezek szerint ilyent is árulhatnék vagy fél éve, ha nem Magyarországon lenne a boltom:
http://www.anandtech.com/show/7011/computex-2013-kabini-in-a-brix-haswell-toomintahogy az elmúlt hónapokban a PH-n olvasott 2-4 magos ITX lapokat sem látni a nagykerekben, hát még a Thin ITX lapokat!
de ha látnánk is, fadobozba rakjam őket?szóval remek, ezt is megtudtam, valahol létezik AM1
bocs, troll voltam, de persze nem rátok haragszom, és igazából még csak nem is a PH-ra
megpróbálok egy hétig nem kattintani
-
Komplikato
veterán
FaceBookon Asus mITX és mATX lapját nagyban reklámozzák, de ára az még nincs(!) és csak 5 hét múlva lesz hivatalosan kiadva. Akkor meg minek?
Egyébként nem tudja valaki, az AMD TrueAudio támogatja a moziást is? mert ha igen, akkor elég jó kis HTPC alap lesz az AM1 platform."Figyelj arra, aki keresi az igazságot és őrizkedj attól, aki hirdeti: megtalálta." - (André Gide)
-
dezz
nagyúr
"Ezt a marhaságot honnan vetted?"
"Még a 6800K-mat sem nyomta le."
És nem csak a GFLOPS és IOPS számít, a GCN fejlesztésénél kiemelet szempont volt a GPGPU-s alkalmazás (GPGPU = a GPU általános célú [general purpose] számításokra való használata).
"A HD4600 az i5-ömben mindössze 17%-kal lassabb a HD8670D-nél"
Miben? NV/Intel finanszírozású játékokban fps-ben? Kicsit másról van szó.
(#30) Fiery: Tudjuk, hogy minden alkalmat megragadsz az OpenCL lejáratására, de a béta driverek szídásával kicsit túllősz a célon.
(#47) Blindmouse: Mondod te, totális laikusként. Ilyen alapon nem létezne a GPGPU fogalma, de még a SIMD kiterjesztések sem a CPU-kban.
Mellesleg van már szoftver, ami kihasználja és elég szépen profitál belőle: [link]
[ Szerkesztve ]
-
Fiery
veterán
"Tudjuk, hogy minden alkalmat megragadsz az OpenCL lejáratására, de a béta driverek szídásával kicsit túllősz a célon"
En nem jaratok le semmit, az OpenCL meg az AMD jaratja le sajat magat es az OpenCL-t egy fust alatt ezzel a minosegi munkaval. Amugy meg szerinted az normalis, hogy ilyen alattomos hiba kerul egy betas driverbe? Pont egy olyan driverbe, amit kiehezve varnak a GCN tulajok a Mantle miatt, es eszvesztve telepitenek fel minden Radeonra? Es egyebkent azt is leirtam fentebb, hogy nem ez volt az egyetlen hiba, amit az AMD (es Intel) OpenCL compilere kapcsan talaltunk az elmult cca. 1 ev soran, es nem csak betas, hanem WHQL driverek hasznalata soran is. Nagyon szivesen visszaterek erre a temara, ha megjelenik az elso idei WHQL Catalyst, aminek azert valljuk be, ideje lenne, igy marcius eleje tajan. Nagyon kivancsi leszek, a WHQL Catalyst 14.x javitani fogja-e ezt a hibat.
Megjegyzem, ha ezek a betas driverek kizarolag egy belso kor (pl. NDA alatt) szamara lennenek elerhetoek, semmi problema nem lenne egy-egy ilyen hibaval, es en sem hoztam volna fel ezt a temat. A gond az, hogy Radeon tulajdonosok tiz- meg szazezrei telepitik fel gyanutlanul a betas Catalystokat, aztan csodalkoznak, hogy az addig jol mukodo szoftverek benazni kezdenek. Vesd ezt az esetet ossze azzal, hogy van egy pre-compiled x64/AVX/AVX2 kodod, ami nem tud elromolni csak azert, mert az egyik gyarto osszelapatolt valami bena drivert. Igen, ott a potencial a GPU-kban, de ha igy benaznak a gyartok, akkor sosem fogja az "average Joe" juzer kihasznalni azt.
"Mellesleg van már szoftver, ami kihasználja és elég szépen profitál belőle:"
Orulok, hogy egyes szamot hasznaltal. Igen, van, egy. Esetleg ketto, ha a JPEG dekodolast is szoftvernek titulaljuk (ami nem az). Vagy harom vagy negy, ha a benchmarkokat is szoftvernek cimkezzuk. A jovo szebb lesz, tudjuk. Csak en mar kezdek 3DNow! szagot erezni. Tudod, amikor ott a potencial, csak a vegen a masik gyarto hasonlo (csak epp nemileg fejlettebb) technologiaja gyoz, es az egyebkent jopofa AMD-s potencial vegul parlagon hever a CPU-ban generaciokon at.
[ Szerkesztve ]
-
-
Fiery
veterán
Attol, hogy csak a GCN tulajok vartak, nem csak ok fogjak felrakni. Mivel az AMD-nel a termek generaciok kulonvalasztasa nem egyertelmu, siman felrakja mindenki, akinek minimum HD7000-es GPU-ja van. Azaz, felrakjak a Trinity meg Richland tulajok is, a HD7350 es HD7450 tulajok is, stb. Arrol meg aztan ne is beszeljunk, hogy a juzerek tobbsegenek fogalma sincs, hogy melyik GCN es melyik nem. A HD6000 (VLIW) tulajok is felrakjak, valogatas nelkul, mert ujabb, mert idei, mert a havertol jokat hallottak rola, mert a mediabol meg a csapbol is az folyik allandoan, stb. Vagy Neked van ennel pontos statisztikad arrol, hogy a Catalyst 14.x tulajok kozul hany %-nak van GCN alapu Radeonja, es hanynak VLIW?
"Melyik gyártó OpenCL driverét mondanád jobbnak, az AMD-ét vagy az Intelét?"
Ez legalabb konnyu kerdes. Az nVIDIA OpenCL _compilere_ (olyan hogy OpenCL driver, nincs, csak OpenCL compiler, ami a video driver, pl. Catalyst es ForceWare resze) fenyevekkel jobb minosegu es kiforrottsagu, mint az AMD vagy Intel hasonlo termeke. Ami valahol teljesen normalis, hiszen az nVIDIA elobb is kezdte, es tobb energiat is fektetett a GPGPU-s fejlesztesekbe, mint barki mas lenyegeben. Ha irsz egy OpenCL kernelt, es szintaktikailag hibatlan, akkor jo esellyel nVIDIA GPU-n kapasbol gyonyoruen le fog futni, mindenfele kormonfont modositasok meg takolasok nelkul. A hibakezeles is szebben van megoldva, a profilozas se bugos, sz'al nagyon smooth az egesz. Nem bugmentes, pl. a szinusz fuggvennyel kicsit hadilabon all a FLOPS kerneleknel, de eddig ez volt az egyetlen bug, amit talaltunk az nVIDIA OpenCL compilerben, ami nagy szo, ha a tobbi gyartoehoz hasonlitjuk. Es hidd el, nem vagyok nVIDIA fan, sot. A GCN SZVSZ a legjobb (GP)GPU architektura, ami valaha keszult, a legkisebbtol (Temash) a legnagyobbig (Hawaii), csak epp nem eleg jo vasat gyartani, csinalni kell hozza normalis szoftver stacket is, anelkul megsutheted a vasat.
Szerk.: Kozben rajottem, hogy az AMD vs. Intel temat feszegeted Azt mondom, 50-50. Mindketto problemas, csak maskepp. Az AMD-nel kicsit konnyebb kovetni az OpenCL compiler fejlodeset, az Intelnel a hulye driver szamozas kicsit nehezkesse teszi a dolgokat. Az Intel compilere azert is van elonyben, mert nagyjabol csak 1 architekturat kell tamogatnia (Gen7.x), es nem kell dupla pontossagu lebegopontos szamitasokkal bajlodnia. Nem fair osszevetni oket SZVSZ.
"AVX/AVX2-re miben fog a legtöbb programozó dolgozni, ASM-ben vagy OpenCL-ben?"
Ha az OpenCL igy halad, akkor egyertelmuen assemblyben, vagy sehogy. De azt se felejtsd el, hogy az OpenCL _GPU_ compiler mas tema, mint az OpenCL _CPU_ compiler. Lehet egy GPU compiler f*s, mikozben meg egesz jo AVX kodot fordit a CPU compiler. Ami persze nem igy van, hiszen egy nativ, kezzel optimalizalt AVX kodhoz kepest fenyevekkel le van maradva barmi, amit az AMD vagy Intel OpenCL CPU compilere kepes forditani, de bizonyos felhasznalasi teruleteknel me'g igy is jobb lehet az eredmeny, mint ha sima x86/x87 kodot hasznalna az adott szoftver.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Az AVX-nél az ASM és az OCL mellé be lehet venni a HSA runtime-ot. Az legacy módban fordítani fog AVXxy-ra. Ha a programozók elvárásait nézzük, akkor messze a HSA runtime célzása a legegyszerűbb, mert az nem változik tehát garantált a futás és a befektetett munka is kevés. Ez majd nagy lökés lesz a piacnak.
Az igaz, hogy az ASM nehéz, míg az OCL könnyű, de nem mindig működik, de ne feledkezzünk meg arról, hogy jön olyan is, ami könnyű és működik is. Ezt fogják választani a programozók, például Java-ban, ha nagyon az egyszerűségre törekszünk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
Ha GPU-krol beszelunk, a Java + runtime forditas HSA-val se lesz jobb, mint a mostani runtime OpenCL forditas. Me'g pre-compiled HSAIL-lel se lesz atombiztos, hiszen me'g ott is lesz egy forditasi fazis, ahol elcsuszhatnak a dolgok. Nativ, architektura-fuggo, azonnal futtathato binaris lenne a megoldas a compiler bugokra, de ezt meg nem tul sokan vallaljak be, hiszen marhara nem future-proof.
Ha a CPU-krol beszelunk, ott meg megint bejon az, hogy pl. egy adott OpenCL kernelt le lehet forditani AMD-fele OpenCL CPU compilerrel is, meg Intel-fele OpenCL CPU compilerrel is, ha mindketto telepitve van. Elore meg hogyan dontse el a fejleszto, hogy melyikkel milyen gyors lesz az eredmeny? Az elore leforditott binaris HSA-val megoldas lehetne erre a problemara, de ahhoz elobb legyen legalabb publikus beta HSA implementacio OpenCL es/vagy Java compilerrel. Az, hogy a Catalyston belul ide-oda hakkolva nem dokumentalt DLL hivasokkal be lehet zizzenteni mar most is a HSA-t, az atlag programozo szamara nem opcio.
[ Szerkesztve ]
-
Fiery
veterán
Csak, hogy egyertelmu legyen az uzenete annak, amit firkalgatok: abban igazatok van, hogy az OpenCL meg a HSA azt az igeretet hordozza magaban, hogy marha egyszeruen lehet SIMD meg SIMT kodot kesziteni. Ez, parositva egy remek GPGPU-s architekturaval (pl. GCN) valoban nagyszeru kilatas a jovore nezve. A problema azonban az, hogy pont akkor teszi ki magat az egyszeri fejleszto a legnagyobb rizikonak, pont akkor teszi a vegtermek (szoftver) mukodeset effektive a GPU-gyarto kezebe, amikor ilyen egyszeru eljarasokat probal hasznalni (mint amilyen a runtime OpenCL vagy Java forditas). Az igeretekkel szemben a gyakorlatban az van, hogy irsz egy OpenCL kernelt, nem bonyolultat, nem extrat, csak egy egyszeru kis valamit, es aztan az nem fut, nem jol fut, vagy (video)driver frissiteskor elromlik anelkul, hogy hozzanyultal volna. Ez igy elfogadhatatlan, ez igy nem fog mukodni. Es hiaba lesz HSA meg HSAIL meg Java meg OpenCL 2.0 meg SVM, amig nem iktatjuk ki a folyamatbol a forditasi fazis(oka)t, addig nem lesz megbizhato a kod, amit gyartasz. Kepzeljetek el, milyen remek lenne egy LibreOffice Calc, ami a HSA-val gyorsitott szumma vagy atlag vagy szoras tablazat funkciokat egy driver frissites utan veletlenszeruen elrontja, es valami latszolag jo eredmeny jon ki, amit a szoftver felhasznaloja eszre sem vesz, mert nem "annyira" rossz az eredmeny. Egy cegnel, ahol emberek sorsa mulik nehany ilyen statisztikai eredmenyen, egy-egy ilyen hiba katasztrofat tud(na) okozni.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
De sokkal jobb lesz, mert egy szabványosított virtuális gépen fut. Nem lesz olyan, hogy az egyiknél nem megy, míg a másiknál igen. Vagy mindenkinél, vagy senkinél. A finalizer pedig egy olyan fordítási fázis, ami nagyon alacsony szintű. Az nagyon átlátható, így rendkívül kicsi az esély a hibára. Most is létezik ilyen fordítás mindegyik driverben és sosem ezzel van a gond.
Elég egyértelmű, hogy a fejlesztők számára csak a szabványos vISA+QL jelenti a mindig működő alapot, ha nem akarnak minden egyes létező és érkező architektúrára egyéni binárist szállítani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Fordítási fázis mindig lesz. Sőt egyre több, mert továbbra is változni fognak a hardveres architektúrák. A HSA azt a célt szolgálja már az első pillanattól kezdve, hogy ez a változás ne jelentsen gondot a programok futtatásánál. Ezért tart olyan sokáig kidolgozni, mert minden szempontból garanciát vállal a HSA alapítvány rá, hogy a HSA runtime egységesen fut minden hardveren, és mindig ugyanaz lesz az eredmény. Magát a fordítót is a HSA szállítja, és nem xy gyártó. Utóbbi cégek csak a finalizert szállítják, de az egyszerű, ma sem ezekben van a hiba lehetősége.
De nyilván egyébként a HSA alapítvány nem tiltja meg azt sem, hogy a programozó minden architektúrára ASM-et írjon. Ez a lehetőség mindig élni fog. A választás lehetősége tehát megmarad, sőt így lesz igazán választható irány.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
Természetesen nem előnyös, hogy ilyen bugok, nehézségek vannak, de hát mint tudjuk, ez nem egyedi jelenség. Jelenleg nem tudom, mi a helyzet, de korábban a CUDA-ra is sok panasz volt. Meg hát elég kevés terület van, ahol sima ügy a programozás.
"Az nVIDIA OpenCL _compilere_ (olyan hogy OpenCL driver, nincs, csak OpenCL compiler, ami a video driver, pl. Catalyst es ForceWare resze)"
De van:
"This release includes OpenCL drivers" (egy említés a sok közül) [link],
"Package contains the following graphics drivers and dependent/required software for the products specified in the current version's official release notes for the 32 bit version of Windows 7, Windows 8 and Windows 8.1: Display Driver ver. 13.251, OpenCL(tm) Driver ver. 10.0.1348.5, Catalyst Control Center ver. 2013.1206.1602.28764." [link] -
LordX
veterán
Hogy nV OpenCL jobb, mint a többi? Uhh... Nagyon, nagyon, nagyon, nagyon nem: Le van ragadva OpenCL 1.1-nél (2011 óta nem sikerült az 1.2??), ugyanazt a C kódot CUDA-ként fordítva akár 1,5x gyorsabb, mint OpenCL-el, a host-device másolás olyan lassú, mint a csiga... Politikai okokból ott tesznek keresztbe az OpenCL-nek, ahol tudnak. Ez minden, csak nem "jó". Lehet, hogy relatíve bugmentes, de fícsörmentes is.
-
Fiery
veterán
A teljesitmenyrol nem beszeltem, csupan a compiler minosegerol, vagyis hogy melyik fordit korrekt kodot egy szintaktikailag hibatlan kernelbol. Az AMD-fele OpenCL compiler azt is kepes megcsinalni, hogy egy teljesen rosszul mukodo kodot fordit (driver verziotol meg hardver architekturatol fuggetlenul) az amugy hibatlan kernelbol, hibajelzes meg warningok nelkul. Ehhez kepest mondom azt, hogy az nVIDIA compileret hasznalni felüdülés
"Le van ragadva OpenCL 1.1-nél (2011 óta nem sikerült az 1.2??)"
Melyik OpenCL 1.2 feature hianyzik Neked? Nem vedeni akarom az nVIDIA-t, de tudtommal az OpenCL 1.2 nem egy groundbreaking fejlesztes az 1.1-hez viszonyitva. Vannak benne jopofa kenyelmi funkciok, de messze van a fejlesztesek osszessege es hordereje pl. attol, amit az OpenCL 2.0 hoz az 1.x utan.
"ugyanazt a C kódot CUDA-ként fordítva akár 1,5x gyorsabb, mint OpenCL-el"
Milyen jellegu kernelrol van szo? Egyebkent az nVIDIA-fele architekturalis sajatossagokat nyilvan figyelembe kell venni az OpenCL fejlesztesnel, azzal sokat lehet nyerni tejlesitmenyben. De akár igy (optimalizalas nelkul), akár ugy (figyelembe veve az architekturat) irod meg, "furcsamod" az nVIDIA compilere meglepoen hibatlanul tud dolgozni, legalabbis a konkurenciahoz kepest.
"a host-device másolás olyan lassú, mint a csiga"
Ezt en nem vettem eszre. Milyen dGPU-rol van szo, es milyen gyakran, milyen blokkmeretet masolgatsz? CUDA-val gyorsabb a masolas?
[ Szerkesztve ]
-
Fiery
veterán
Nyilvan a CUDA sem onnan indult, ahol most tart, de velemenyem szerint a jelen helyzetrol erdemes beszelni, a mult mar elmult. Raadasul, ha visszamegyunk X evet az idoben, jo esellyel hasonlo kulonbsegeket talalnak a gyartok kozt, pl. az elejen az Intel is me'g sokkal sz*rabbat csinalt, amikor az nVIDIA OpenCL compilere csak kicsivel volt f*sabb mint most, stb. stb
"De van"
2009-es lapot idezel? Ne vicceljunk mar... Raadasul mar ott is ezt irjak: "OpenCL v1.0 Conformant GPU drivers". Ergo OpenCL-t tamogat a GPU drivere, ami a videodrivernek felel meg. A lenyeg, hogy az OpenCL-hez nem driver kell, hanem az OpenCL tamogatast kell beepiteni a videodriverbe. Onnantol pedig a videodriver reszeve valik az OpenCL compiler, meg az OpenCL API tamogatas. De ne rugozzunk ezen, hivhatjuk igy is, ugy is, a lenyeg hogy mind sz*r, csak maskepp sz*r, es fenyevekre van minosegben minden OpenCL megoldas attol, amit a programozok megszoktak mondjuk a Visual Studio vonalon. Sz*pni lehet minden programozasi feladattal, csak **rvara nem mindegy, hogy a compilerrel szivsz napokat, vagy magaval a feladattal, amin dolgozol. Kepzeld el, hogy napokig, hetekig faragod az algoritmust, megirod nagy nehezen a kernelt, es utana 3-bol 2 architekturan mukodik, az egyiken meg egyaltalan nem. Eleg idegesito tud lenni az ilyen, plane amikor nem is tudsz a dologgal mit kezdeni, mert a compiler gyartojanak kell hetek (vagy inkabb honapok) leforgasa alatt javitani a szemetre valo termeket. Es nem, nem (csak) az AMD-rol beszelek, sajnos a tobbi gyartonak is tobb hetig, gyakran honapokig tart, hogy kijavitsanak egy-egy compiler bugot. Addig meg all a fejlesztesed programozokent, vagy kiirod plecsnivel, hogy "sorry, de AMD-n/Intelen/nVIDIA-n nem mukodik a cucc". Ami meg bena es az end-user szamara nem jo uzenetet kozvetit.
-
Abu85
HÁZIGAZDA
Tökmindegy a hardver. A másolás lassúságát a szoftver miatt van, mint általában minden, ami miatt lassú az NV OpenCL-ben. Volt egy driver a 270-es sorozatban, ami 30-50%-kal is visszavetette az OpenCL teljesítményt.
Ahogy LordX írja ez egy politikai harc. A számok alapján egészen egyértelmű, hogy ma 170 professzionális szoftver támogatja az OpenCL-t, és másfél éve ez a szám 60 volt. Ergo az ipar a CUDA-ról OpenCL-re áll át. Néhányan a CUDA kódot csak úgy kivágták, mert nyomást akarnak gyakorolni az NV-re.
Még olyan is van, hogy az Autodesk 3ds Max az Active Stereo funkciót csak FirePróra engedélyezi. Semmi technikai hiányosság nincs erre, de a cég FirePrókat akar látni az ügyfeleik gépeiben csak azért, hogy az NV-t rávegyék a szabvány normális támogatására.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
"2009-es lapot idezel? Ne vicceljunk mar..."
De jó, hogy csak az egyik idézetet nézted meg... Az AMD-nél azóta is mint OpenCL driver jelenik meg, ami korábban külön csomag volt, most már az alap drivercsomag része, de custom installáláskor most is választható opció (default on).
Ja, és az Intelnél is OpenCL driver van.
Hát tudod, elég furcsa, hogy ez neked most újdonság...
"Raadasul mar ott is ezt irjak: "OpenCL v1.0 Conformant GPU drivers". Ergo OpenCL-t tamogat a GPU drivere, ami a videodrivernek felel meg."
NEM! Ez egy a videodrivertől függetlenül letölthető driver volt! A bevezető megjegyzésben és az összefoglalóban OpenCL drivernek nevezik/rövidítik. Nem látod!? "OpenCL v1.0 Conformant GPU drivers" = OpenCL drivers. (Mint írják, 2009 óta itt is az alap drivercsomag része, de valószínűleg itt is választható, hogy települjön vagy se.)
"A lenyeg, hogy az OpenCL-hez nem driver kell, hanem az OpenCL tamogatast kell beepiteni a videodriverbe."
Hát pedig de, ez egy külön driver.
"Onnantol pedig a videodriver reszeve valik az OpenCL compiler, meg az OpenCL API tamogatas."
Nem, legfeljebb az alap drivercsomag részévé válik az OpenCL driver is, amit szintén feltelepít a telepítő (ha nem tiltjuk meg neki).
"De ne rugozzunk ezen, hivhatjuk igy is, ugy is"
Mintha te kezdtél volna el ezen rugózni, anélkül, hogy vetted volna a fáradtságot, hogy utánanézz a teóriádnak, rám terhelve ennek (link keresés, magával a ténnyel azóta tisztában voltam, amikor megjelentek az első OpenCL driverek, mert már akkor feltettem és használtam) fáradtságát (nem mintha nagy fáradtság lett volna, de mégiscsak).
[ Szerkesztve ]
-
Fiery
veterán
Az a baj tudod, hogy csak a cimeket olvasod el. Pl. a linkelt intel-fele lapon ez all a cimben:
"OpenCL™ Drivers and Runtimes for Intel® Architecture"
Viszont a szovegben meg ott a valosag:
"This software driver package will install the Intel® graphics driver with support for OpenCL"
Ergo a grafikus driver resze az OpenCL tamogatas, nem kulon driver van az OpenCL-hez.
"OpenCL v1.0 Conformant GPU drivers" = OpenCL drivers."
Akkor ezt olvasd el me'g egyszer kerlek A "GPU drivers" szavakat kell egy adott fogalomkent ertelmezni, es onnan kiindulni. Olyan GPU driverrol van szo, ami megfelel az OpenCL 1.0-nak, azaz videodriverrol van szo, ami tamogatja az OpenCL-t. Nem OpenCL driver, mert a (GPU-khoz valo) OpenCL es ugy altalaban GPGPU tamogatas eleve ugy van megoldva (a HSA elotti idokben) Windows alatt, hogy a video driver resze kell hogy legyen. Ezt nem en talaltam ki, hanem igy talalta ki anno az nVIDIA is (bar ok a CUDA-val kezdtek), a Khronos is (OpenCL), es az AMD is (Stream).
"amikor megjelentek az első OpenCL driverek, mert már akkor feltettem és használtam"
Nem mintha ez barmit is szamitana. Plusz, attol, hogy OpenCL drivernek hivjak, me'g nem lesz az. Hivhatod barminek, akkor is csak egy layer a videodriveren, mikozben maga a videodriver kell hogy tamogassa az OpenCL-t. Egy API, ami egy-ket DLL fajlbol all, me'g nem lesz driver, az kicsit mas teszta (ld. kernel driver). OpenCL runtime, az mar kozelebb all az igazsaghoz, de az megint nem driver.
-
Fiery
veterán
CUDA driver azt jelenti, hogy ForceWare, azaz olyan videodriver made by nVIDIA, ami tamogatja a CUDA-t. Olvasd el a szoveget alaposabban, es ki fog belole derulni. De ha nem is akarsz ilyen melyen belemaszni a szovegbe, akkor sincs sok ertelme kulon CUDA driverrol beszelni, hiszen mar jo nehany eve a CUDA tamogatas a ForceWare videodriverek szerves resze. Sokkal elobb lett a CUDA rendesen integralva a ForceWare-be, mint a Catalystba az OpenCL rendesen berakva, de ezt csak megjegyzem, ez nem itelet az AMD felett. Az AMD-nel a Stream meg annak az elhagyasa es az OpenCL-re atallas nagyon megkavarta a dolgokat.
[ Szerkesztve ]
-
dezz
nagyúr
Jó lenne, ha:
1. Nem csak azokra a dolgokra válaszolnál, mazsolázva, amik számodra kedvezőek. (Nem először.)
2. Ha nem sugalmaznál olyanokat, hogy én mindig csak a címeket olvasom el, csak mert az Inteles példánál így tettem (mert utólag írtam be és lejárni készült a szerkesztési idő)."A "GPU drivers" szavakat kell egy adott fogalomkent ertelmezni, es onnan kiindulni. Olyan GPU driverrol van szo, ami megfelel az OpenCL 1.0-nak, azaz videodriverrol van szo, ami tamogatja az OpenCL-t."
Nem feltétlen ez a helyes értelmezés, egy a GPU-t computingra kihasználó külön driver is GPU driver.
Lásd ezt:
A HSA bevezetése előtti időt mutató képrészen az OpenCL komponens a kép alapján közvetlenül a GPU-val kommunikál. De még ha nem is közvetlenül azzal, hanem valójában a kernel mode driverrel, vannak user mode driverek is, mint pl. a Direct3D driver, és itt lehet egy OpenCL driver is.
"OpenCL runtime, az mar kozelebb all az igazsaghoz, de az megint nem driver."
Lehet, hogy ez a leghelyesebb elnevezés, de ez már szemantikai vita. Az AMD ~2009 óta OpenCL drivernek nevezte az évekig külön letölthető OpenCL csomagját. És még most is úgy nevezi az integrált telepítőcsomagban. Náluk reklamálj!
Nem beszélve arról, hogy az egész OpenCL nem csak egy compiler, mint eredetileg állítottad.
(#66): Neked is javaslom az alaposabb olvasást, mert több helyen OpenCL driver processről beszélnek, aminek megvan a saját verziószáma is.
-
Fiery
veterán
Tok mindegy, melyik ceg hogyan hivja, ha egyszer nem driver! Ennel egyertelmubben nem tudom elmagyarazni. De tudod mit? Fogd a legujabb Catalystot, a legujabb ForceWare-t es a legujabb IVB/HSW video drivert, es keresd meg benne az OpenCL drivert. Segitek, kernel drivert kell keresni, jo esellyel .SYS kiterjesztessel. Mutasd meg, melyik fajl lesz az. De hogy kedves legyek, me'g egyet segitek: ne faradj, mert nem fogsz ilyet talalni. Amit talalsz, az nehany DLL fajl, ami nem driver, hanem DLL.
"A HSA bevezetése előtti időt mutató képrészen az OpenCL komponens a kép alapján közvetlenül a GPU-val kommunikál. De még ha nem is közvetlenül azzal, hanem valójában a kernel mode driverrel,"
Az engem baromira nem erdekel, hogy egy sematikus abran mit hova nyilaznak. Attol me'g -- ahogy irod is -- ott a kernel driver, ami "erdekes" modon a videodriver resze, es "erdekes" modon megegyezik a kernel driverrel (ld. pl. ATIKMDAG.SYS a Catalyst eseteben vagy pl. NVLDDMKM.SYS a ForceWare eseteben). Meg ott a D3D is, amit nem raktak oda az abrara, pedig eleg fontos Achilles-sarka a jelenlegi OpenCL implementacioknak.
"Nem beszélve arról, hogy az egész OpenCL nem csak egy compiler, mint eredetileg állítottad."
En azt mondom, az OpenCL implementaciok bugos resze a compiler. Az a legkritikusabb komponens, azt lehet elcseszni a legkonnyebben. A tobbi resze engem nem erdekel, mert a tobbi resz mukodik mindharom gyartonal. Ha meg mukodik, minek foglalkozzon vele a 3rd party fejleszto, nem az o dolga.
[ Szerkesztve ]
-
dezz
nagyúr
Már írtam: van olyan, hogy kernel mode driver (.sys) és vannak user mode driverek (mint .dll file-ok).
"ott a kernel driver, ami "erdekes" modon a videodriver resze"
Kiemelés tőlem... A kernel mode driver egy igen alacsony szintű réteg, ami önmagában, user mode driverek nélkül nem sokmindenre használható. Az, hogy ezeket mikor hívják runtime-nak és mikor drivernek (néha meg hol így, hol úgy), mint szintén írtam, szemantikai kérdés.
"En azt mondom, az OpenCL implementaciok bugos resze a compiler."
Ezt írtad: "(olyan hogy OpenCL driver, nincs, csak OpenCL compiler, ami a video driver, pl. Catalyst es ForceWare resze)"
"A tobbi resze engem nem erdekel, mert a tobbi resz mukodik mindharom gyartonal."
Honnan tudod, hogy egy adott helyzetbeni hibás működés forrása nem ez a rész?
Megjegyzem, pl. a WinZIP OpenCL része előbb működött AMD-n (és talán NV-n), mint Intelen. Még évekkel ezelőtt próbálgattam különféle kisebb OpenCL programokat, többnyire azok is gond nélkül futottak mind AMD-n, mind NV-n. Ami nem, az sem bugok, hanem hiányzó funkciók miatt (le sem fordultak adott HW-en). Intelen alig futott valami.
-
Abu85
HÁZIGAZDA
Általában minden OpenCL cucc hamarabb működik AMD-n, mert a fejlesztők többsége az APP SDK-t használja. Ez a legátfogóbb fejlesztőkörnyezet OpenCL-re, illetve rengeteg funkciója cross-vendor szinten is működik. Például a gDEBugger 6 is, ami egy elég fejlett OCL debugger.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"A kernel mode driver egy igen alacsony szintű réteg, ami önmagában, user mode driverek nélkül nem sokmindenre használható"
Rosszul tudod. Egy sima futtathato binaris (.EXE) is be tud tolteni es tud hasznalni egy kernel drivert gond nelkul. Csak hogy ne a sajat hazamtajarol mondjak peldat, ott van pl. a CPU-Z, ami igy mukodik. Es egy mar betoltott kernel drivert is tud hivogatni egy futtathato binaris, nem kell kozejuk feltetlenul egy DLL-nek ekelodnie.
"Honnan tudod, hogy egy adott helyzetbeni hibás működés forrása nem ez a rész?"
Ha ugy lenne, akkor se tudnek vele mit kezdeni. Ha egyszer egy csomagban kapom a gyarto OpenCL API-jat (akarmi.dll), aminek resze az OpenCL compiler, akkor hiaba van itt vagy ott a DLL-ben a bug, attol me'g a forditasi eredmeny sz*r lesz. Ha meg az eredmeny sz*r, nem az en feladatom kutatni a pontos helyet, ahol elcsuszik a forditas az adott gyarto OpenCL implementaciojan belul. Ha az altalunk keszitett szoftver bugzik egy akarmilyen hardveren, nem a hardver gyartoja fogja kideriteni, hogy a mi szoftverunkben pontosan hol a bug, nem az o feladatuk ezzel molyolni.
"Megjegyzem, pl. a WinZIP OpenCL része előbb működött AMD-n (és talán NV-n), mint Intelen."
Es? Ha minket (is) az AMD penzelne, es a lejelentett compiler bugjaikat nem heteken hanem napokon belul javitanak, a mi OpenCL kerneleink is elkeszulhetnenek eloszor AMD-re. Csak tudod mi, mint fuggetlen fejlesztok, nem adnank ki egy OpenCL kernelt, ami nem fut az egyik gyarto GPU-jan. Vagy fusson mindenhol (addig kell nyomatni a compiler fejlesztoket), vagy sehol. Nyilvan kivetel a VIA, amelyiknek a v0.1 Alpha-nal is gyatrabb allapotban ragadt meg az OpenCL implementacioja, ok egyszeruen feladtak a dolgot, nincs ra kapacitasuk.
Megjegyzem, a kulonfele OpenCL-lel kapcsolatos bugok miatt en me'g veletlenul sem biznam mondjuk az adatmenteseimet egy GPU-val gyorsitott tomorito/archivalo szoftverre. Nagyon jol es abszolut megbizhatoan mukodik az a CPU-n, nincs szukseg extra rizikora meg hogy egy videodriver frissites utan egyszercsak alattomos modon elsz*rodjanak az archivalasaink. Ami persze csak akkor derulne ki, ha mondjuk lenne egy adatvesztes es megprobalnank visszallitani a fajlokat... Az ilyen GPU-val gyorsitott WinZIP-pel szorakozas pont addig jopofa, amig nem emberi sorsok mulnak a dolgon.
[ Szerkesztve ]
-
dezz
nagyúr
nem sokmindenre != semmire
nem sokmindenre használható = alapszintű GPU managementet végez"Es egy mar betoltott kernel drivert is tud hivogatni egy futtathato binaris, nem kell kozejuk feltetlenul egy DLL-nek ekelodnie."
Sehol sem írtam, hogy feltétlenül kell, de pl. Direct3D-hez, OpenCL-hez kell, mivel azok implementálják a vonatkozó API-kat.
A 2. bekezdésben (amellett, hogy evidenciák) kicsit mást állítasz, mint korábban.
3.: szóval, nem adtok ki olyat, ami nem fut az egyiken, kivéve, amelyiken nem fut. Korábban az Intel OpenCL drivere is kezdetleges volt, miközben az AMD-é és NV-é már nem. Akár független valaki, akár nem, nem várható, hogy félévekig várjon egy szoftver kiadásával az egyik HW gyártó miatt.
Ha valós veszély lenne, amit a 4. bekezdésben írsz, szerintem a WinZIP kiadója nem vállalta volna a felelősséget.
-
Fiery
veterán
"szóval, nem adtok ki olyat, ami nem fut az egyiken, kivéve, amelyiken nem fut."
A VIA implementacioja nem publikus es nem mukodik rajta semmi, me'g egy egyszeru clGetDeviceInfo hivas sem. Csupan azert emlitettem meg oket, mert belekezdtek, akartak volna csinalni, de beletort a bicskajuk. Ok lettek volna a 4. szereplo.
"Korábban az Intel OpenCL drivere is kezdetleges volt, miközben az AMD-é és NV-é már nem. Akár független valaki, akár nem, nem várható, hogy félévekig várjon egy szoftver kiadásával az egyik HW gyártó miatt."
Egyreszt a multrol beszelsz, mig en a jelenrol, masreszt meg amikor a WinZIP OpenCL implementacioja elkeszult (cca. 2 eve), akkor az nVIDIA-e teljesen franko volt mar, ergo elvarhato lett volna, hogy legalabb AMD+nVIDIA-n fusson. Csak ugye az exkluzivitas nagy ur, az sokat meger az AMD-nek meg a tobbieknek is adott esetben
"Ha valós veszély lenne, amit a 4. bekezdésben írsz, szerintem a WinZIP kiadója nem vállalta volna a felelősséget."
Kar, hogy az OpenCL compilert nem ok keszitik, tehat toluk fuggetlenul barmikor elsz*rodhat az egesz GPU-gyorsitott tomorito szoftveruk Ok meg felteszik a kezuket, hogy az "AMD volt!" De ha szamodra abszolut megnyugtatonak tunik a WinZIP GPU-gyorsitasa, nyugodtan hasznald, nekem teljesen mindegy, ki mit hasznal.
[ Szerkesztve ]
-
Fiery
veterán
Nem mondtam, hogy hazudnak. De ezt az oldalt erdemes megnezni --> [link] Az URL onmagaban is felettebb erdekes. Meg az a 4 db AMD vagy AMD technologiahoz kapcsolodo logo sem arra utal, hogy ez egy fuggetlen, OpenCL-hez kotodo fejlesztes. Eleve "AMD OpenCL technology" neven hivatkoznak ra... Ha ez egy kifejezetten nem exkluzivitasra torekvo fejlesztes lett volna, akkor nem lett volna a lapon ennyi AMD logo, nem lett volna ennyiszer hangsulyozva, hogy ez egy AMD technologiakhoz kotodo fejlesztes, es ott lett volna csillag/kisbetuvel, hogy "Coming soon for nVIDIA and Intel GPUs". Ami persze utana meg is tortent, azaz elkeszult a masik 2 gyarto GPU-ira is a portolas.
Lehet, hogy ez az egesz csak arra volt jo, hogy nyomast gyakoroljon a WinZIP keszitoje (Corel) az nVIDIA-ra es Intelre, hogy szorosabban egyuttmukodjenek a WinZIP OpenCL-re portolasaban, es kijavitsak a bugos compilerekeit. Ez -- mar ha ez tortent -- a tortentek fenyeben hatott is a gyartokra, csak epp igy utolag mar nehez eldonteni, hogy mi volt a motivacio valojaban. Mindenesetre, ha emelle odatesszuk, hogy a Corel tunik a HSA legnagyobb (PC-s szoftverkeszito) tamogatojanak, akkor szamomra eleg egyertelmu a konkluzio -- de mindenki hozza meg sajat hataskorben a kovetkezteteseket es teoriakat.
((( Ezen felul vannak me'g birtokomban olyan informaciok, amik egyik iranyba billentik a merleget, de ezekrol nem lenne szep dolog beszelnem. Max. privatban egy sör es pizza mellett )))
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Nézd meg a Corel, Sony, Cyberlink, Arcsoft új programokat és funkciókat. Számtalan példa van rá, hogy egy új verzió új funkciója csak az AMD OpenCL meghajtójával működik, vagy működik mással is, de kiemelik, hogy nem garantálják a hibátlan működést.
A legjobb OpenCL debugger a gDEBugger. Ez fontos eleme a fejlesztésnek. Az AMD ezt a programot pár éve megvette, és a 6-os verzió, ami egyébként igen sok extrát tartalmaz az önálló 5-öshöz képest csak az APP SDK-ban van benne.
Sok választás amúgy sincs. Az NV SDK-ja OpenCL oldalról már két éve nem fejlődött, sőt inkább csak butul, ami ellen a fejlesztők petíciót is indítottak. Az Intel esetében az OCL debugger nem elég kiforrott.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez csak a Fusion Fund program, ami nem csak a Corelt, hanem az Adobe, Cyberlink, Arcsoft, The Document Foundation, Telestream, BlueStacks, Aviary, Sony, Musemage, MAGIX, GIMP, VUDU, Moovida, Roxio, VideoLAN, stb. cuccokat is támogatja.
A partnerprogramban az AMD állja az erőforrások egy részét (legyen az ember vagy pénz), illetve a problémákra együttesen kidolgoznak egy megoldást. Ezért cserébe az AMD azt kéri, hogy használják ki az új technológiákat.
A koncepció az, hogy a fejlesztő úgyis rákényszerül az új lehetőségekre, mert verseny van, de a Fusion Fund keretében a teher egy részét az AMD vállalja át, és a fejlesztő kap ingyen hardvereket.
Az Intel/NV is szorosan együttműködik a fenti cégekkel, csak nincs hasonló partnerprogramjuk, így nem élveznek prioritást.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
félisten
A youtube videót készítő fickó update-elte a rendszerét egy Bequiet! 300W SFX táppal, és egyből tesztelte is:
Prime 95 4 Threads + Furmark
45W ---- CPU 39° ---- MB 34°Nem rossz eredmény, érdekesek a passzív hűtéses eredmények is!
"Csak egy dologtól félek. Ha meghalok, az asszony eladja a gépeimet annyiért, amennyit bevallottam neki." KERESEM: Lian Li PC-C50, Silverstone Milo ML03 ..............................................................................................
-
radi8tor
MODERÁTOR
-
félisten
Új hozzászólás Aktív témák
- Júniusban végre bemutatkozhat az új Gears of War játék
- Bundle topik
- A fociról könnyedén, egy baráti társaságban
- Formula-1
- Mibe tegyem a megtakarításaimat?
- Alkoholista nevelde
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Intel Dual Core 2000 felhasználók barátságos offolós topikja
- LG C3: egy középkategóriás OLED tévé tesztje
- Autós topik
- További aktív témák...