- Melyik tápegységet vegyem?
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- RAID
- Milyen asztali médialejátszót?
- Milyen széket vegyek?
- Felpörög az asztali CPU-piac a következő pár hónapban
- Milyen TV-t vegyek?
- AMD GPU-k jövője - amit tudni vélünk
- Szünetmentes tápegységek (UPS)
Hirdetés
-
A manapság optimális specifikációkra törekszik az MSI QD-OLED monitorja
ph 27 hüvelyk, 1440p, 240 Hz, Type-C és AI funkciók jellemzik dióhéjban a kijelzőt.
-
Középpontba kerültek a hibrid autók, alig fogyaszt a BYD újdonsága
it 2,9 literes fogyasztást és több mint 2100 kilométeres hatótávot ígérnek a BYD új hibrid technológiájához, de a Toyota (és a Subaru, Mazda) is a hibrid motorokra koncentrál épp.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
Új hozzászólás Aktív témák
-
B4nd1t4
tag
Érdekes... Ezt a lépést nem vártam volna... Ha már lúd, legyen kövér alapon nyitottá tehették volna teljesen. Ennek sztem kb. ugyanannyi értelme van, mintha nem csináltak volna semmit. Max némi marketing, hogy azért tudják a fejlesztők, ők is itt vannak még...
Alamuszi Nyuszi nagyot ugrik... :)
-
Bcy+
tag
Kiáltás a pusztába ...
||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||
-
Angel1981
veterán
Kíváncsi vagyok, mi lesz a CUDA-val, az eddigiek alapján a távoli jövőképe nem túl rózsás...
-
smkb
őstag
"Éppen ezért a gyártók szemében a CUDA továbbra is mostohagyermek lesz, és a gyártóktól valóban független platformok továbbra is jobb alternatívát jelenthetnek."
Mely független platform van jelenleg jobban támogatva alkalmazásokkal, mint a cuda, pl hpc szegmensben? Mert, ha ugye eddig is mostoha gyerek volt, akkor nyilván tobzódnak az alkalmazásk a független apikra és többszörösük van, mint cudára...
-
kisbalázs
tag
majd akkor fog kihalni mikor kifogy a csúszópénz az "nvidia The Way It's Meant To Be Worked" alapból.
Egy példa, eredetileg a vray rt csak nvidia gpu-kon futott a cuda miatt de elég hamar rájöttek hogy ők elég kicsit ahhoz hogy letegyék a voksukat egy gyártó mellett, mert nagyon hamar megjelentek az ingyenes jó minőségű renderelők opencl re akiket nem igazán érdekelt a cuda
és már ez is elérhető openclre. És itt a cudába ölt pénz, fejlesztés, támogatás, cégeknek ajándék, hamar (1-2 év alatt) semmis lett. Ma már csak annyi hogy az ajánlott cimkét kapták meg.Johnny Mnemonic 2021:320gb-t töltött az agyába és majdnem meghalt, inkább pendrive a s?ggébe!
-
félisten
Tudtommal a vray rt azért lett először CUDA-s, mert amikor elkezdték fejleszteni, akkor a többi nem létezett, legfeljebb hallani lehetett róla, hogy majd jön.
Ugyanez a helyzet az Adobe-nél is, ahol még el is gondolkodtak az openCL-en, amikor az megjelent, de aztán rájöttek, hogy hiába írnák át egyből OpenCL-re, nem lenne semmivel sem jobb a helyzet, mert a konkurens OpenCL kompatibilis hardverek amúgy is lassúak, tehát ha nem érdemes hardvert váltani, akkor jó a CUDA is, pláne, hogy az nV karikon az OpenCL kód lassabban fut, mint CUDA kód, így csak rontottak volna a helyzeten.
Pár év múlva amúgy is szükséges lesz a GPGPU kód refaktorálása, ahogy szinte minden olyan kódnál, ami nagyon új terület a fejlesztők számára, így meglesz a lehetőség az openCL-re váltásra később is, ha a konkurens hardverek teljesítménye labdába fog rúgni.[ Szerkesztve ]
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
kisbalázs
tag
Ez így igaz hogy akkor még csak az volt, de gyorsan áthajóztak a nyíltforrásra ahhoz képest hogy az nvidia gáncsolja a nyílt dolgokat ahol csak tudja (phisx, cuda), erre akartam mutatni.
Johnny Mnemonic 2021:320gb-t töltött az agyába és majdnem meghalt, inkább pendrive a s?ggébe!
-
félisten
Igen, ez igaz, én meg ezt akartam alátámasztani azzal, hogy a vray esetén csak az openCL későbbi érkezése miatt kezdték CUDA-ban. Persze, nekik lehetőségük is volt OpenCL-re váltani, mert pl. az AMD karikon meglepően tűrhető eredményt produkál a Vray RT, ahogy hallottam. Tehát érdemes volt engedni az nV karikon tapasztalható teljesítményből a konkurencia támogatásáért.
Az Adobe GPGPU kódja ezzel szemben feltehetően halott lenne AMD karikon így az OpenCL támogatás csak rosszabb lenne, mert az nV karik lassabb működésével fizetnének az amúgy is lassú konkurens kártyák támogatásáért - ami nem éri meg.
[ Szerkesztve ]
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
nandon
tag
"A CUDA Toolkit nyílt fordítót támogató verziója egyelőre nem publikus, de az alábbi weboldalon kérvényezni lehet a hozzáférést." - Isten malmai lassan őrölnek..
RISC86 Power
-
Abu85
HÁZIGAZDA
Ha a top500-at nézzük, akkor a gépek nagyon csekély része tartalmaz GPU-t. Nagyon az elején vagyunk még az aratásnak. A HPC szegmensben az egész innováció akkor veszi, majd kezdetét, amikor megkezdődik az integráció. A CPU-magok számos dologra jók, és a GPU-magok is. Egymástól függetlenül, vagy távol azonban a lehetőségek korlátozottak. Együtt egy lapkán belül viszont igazán ultimate megoldások lesznek. Amire viszont figyelni kell az a piac igényei. Nagyon sokan nem akarnak elszakadni a magas szintű programozási nyelvektől. A CUDA-nak és az OpenCL-nek is lesz létjogosultsága, de nem egyszerű platformokról van szó. A C++ AMP, az OpenACC, és a natív C++ támogatás sokkal kedvezőbb lesz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
Kicsit elvakult/elfogult...
Régebb óta kint van a piacon, könnyebb cuda-ra fejleszteni és sokkal gyorsabban is fut pl egy raytracing-es renderelő, mint opencl-ben megírva. (akár hasonló kaliberű AMD kártyával összehasonlítva is)
Egyetlen hátránya, hogy only NV, de lehet a GK100 megjelenése után 1024 maggal ez már nem is számít annyiraA 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ó.
-
Abu85
HÁZIGAZDA
Ja nyilván. Én döntöttem arról is, hogy az Intel, az AMD, az IBM, az ARM, és a többiek nemet eddig mondtak a CUDA támogatására. Én vagyok akitől a CUDA sorsa függ, mert a sakkban tartom a gyártókat, és kényszerítem őket, hogy mellőzzék a CUDA-t. A CUDA mellé oda lehetett eddig is állni, csak senki sem tette. Az NV most nem nézi tétlenül, hogy a gyártófüggetlen megoldások elkaszálják (ahogy a történelemben ez mindig megtörtént a zárt rendszerekkel), így az OpenACC általánosan érdektelensége után az egyetlen út a CUDA LLVM fordító forrásának megnyitása. Ezzel időt adott magának az NV. Valószínű, hogy gyártói támogatást nem látunk, mert már az AMD és az Intel is a C++ natív támogatásában bízik. A fejlesztőknek ez egyszerűbb alternatíva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
Top 10 vagy 20-ból érdekes, hogy mennyiben van NV kártya.
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ó.
-
Abu85
HÁZIGAZDA
Ezt nevezik szelektív látásmódnak. Úgy alakítod a top500 adatait, hogy az jó legyen annak a szempontnak, amit ki akarsz hozni belőle. Felőlem ezt megteheted, de ebben az esetben sértő számomra, hogy pont te nevezel elvakultnak.
Én szeretnék ebből kimaradni, mert az egyértelműen nem tényszerű információcseréhez vezet, ha a vizsgált lista 95+%-át szándékosan kizárjuk a statisztikából.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
MaUser
addikt
Abból a szempontból viszont indokolható, hogy értelemszerűen a lista elején vannak az újabb gépek, nyilván egy öt éves gépben (2006-os gépek is bőven beférnek a top500-ba!) nem lesz GPU. Egyébként a top20-on kívül is bőven van nV GPU-s gép még a konkurencia szinte nem is képviselteti magát: Top500
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
Jack@l
veterán
Ezt pontosan annak nevezik, szerinted mért nem a középső 250-et szúrtam ki véletlen?
(elárulom a titkot: a kraft nagy részét ugyanis ők képviselik egy supercomputerben, az x86 max pitypangot szed a réten hozzájuk képest)[ 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ó.
-
wdtv
tag
a cudanak mar vege van , ez mar csak az utolso lehelete
-
Sanya
nagyúr
Ezek a gyártók a programozók lennének?
A bortól bolondokat gondol az ember, DE A PÁLINKÁTÓL MEG IS CSINÁLJA!!!
-
Abu85
HÁZIGAZDA
Ez olyan dolog, hogy ha megjön egy új Windows, akkor kizárod a régieket, és 100%-os a részesedés. Mondom fel lehet állítani ilyen direktívákat, hogy az eredmény kozmetikázott legyen, de ettől még nem lesz elterjedtebb a rendszer a teljes piacot tekintve.
Az AMD más utat választ a HPC-hez. Az új GPU-ról nem beszélhetek, mert volt már konf. ... de korábban már kiderült, hogy a C++-ban bíznak, mert sok rendszeren fontos, hogy ne kelljen újraírni a programot. Az NV ezért vetette be az OpenACC-t, mert a CUDA és persze az OpenCL nem mindenhol előny. Persze abban azért továbbra sem hiszek, hogy szimpla újrafordítással, illetve direktívákkal jó lesz a sebesség.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
kpal
veterán
NV
-
MaUser
addikt
A direktívával semmi gond nincs, az AMD jelenleg tényleg észrevehetetlen a top500-ban GPU szinten... Én kemény két gépet számoltam össze, de nézd át a listát te is. Kb. 10:1-hez az arány az nV javára.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
Abu85
HÁZIGAZDA
A gyártóknak már az nem tetszik a C++ AMP-nél, hogy az AMD írja az SDK-t a nem Windows rendszerekhez. Miért tetszene innentől a CUDA, amit minden rendszerre az NV fejleszt, saját igényei szerint. Ez vállalhatatlan. A C++ AMP még épphogy vállalható. Kétségeim vannak, hogy az AMD nem optimalizál haza a nem Windows rendszereken, de legalább a platform fejlesztését független cég delegálja, és a Win alatt az AMD egyenlő a többiekkel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
wdtv
tag
a windows 8 -ban alap az AMP, innentol kezdve a cudanak nagyon nincs szerepe, az opencl hasonloan az opengl-hez multiplatformos fejleszteskoor johet szoba
az nvida rajott hogy az o megoldasuk halalra van itelve, ez a lepes maximum a szinpatiat noveli iranyukban, bar ez az egesz alsagos lepes, a semmit sem ero vackot konnyu kozze tennihosszu tavon sajnos az nvidianak nem terem baber, az intel be fogja daralni, az armos win8 is egy butitott verzio lesz
[ Szerkesztve ]
-
Brutális eb
addikt
Csak várjuk ki a win8 sikerét.
Eléggé kétséges.
Mind asztali mind más platfomokon.Panni net lemondva már távol tőlem. Voda vicc! Nordtelekom korlátozza a p2p forgalmat,!Ice dsl trükközik a sávszélességgel.T-kábelnet?Próba hónap után jön a szekventálás vigyázz velük.Digi most még rendben.
-
Hiftu
senior tag
Ha linux-ra is az AMD fejleszti az SDK-t, akkor az tuti halott ügy. (Feltéve, hogy alapból számolnak a linux-szal, mint célplatform.)
(Normális) Display drivert is nehezen sikerül kiizadniuk magukból.Tessék mondani, lehet itt hazudni? - Kaszt: Decker, Faj: Troll, Működési Terület: Prohardver
-
Puma K
veterán
Valami megváltozott bennem az Nvidiával kapcsolatos világomban...
"Cuccok: csattogós lepke és tiki-taki" └[ʘヘʘ]┘
-
Abu85
HÁZIGAZDA
Az asztali Linuxokkal nem is érdemes törődni. A gyártók ezt üzleti szinten kezelik. Látják, hogy van egy rendszer, ami ingyé sem kell az emberek nagyon-nagyon-nagyon-nagy többségének. Az rendben van, hogy a driverekben az elmúlt hónapokban óriási volt a fejlődés, de még így sem fektetnek bele túlzott erőforrást. Egyszerűen nem jön vissza a pénz. Szimpatikus a Linux, de a mai világ az kőkemény üzlet. Ha valahol van pénz, akkor az kap támogatást, ha nincs benne pénz, akkor ott komoly befektetésre sem lehet számítani. A Linux tulajdonképpen egy gyártónál sem számít asztali szinten. Profi szinten már más a helyzet, oda komoly erőforrások mennek minden oldalról. A másik az Android, ami egy sokkal jobban fejlődő OS. Oda is jóval több erőforrást fektetnek a gyártók. Itt a jövő egyértelműen az egyéni Android verziók, mert minden cég ki szeretné használni azokat az extrákat, amiket a chipbe építenek. Itt elsősorban az AMD van ilyen helyzetben, hiszen a Brazos képességei két évvel előzik meg a konkurenciát (számolva azzal, hogy a Tegra 4 megjelenik 2012 végén), de a Google úgy építette fel az Androidot, hogy egyszerű legyen a userek szempontjából, vagyis saját API-kat használ, így amikor programot töltesz le, akkor csak a verziószámot kell nézni. Ez jelenleg megfelelő a gyártóknak, de az AMD más most többet akar, és ezért fejlesztik az x86 Androidot nem hivatalos forrásból, mert a hivatalos Android nem felel meg nekik. A jövőben egyre több cég dönt majd így. Az NV számára például ott a CUDA. A Google nem fogja hivatalosan implementálni, így alternatív utat kell keresni. Nyilván az Android a jelenlegi formájában pár gyártónak nem felel meg. A Google maximum az OpenCL beépítésével fog törődni, mert az kezd tömeges igény lenni a gyártók oldaláról, de a CUDA, a C++ AMP, a OpenVideo Decode, stb. egyelőre egyéni, vagy csak pár gyártó igénye. Mindenesetre ez egy olyan kérdés, amit valahogy meg kell oldani. A Windows 8 megjelenésével a gyártók kapnak az Android mellé egy alternatívát. Ráadásul olyat, ahol az egyéni igények könnyen beépíthetők. Nyilván a Google-nek kell valami megoldás arra, hogy az Androidon is ki lehessen elégíteni az egyéni igényeket.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
szabi80sz
tag
Jujj!!! Te jó ég, hogy itt mennyi hozánemértő osztja az észt! A C++ AMP és a Cuda teljesen más területre valók! Van amire a Cudát lehet használni, de a C++AMP-ot nem (fordítva ez nem igaz, legfeljebb annyi, hogy ahol az AMP használható, ott hatékonyabban lehet programozni, mint a Cudát vagy az OpenCl-t, pont ezért van létjogosultsága). Ugyanígy az OpenCl-nek sem ellenfele az AMP.
Ilyen szöveg, meg hogy "a Cuda halálra van ítélve"... No comment...
Más: az OpenCl-es cikk nem lenne rossz, csak átveszi a marketinget és a valóságról nem sok szó esik benne (csak olyan tervekről, mit az OpenCl-ben érdekelt hardvergyártók nagyon szeretnének elérni, de ez még jó ideig álom marad, mert jelenleg sajnos az OpenCl több területen nem igazán szóbajöhető alternatívája a Cudának). -
flugi
tag
na végre.
esetleg kijavíthatjuk a ptxas-t, mert valami borzasztó, néha miket csinál.
-
Abu85
HÁZIGAZDA
válasz szabi80sz #38 üzenetére
Az OpenCL fejlesztéséért nem felel az AMD, sem pedig az NV, vagy más gyártó. A Khronos Group a platform felügyeleti szerve. A gyártók beleszólást kapnak, de csak SDK-t és persze támogatást készítenek az aktuális verzióhoz. Az persze igaz, hogy a rendszer élharcosai közé az Apple, az AMD, az ARM, és most már az Intel tartozik, míg az NV inkább később támogatja az aktuális verziókat, hogy egyszerűbb legyen a CUDA élete. Ez az a probléma, ami a konkurens gyártók által nem támogatott rendszereknek nehézséget okoz. Az Intelnek lenne valamennyire hatalma a saját akaratát rákényszeríteni a piacra, de az NV kicsi ehhez. A PC-s piacon rendelkeznek jelenleg ~16-18%-os részesedéssel. Ez nem elég. Ezért áll át egyre több szoftverfejlesztő az OpenCL-re, mert egyszerűen nagyon kevés felhasználó tudja kihasználni a CUDA-t. Jóval egyszerűbb egy szoftvert eladni, ha a PC-s piacon eladott gépek 100%-a támogatja a felületet. A kontraszt láthatóan jelentős. A C++ AMP is jelentős változás lesz, bár technikai értelemben nem olyan, mint a CUDA, vagy az OpenCL, de a célja nyilván azonos.
Az NV-nek meg kellett nyitnia a CUDA fordító forrását, mert a CUDA elveszne a független felületek között. Így sincs túl sok esély rá, hogy a gyártók beállnak a támogatók sorába, hiszen a felügyelet az NV-nél maradt, de adnak még egy kis időt a CUDA-nak. Az valószínű, hogy a konzumer szinten a CUDA-nak vége. Nem látom reális esélyét annak, hogy egy cég 16-18%-os és folyamatosan csökkenő részesedéssel el tudna terjeszteni bármit is. De a professzionális és a HPC-piacon van még lehetőség a CUDA előtt, legalábbis azzal, hogy nyílt a fordító mindenképpen nyert egy kis időt az NV.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
szabi80sz
tag
Részben egyetértek. Amivel nem (illetve lehet, hogy inkább csak félreértettél) : pontosan az OpenCl "támogatással" van a probléma Amd környékén (nem a funkcionális támogatással, hanem az optimalizálás teljes hiányával -ezt felejtik ki a marketingből-, ami főleg az indulási időket jellemzi, ami bizonyos programoknál nem olyan fontos, mert elrejthető, de más programokban pedig nagyonis számítanak). Tehát bizonyos programokat Amd videókártyán futtatni felesleges, mert a cpu-n gyorsabban fut le a kód, pedig pont az Amd miatt használnak (jelenleg még) OpenCl-t, de ha egy Geforce-on van értelme lefuttatni, Amd-n nem, akkor már inkább Cudát használ az ember. (Persze ettől még egyre inkább igaz lesz az, hogy a konzumer szinten csökkenni fog a Cudás kódok száma, hála az Nvidia butaságának, hogy nem tette és nem teszi nyílttá a Cudát).
Egyébként a Cuda már régen eltűnt volna, ha annyira rossz lenne. Igaz, hogy ez volt az első megjelent kiterjesztés, amivel általános célú programokat lehetett készíteni GPU-ra (emiatt elég sok olyan kod készült, amik ma is futtathatók), ráadásul a rendszer tervezői nagyon jó munkát végeztek, amit az OpenCl-re már nem lehet elmondani. Elég csak arra gondolni, hogy szemléletmódjában az OpenGl-es vonalat követi (nyilván emiatt elvileg jobban integrálható az OpenGl-el), de az OpenGl-t nem általános programozásra tervezték és ezért hiába másoltak le sok mindent a Cudából: sokkal kényelmetlenebb a programozása, mint a Cudának (elsősorban ez okozza a programok Cudához képesti lassabb futását, az OpenCl-es implementációjuk alatt).
A CL_DEVICE_MAX_MEM_ALLOC_SIZE pedig az OpenCl egyik legdurvább korlátja, ami amellett, hogy kényelmetlen is, lassít és felesleges többletmemóriát kell felhasználni miatta.
Nyilván sok esetben ezek nem tántorítanak el embereket az OpenCl-re történő fejlesztés melletti döntéskor, de ha én játszani akarok: konzolt veszek és nem számítógépet, így ha komolyan gondolom a GPU-ra történő fejlesztést (jelenleg) hiába OpenCl programokat fejlesztek, akkor is Nvidia kártyát veszek.
Ezzel még nem értek egyet: "A C++ AMP ... bár technikai értelemben nem olyan, mint a CUDA, vagy az OpenCL, de a célja nyilván azonos." Amennyiben a cél alatt azt érted, hogy egy program a gpu-n is futhasson akkor ez igaz, de ez annyira absztrakt megközelítése a dolgoknak, mintha azt mondanám, hogy egy harci helikopter, bár technikai értelemben nem olyan, mint egy utasszállító repülőgép, de nyilván a célja azonos (repülnek és emberek is lehetnek bennük ). Azért le kell szögeznem, hogy a jövőbeni változásait a C++ AMP-nak nem ismerem, de akkor is igaz, hogyha olyan funkcionalitást akarnak, mint amilyen a Cudáé vagy az OpenClé, akkor annyira meg kellene változtatni, hogy pont a jelenlegi előnyeit veszítené el, emiatt nem hiszem hogy ezeket a változásokat elvégzik.[ Szerkesztve ]
-
-
Abu85
HÁZIGAZDA
válasz szabi80sz #41 üzenetére
Az AMD nem is a VGA-kra gondol az OpenCL-nél. Nekik a Fusion a lényeg. Nagyjából 50 programot készítettek már az APP SDK-val. És tegnap voltam konferencián, ahol szintén bejelentettek pár programot, melynek az OpenCL részét átírják az APP SDK-val és ezzel gyorsabb lesz Fusionön. A tendencia látszik. Korábban olyan programok, amelyek only CUDA besorolásúak voltak már APP SDK-val készülnek (ArcSoft progik többsége pl., de a Corel is egyre jobban áll át). Ebből a szempontból a fejlesztők számára nagyon is megfelel az AMD fejlesztőkörnyezete. Ha nem felelne meg nem használnák. Az OpenCL egyik legnagyobb problémája debug, már amin ugye lehet korrigálni. Ezért vette meg az AMD a gDEBuggert, hogy ezen javítsanak. Ez nagy szerepet játszik abban, hogy az APP SDK-t egyre egyszerűbb használni. Nem sokat beszélhetek a készülő programokról, de fájltömörítőt is írnak APP SDK-ban jelenleg. 2012-ben meg is jelenik. Valszeg a Trinity APU startjához időzítik.
A CUDA nem rossz. technikailag semmi baj nincs vele, csak az NV 16-18%-os részesedésével a konzumer piacon nem lehet alternatíva. Saját maga hasznát vágja el a fejlesztő, ha CUDA-ra ír egy konzumer vásárlóknak szánt programot.
Úgy értem. A GPU-k kihasználása a cél az általános számításoknál. Az MS megközelítése egy picit más. Valszeg sikeres lesz, mert pont ott előnyös a C++ AMP, ahol a CUDA és az OpenCL nem. Sokan szeretik a magas szintű megközelítést. Nem a leghatékonyabb, de könnyű benne dolgozni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
szabi80sz
tag
A hozzászólásod kapcsán nem ismételném magam. Nem írtam semmit -szerintem -, ami ennek a hozzászólásodnak ellentmondana.
A fusion-t nem tudtam tesztelni, de szerintem az indulási idők ott is okozhatnak "fennakadásokat", szóval az Amd-nek érdeke lenne minél hamarabb kijavítani ezeket, mert nem igaz, hogy az Nvidia fejlesztői 600* gyorsabb kódokat tudnak írni (vagyis úgy tűnik, hogy sajnos igaz, de most hogy tudnak a problémáról: talán javítanak is majd, remélem: minél hamarabb). -
szabi80sz
tag
Azért még ezt a korábbi mondatomat kiegészíteném a hozzászólásod kapcsán: "Nyilván sok esetben ezek nem tántorítanak el embereket az OpenCl-re történő fejlesztés melletti döntéskor.."
Főleg, ha még fizetnek is érte, akkor meg pláne nem okozhatnak ilyen gondot a fejlesztőknek. (Meg persze az is igaz, hogy a jövőre is gondolni kell és inkább egy univerzálisabb platformra érdemesebb fejleszteni, a hátrányok jelentkezésekor pedig inkább becsukjuk a szemünket és összeszorított foggal megpróbálunk nem tudomást venni róluk, de ezzel kapcsolatban is volt már szó, hogy az Nv nagyon elszúrta, a Cuda zártságát stb.) -
Abu85
HÁZIGAZDA
válasz szabi80sz #45 üzenetére
A zártság ellen mindig lehet tenni. Az AMD-nek van egy OpenVideo Decode API-ja. A fejlesztésnél úgy tervezték, hogy zárt lesz, de később ez megváltozott. Jelenleg készítettek egy olyan alaprendszert, aminek sok hardver megfelel, és kérvény van beadva, hogy a Khronos Group felvegye szabványba. Jövőre erről döntenek, de sok fejlesztő szeretné, így valószínűleg nem lesz akadály a szabványosítás. Utána lehet fejleszteni a rendszert új verziókkal.
Az NV még most is odaadhatja a CUDA-t a Khronos Groupnak. Ha egy független szervezet felel a fejlesztés koordinálásért, akkor a gyártók biztos nem lennének ellene.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
wdtv
tag
az arm platform megjelenesevel , mar nem csak amd es nvidia jatszik windowsos kornyezetben, es egyseges gpu tamogatast csak a windows biztosit az AMP vagy compute shader altal
a jelenlegi fejlesztorendszer ugy nez ki hogy meg opengl-es programot sem tudsz irni win8-ra nemhogy opencl-eset m a microsoft korulbastyazta magat a sajat technologiajaval
Új hozzászólás Aktív témák
- Egyre több európai használja a Telegramot, ezért megkereste az EU
- Építő/felújító topik
- Melyik tápegységet vegyem?
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- A Z Flip6 jókora, a Galaxy Ring parányi akkumulátort kap
- Itt van az eddig legjobban teljesítő kétfiókos NAS a TerraMastertől
- Formula-1
- Xbox Series X|S
- Kerékpárosok, bringások ide!
- Autós topik
- További aktív témák...
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Promenade Publishing House Kft.
Város: Budapest