- Minden fejlesztőnek kipróbálható a Microsoft DirectSR API
- Feltűnt a dél-koreai hitelesítésen a PlayStation VR2 PC adaptere
- A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
- A manapság optimális specifikációkra törekszik az MSI QD-OLED monitorja
- Felpörög az asztali CPU-piac a következő pár hónapban
- Fejhallgató erősítő és DAC topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- ThinkPad (NEM IdeaPad)
- Xiaomi Pad 5 - hatásos érkezés
- A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
- Gaming notebook topik
- Felpörög az asztali CPU-piac a következő pár hónapban
- Nvidia GPU-k jövője - amit tudni vélünk
- Projektor topic
Hirdetés
-
Tényleg három színben érkezett a Nothing Phone (2a)
ma Csak mindhárom ugyanazon a hátlapon csoportosul, az új, limitált kiadású Phone (2a) megjelenése így még mozgalmasabb lett.
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Feltűnt a dél-koreai hitelesítésen a PlayStation VR2 PC adaptere
ph A Sony közel lehet a starthoz, így a VR headsetjük hamarosan PC-vel is használható lesz.
Új hozzászólás Aktív témák
-
O_L_I
őstag
Nagyon jó irányt vett az AMD. Látszik hogy szoftveres/driver fronton is határozott irány van.
Mostmár csak a Bulldozernek kell hozni a várt teljesítményt és tényleg egy nagyon ütőképes komplett platform lesz az AMD kezében
-
Pikari
addikt
Erről haverom anyja jut eszembe. Kiment a piacra, és vett egy bazinagy bombont. Akkora volt a csomag mint két laptop. Hogy örült. Csak 300 ft! Szinte ingyen van! Hazament, kibontotta, és volt benne 5 db bombon. Négy a sarkakban, egy db középen.
Használhatatlan semmi, díszes csomagolásban.
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
-
Pikari
addikt
Attól tartok, hogy inkább nektek nincs róla fogalmatok. Kettőtök közül melyikőtök írt már videótömörítést OpenCL-ben?
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
djculture
félisten
Ha az intel meg az nv nem foglalkozik vele akkor ez is csak egy próbálkozás lesz,nem fog elterjedni komolyabban.
-
Ł-IceRocK-Ł
addikt
Az amd tényleg nem ül a sejhaján, toják az ipart, ami nagyon hejes. Várom az új katalistot, hogy valójában kiderüljön mi merre hány méter.
Pikari: ha így folytatod te sem leszel hosszú életű itt. személyes véleményem szerint.
[ Szerkesztve ]
"lol, rock, te egy kib*szott médium vagy. mit médium, HARD " by FireKeeper
-
O_L_I
őstag
Pikari: Megfogtál valóban nem programoztam OpenCL-ben.
Ami számomra lejött mint újdonság és extra haszon az az utófeldolgozás hardveres gyorsítása Mert jelen pillanatban hiába van hardveres dekódolás a filmen ha bármilyen post process effektet bekapcsolok akár Splash PRO-ban akár PDVD-ben azok azonnal a procit fingatják ráadásul egy HD anyagnál nem is kicsit.
[ Szerkesztve ]
-
Pikari
addikt
O_L_I: én a szoftveres megoldások híve vagyok. Persze kipróbáltam az OpenCL-t is, szeretek haladni a korral. És a cikkben szereplő dolog annyit ér, mint akna által levitt lábra a papírzsebkendő. A DMA meg mindkét esetben ugyanúgy fogja fingatni az eljárást. This should do the trick.
Ł-IceRocK-Ł:
Végülis igazad van. Azt hiszem, többet ilyen témában nem szólok hozzá. Most no offense, nem beszólás, de felesleges olyanoknak osztanom az észt, akik szó nélkül bekajálnak bármilyen magyarra fordított marketingbullshitet ami mellett ott figyel mondjuk egy AMD logó. Mivel ezekkel az arhitektúrákkal kapcsolatban nagy pénzek forognak, amiben én személyesen is érdekelt vagyok, jobb ha megtartom magamnak a titkokat.
[ Szerkesztve ]
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
TTomax
nagyúr
válasz Ł-IceRocK-Ł #15 üzenetére
Pedig nem irt ám hülyeséget...
★★★★★ I got too much soul, rhythm and blues R&B ya see, all that's cool, but hip-hop and rap yeah that's where my heart's at Even back when I used to break on a box ★★★★★ "Chief Rocka"
-
Abu85
HÁZIGAZDA
Ez a OpenVideo Decode API olyan, mint a DXVA (Windows), vagy a VDPAU (Linux).
Az AMD megoldásának annyi az előnye, hogy az OpenCL-re könnyen megoszthatók a pufferek. A DXVA esetében ez a rész borzalmasan nehézkes, és alapvetően korlátozott is.
Lényegében aki GPGPU-s szűrőket akar futtatni a lejátszójában, annak jelenleg az OpenVideo Decode API a legkényelmesebb megoldás. Emellett még nincs konkretizálva, de az AMD már mondta, hogy tárgyalnak az OVD Khronos specifikációba való felvételéről. Innen eredhet az első verzió úgymond korlátozása is, hogy a lehető legtöbb hardver támogassa.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
devast
addikt
Én spec pikari-nak adok igazat.
Mutassatok nekem, 1 akármilyen video decodert/encodert ami opencl-t használ. Másrészt a postprocessing-et eddig is d3d/opengl -ben végezte minden jobb dekóder.
ps: linux alatt is nemrég nyitotta meg az ati a dxva interfészét. Mondanom sem kell, az is mint halottnak a csók. -
O_L_I
őstag
Na tisztázzunk valamit mert új vagy itt.
A Troll és a pesszimista szakértő között annyi a különbség hogy a szakértő megmagyarázza hogy miért szar a bizonyos dolog a troll meg csak leírja hogy szar és ezt az álláspontját bármiféle érvelés nélkül a végletekig védi.
A bonbonos hasonlatból nem jön ám le hogy te melyik kategóriába tartozol.
Tehát nem besértődni kell hanem akkor mond el hogy ez szerinted miért nem ér semmit. -
Meteorhead
aktív tag
Nem kifejezetten szeretem, amikor a fórumozó népek összefognak és szétszedik az egyetlen más állásponton lévőt, úgyhogy maradok a kultúr véleménynyilvánításnál.
Pikari, ugyan még nem írtam videotömörítést OpenCL-ben, de a legeslegelső OCL béta SDK óta nyúzom az APIt (szinte főállásban) és határozott véleményem, hogy ez nem bonbonos doboz. Ha megnézed 1.1.7-es VLC GPU gyorsított codecjét, akkor látni fogod, hogy egy vicc. (1.1.8-ra csináltak valamit, de még mindig nem az igazi)
Adat GPU-ra >> decode >> adat vissza CPU-ra >> post-process >> vissza GPU-ra >> display
Ugyan GPU accel, de szaggat mint atom, rosszabb mint a sima CPU-s ami tökéletesen működik a 8GB-ba tömörített HD-knál, csak a 25GB+ videok fekszik meg a gyomrát mezei masinákon.
Az értelme ennek az egésznek, hogy egy egységes felület adódik az ilyen problémák nagyon szép és frappáns kiküszöbölésére. Az ember streameli adatot GPU-ra, UVD egyszerű preprocess formában dekódolja az adatot, OCL kernel postprocess javításokat használ rajta és küldi OGL-nek megjeleníteni. Nagyon szép moduláriás és robusztus rendszer.
Hogy mire jó a frappáns elrendezés? Ezzel lehet igazi varázslatot csinálni. Gondolom mindenki látott már 100+Hz TV-n frame beillesztő eljárást, és hogy mennyivel simább lesz tőle a videó. Az ilyen szép strukturált programokkal lehet ilyet csinálni gépen is tv nélkül. UVD dekódol képet küldi OCL-nek, OCL vár még egy frame-re, amikor másodikat kapja interpolál egy kockát a kettő közé (ami számításigényes buli ha szépen akarod megcsinálni), postprocess az első és az interpolált képre és mehet OGL-nek megjelenítésre, már nem 29.7 hanem 59.7 fps streamként.
Ettől a felhasználó már hanyatt esne. Hadd ne folytassam, hogy az encode és transcode variációkkal miket lehet még csinálni, de hidd el hogy az ilyen dolgokért nagyon sokan ölni tudnának (köztük én is). És szeretném kihangsúlyozni, hogy AMD nem olyan mint buzi Intel vagy NV, hogy ahol tudják kiszorítják a konkurenseket, hanem nyílt szabványba invitálja a népeket.
Remélem sikerült megvilágítani Pikari és a kétkedők számára hogy miért jó ez.
-
Abu85
HÁZIGAZDA
Ezen nem kell csodálkozni. DXVA-hoz az NV és az AMD a CL to D3D10 interop kiterjesztést használhatja. De azon belül is eléggé szenvedés a program megírása. Addig nehéz programot kérni, amíg egy értékelhető felület nem kerül le az asztalra.
A D3D és az OpenGL nem a legjobb felület post processingre. Az OpenCL és a DirectCompute képességei messze meghaladják a korlátozott shader modellek képességeit.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Pikari
addikt
,,messze meghaladják a korlátozott shader modellek képességeit''
...amit aztán persze ezekkel a korlátozott shader modellekkel kénytelenek leemulálniA Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
Abu85
HÁZIGAZDA
Nem éppen. Például a DirectCompute alatt eleve a shader modell 5 az ami értékelhető teljesítményt tesz lehetővé. A DXVA viszont nem támogatja a DirectCompute felületet. A legjobb shader modellből ezzel helyből kizártad magad. Persze a DXVA-t tovább lehet fejleszteni, hiszen az MS bármikor megteheti, csak addig amíg ez nem történik meg lenyeled a korlátokat, vagy váltasz egy másik API-ra, ami rugalmasabb. Pl.: a hírben szereplő.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
O_L_I
őstag
válasz Meteorhead #21 üzenetére
Pont erre a frame beillesző eljárásra gondoltam mikor a megfingatásról beszéltem
Ez a Spalsh PRO-ban tök jól működik de eszi is a procit rendesen. -
Abu85
HÁZIGAZDA
Ez is univerzális, ráadásul nyílt. Pont azért lett meghúzva a képesség ilyen alacsony szinten, hogy a lehető legtöbb hardver támogassa, és a Khronos mielőbb fel tudja venni szabványba.
Ha meg nem támogatják a konkurensek, akkor az Intel és az NV magával szúr ki, mert ezzel az API-val teljesen hardveres futószalag építhető, mindenféle CPU-s bottleneck nélkül. Nyilván program is készül rá a Fusion Fund keretein belül. Az NV és az Intel vagy kínál hozzá drivert, vagy nézi, ahogy az AMD rendszerei több funkciót és jobb feldolgozást kínálnak az adott programok alatt. Igazából az AMD-nek rövidtávon mindkét opció jó. Hosszútávon a legjobb, ha felvetetik az OVD-t szabványba a Khronosszal.Sejtettük, hogy Linuxra nem a DXVA lett megnyitva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Pikari
addikt
Szerintem szemléljük inkább egyben.
Van egy számítógép, amin valaki szeretne nézni egy nagy felbontású videót.
Oké. Stimmel. Beleraksz egy DVD-t, és megnézed. Vagy ott a film a vinyón. Vagy internetről nézed. A téma szempontjából végülis teljesen lényegtelen: a kicsomagolatlan videó először is a rendszermemóriába kerül. Innen, ha azt akarjuk, hogy kép legyen, mindenképpen át kell adni a videókártyának valahogy. Ez mindenképpen meg fog történni legalább egyszer, hiszen más különben nem lenne kép.
A probléma szerintem nem ezeknek a technológiáknak, inkább az egész GPU alapú filmgyorsításnak a létjogosultságát kérdőjelezi meg. Tényleg szűkség van rá, és tényleg működik a gyakorlatban? Ha a videókártyán akarod dekódolni a filmet shaderekkel, akkor először is a nyers, dekódolatlan adatot oda kell adnod. Egy dekódolandó frame függhet az előző frametől, tele van furcsa tömörítési eljárásokkal, amik gyakran még csak nem is párhuzamosíthatók normálisan, tehát shaderekkel ezek dekódolását NEM LEHET normálisan leemulálni. Kivételt képeznek ez alól azok a dekóderek és videótömörítési eljárások, amiket direkt ennek a figyelembe vételével fejlesztettek ki. Ilyen csak papíron létezik. A többit úgy lehet GPU-n dekódolni, hogy hardveres dekódert építenek be tranyó szinten. Ami persze gyorsabb, mintha gpgpuval próbálnák meg kiszmolni a frameket. A probléma ezzel az, hogy minden egyes videótömörítésre külön meg kell ezt csinálni. 2 hét múlva kijött egy új verzió? Hát szar ügy, mehet vissza a 100ezres videókártya a dobozba, meg a tervezőasztalra, hogy kicseréljenek benne 100 tranyót. Tényleg szűkséges ezeket a GPU-ba integrálni? Vagy a CPU-ba? Nem az. Egy asztali dvd lejátszó esetében még van értelme, hiszen az célhardver. Egy számítógép esetében ennek nincs létjogosultsága. Hisz ilyen technológiák léteznek már 10 éve. Azóta se használja őket senki. Meg ezután sem fogja. Persze az ipar nem először gondolkodik, aztán cselekszik. Az ipar az menő ficsőrök köré épül. Például ott vannak a shaderek. Hogy csillog tőle krájzisban a víz! De rohadt menő! Hát gyorsítsunk vele videódekódolást. Azt már most mondom, hogy nem fogsz. Ugyanis vagy tranyó szinten beteszik az adott videóformátum dekódolását, és akkor fogsz. Azt az egyet. Vagy egy grafikus kártyára épített streaming műveletekre kihegyezett egységre épített általános célú végrehajtó egységekre épített általános célú interfészemuláción keresztül leprogramozótt dekóderrel fogsz egy papíron x000 gigaflops teljesítményű valamivel dekódolni egy framet - a gyakorlatban, mint láthatjuk, max olyan sebességgel, mint egy Pentium2-n alulról, vagy olyan kinézettel mint egy 15 éves mpeg dekódoló kártyán. Az egészet kiheréli a lowend gpukon csüngű, GeForce3-mat alulról szagoló 32 és 64 bites 286 szintű bonyolultsággal megtervezett memóriavezérlő, hogy még véletlenül se tudd normális sebességgel kicsomagolni a nagy felbontású videót. Elvégre egy 8 gigabájt/sec-es memóriatransferrel rendelkező integrált kacaton ne akarjon senki egy 4x4096x2048x3as (24 bites) planet valós időben updatelni úgy, hogy közben az egészen még egy dekódert is futtat. Találtak már fel ilyen általános célú kütyüt, aminek az a dolga hogy bármilyen cuccot meg lehessen írni rá. Úgy hívják hogy CPU. Van is belőle vagy 4. Persze a memóriasávszélessége ennek is takony. És azért nem lehet a feladatot tőle hatákonyan átvenni ilyen más cuccra felhegesztett általános célú hardverekkel, mert a vinyó, a hálókártya, a cdmeghajtó, az végső soron a CPU-ra, illetve hát na, a chipsetre van rákötözve, hiába építünk a GPU-ba mindenféle hangzatos nevű technikát, max dísznek lesz jó. Minden erre épített további technológia már csak légvár. A megoldás az, ha a GPU-t a CPU-ba költöztetjük - és akkor a GPUból ledegradálódik egy textúracímzőre, egy speckó interruptra amivel a cpura fallbackel shaderek gyanánt, meg egy hardveres videódekóderre, amit lehet ideig-óráig használni, aztán meg senkit nem fog érdekelni mert lesz helyette 10 másik. Vannak is ilyenek, dvd játékosokban is ez van. Csak egy olyan chip 2 ezer ft és 5Wot fogyaszt. Egy olyan GPU ami ezt meg tudja csinálni, 100 ezer ft, és 100w-ot fogyaszt. Innentől kezdve nekem már csak egy kérdésem van: noooormális? Én az AMD helyében nem mertem volna odaírni az OpenCL-hez a nevem. De mostmár mindegy, így jártak. Viseljék el.
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
Abu85
HÁZIGAZDA
Érdemes megnézni a gyakorlati példákért a Brazos tesztet. [link] Ott a videólejátszás táblázata, ahol le van vezetve, hogy négy videó lejátszása milyen minőségű. A két legmegterhelőbb videó akad az Atomon, míg a Brazos mindkettőt zsírul viszi. Az Atom + Ion páros gyomrát egyedül a Killa sample fogja meg.
Na most a gyakorlat világosan mutatja, hogy GPU-s gyorsítás nélkül egy Atom mellett meg vagy lőve. Alapvetően a Brazos processzormagjai mellett is meg lennél, ha nem lenne mellette egy UVD 3.0-s motorral szerelt IGP. Ez önmagában megalapozza a GPU-s gyorsítás létjogosultságát. Az AMD csak annyit szeretne, ha ez az élmény egy korszerű API mellett még jobb lenne. A többiek ehhez csatlakozhatnak.Amúgy a shaderekkel nem videokódolást gyorsítasz, hanem post process szűrést. A dekódolásra ott az UVD motor.
A post process szűrést ellenőriztük a TMT5 szoftverrel, ahol OpenCL-ből alkalmaztunk HD felskálázást. Az OVD-vel ezt a fejlesztő a lejátszóba integrálhatja magába a futószalagba. Ez egyértelműen win számodra, mert javul a videó minősége. Ráadásul Open az egész, vagyis bárki támogathatja.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Pikari
addikt
Az Intel Atomon, a beléjük előszeretettel beépített GMA-kon, és a jövőben megjelenő hasonló kaliberű hardvereken hosszú távon ez az új SDK nem fog segíteni, de érzésem szerint rövid távon sem nagyon.
Szerintem az lenne mindenki számára egyértelmű win, ha a processzor memóriasávszélességét megötszöröznék, saját magába integrált GPU-t kapna mint ahogy elmondtam, meg 8 magot... Mindegyik kapna néhány gpuban megszokott utasítást egy új instruction set keretein belül, és akkor hirtelen azt vennénk észre hogy mindenféle kő alól, meg mocsaras helyekről előbújt furcsa nevű használhatatlan API nélkül is működne minden negyed akkora költségvetésből, normálisan
[ Szerkesztve ]
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
Abu85
HÁZIGAZDA
Ha a jövőben megjelenő Atom nem gyúr rá a multimédiára, akkor az óriási fail az Intelnek, mert a Brazos fényévekkel az aktuális platformjuk előtt jár. Nem azt mondom, hogy verjék meg az AMD-t itt, de illene egy minimális szintet hozni.
Jó. Azt úgy lehet kivitelezni, hogy négycsatornás memóriavezérlőt építesz a CPU-ba. Ez kb. 1500+ láb. Belevéve a routing bonyolultságát cirka hatszorosára nőne a belépőszintű, és háromszorosára a középkategóriás termékek előállítási költsége.
Amit mondasz az mind kivitelezhető, ha a termékek fogyasztói árát megtöbbszörözik. Ja és el lehet felejteni a mobil forradalmat is.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Pikari
addikt
Nem kell egy láb sem. Szerintem nem kell külön chipset. Nem kell külön GPU. Nem kell külön speckó memóriavezérlő sem. Néhány külső perifériákkal való kapcsolattartást meg egy külső HUB-ba át lehetne szervezni (pl sata, ide, usb). Szóval nem kell elbonyolítani úgy ahogy a mostani tradícionális x86 ki van alakítva, a lényeg úgyis a bináris kompatibilitás, formailag, arhitektúrálisan nem kell kompatibilisnek maradni. Szépen, egyszerűen egy tömb, és akkor kaptunk egy GPU-hoz hasonló valamit, csak épp x86 támogatással. És akkor amit elvesztessz adón, megspóroltad a vámon. Van már hasonló elgondolás alapján született hardver, ami persze nem pont ilyen, mert ennyire nem merészkedtek messzire, de pl érdemes nézelődni a DPM/Vortex86 irányába, meg látható hogy a GPU-t az AMD és az Intel is elkezdte egybepakolni. De ez ami most van náluk, az nem az, amit elmondtam, mert kvázi külön van a gpu a cputól, ha a cpu alrendszere lenne a gpu, akkor lehetne elindulni ezen az úton.
[ Szerkesztve ]
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
Pikari
addikt
Lerajzoltam vázlatba. Természetesen itt amelyik proci nem kell azt le lehet kapcsolni és kész.A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
Pikari
addikt
Igen, de az több ponton is gázos, és sajnos nagyon lényeges pontokban. Egyrészt ha PCI-E-re ülteted, akkor ugyanazok a problémák lesznek rá érvényesek mint amit az előbb már elmondtam. Ha alaplapra ülteted (amit az egyik módosított változatával TALÁN meg lehet csinálni állítólag) akkor viszont csak 4 magot látsz, speciális SDK kell ahhoz hogy a többivel is tudj kezdeni valamit, tehát az egész arhitektúra a rendszer szempontjából nem monolitikus, így nem csoda hogy bukás lett a dologból.
[ Szerkesztve ]
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
eziskamu
addikt
Esetleg elő kéne venni a Transmeta Crueso-t, csinálni belőle egy százmagosat spéci memvezérlővel, és alapból x86-os morph progit feltölteni, de esetleg szoftveresen lehessen változtatni "magonlént", hogy adott mag x86-os vagy valami más üzemmódban működjön? Vagy ez is hülye ötlet?
[ Szerkesztve ]
-
Pikari
addikt
Azt már felvásárolták, és áttervezték cpu-gpu hibriddé Izraelben. Aztán csődbementek, és nem kell a maradványuk senkinek. Mondjuk az nVidia szerintem hasznát venné.
De a DPM megoldása sokkal jobb, és licenszelhető.
[ Szerkesztve ]
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
Abu85
HÁZIGAZDA
Ha gyorsabb memóriát akarsz, akkor azt jelenleg a csatornák növelésével érheted el. Ezt meg kell fizetni a lábak számában. Nyilván a több lábat pedig mi fizetjük majd a kasszánál.
Mindenki elkezdte a GPU-t és a CPU-t egybepakolni. Lassan minden versenyző vállalat realizálja, hogy a heterogén éra elkerülhetetlen, ugyanis a CPU-magok számát nem tudod növelni a végtelenségig. Meg lesz az a határ, ami az egymagos rendszerek karrierjének véget vetett. Nagyon közel járunk a kritikus fogyasztási határ, vagyis olyan útra kell lépni, amivel a vég elnapolható. Ezért pakolják a cégek a CPU-t és a GPU-t össze. A késleltetésre érzékeny szálak a CPU-n lesznek futtatva, míg a párhuzamos végrehajtás esetében ki lehet használni a GPU masszív számítási teljesítményét.
Nyilván a következő lépcsőfok a még szorosabb integráció, de egyelőre erre nincs lehetőség. Majd 2013 környékén. Akkor lehet gondolkodni a memória-sávszélesség problémáján is.
A jelenlegi technikák mellett egy Cellhez hasonló megoldást tudsz kihozni. Ez persze nem olyan rossz, de vannak gyengéi, ami a PC-n alkalmatlanná tenné a rendszert.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Pikari
addikt
én így születtem
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
eziskamu
addikt
válasz errorcode06 #41 üzenetére
Szerintem csak simán időben jutottak nethez és nem (csak ) lenge lányokat nézegettek.
[ Szerkesztve ]
-
eziskamu
addikt
válasz errorcode06 #44 üzenetére
Volt már, csak megszüntették
-
Meteorhead
aktív tag
Igazad van Pikari, ez nem egy rossz elrendezés, és az Intel Larrabee chipje (amiből volt alaplapra gyógyított variáns) az pontosan ezt csinálta. A koncepció (annak aki nem tudná) az volt, hogy sokkal egyszerűbb x86 magokat csinálni, de sokkal többet (16 azt hiszem). A magok pedig teljesen szabadon számolhattak x86 binárist vagy DX9 API-n keresztül grafikát. A probléma csak ott volt, amikor grafikát kellett számolni. Ugyanis xar volt. Kicsi, kevés, keskeny, sovány, vékony.
A probléma a bonyolultságában rejlik, és nem az elrendezésnek, hanem az x86-nak. Itt nem architektúrális bonyolultságról van szó, ez ARM-mal és semmi mással sem lehetne kivitelezhető ilyen formában, mégpedig a végrehajtóegység bonyolultsága miatt. Egy x86 mag ha meglát egy sinust, kiszámolja, ha meglát egy if()-et, talán át is tudja ugorni anélkül hogy kiértékelné a belsejét (kód előre olvasás). Egy shader ha sinust lát, egy szorzás 137-szeres műveletigényével ki is számolja (dupla pontosságról már nem is beszélek), ha if()-et lát... akkor megáll a világ.
Amire szerintem Pikari gondol az mostanság van készülőben, csak nem verik nagydobra. AMD-nek vannak népbutító marketing videói, mennyivel jobb Llano játékban mint Sandy Bridge ha közben excel számol háttérben és filmet nézel. (Fixed funkciós egységek fitogtatása) Mindez azért van, mert Sandy Bridge IGP-je osztozik a CPU cache-ével (amit az excel rendszeresen kipurgál, ezért megy xarul a játék). MERTHOGY Intel arra utazik, hogy olyan C compilert írjon, ami magától felismeri a vektorosítható műveleteket és azokat minden programozói kijelentés nélkül az IGP-n hajtsa végre. Ez már egy igazi összeolvadása a két egységnek.
Látható, hogy minden csak stratégia kérdése, nem biztos, hogy az erős integráció járható út (Larrabee), lehet hogy a picit herélt mód (Sandy Bridge) lesz a járható, vagy a jó API-kon keresztüli megoldások (Fusion). Én személy szerint az utolsó mellett tenném le a voksomat, de ez ízlés kérdése.
A fixed function videodekódoló egységek pedig igenis jó dolgok, bármit is mond bárki. Nem cserélődnek olyan gyorsan a közkedvelt codec-ek, hogy ne működne a dolog.
-
Abu85
HÁZIGAZDA
válasz Meteorhead #47 üzenetére
32 magos volt az a Larrabee, amit már elkészítettek, de elkaszáltak (ez volt elvileg a tervezés szerinti második generáció, és az első, amiből tényleges hardver lett). Van is kártya, csak nem adják ki. Andrew Richards volt, az aki a leírta a fejlesztéssel kapcsolatos érzéseit. [link] Ebből csináltam anno egy hírt. Sajnos az eredeti írást az Intel levetette, de a lényeget kiemeltem.
Már készül az új verzió, ami majd jövőre jelenik meg. Ebből is csak HPC-be lesz termék. Persze sok esélyt nem jósolok neki a Kepler ellen.Az amin az Intel dolgozik koncepció, az a Larrabee-vel lett volna alkalmazható. Amíg opció volt a projekt, addig ez volt a terv. [link] Azt nem tudom, hogy mostanra mi változott.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
leviske
veterán
válasz djculture #10 üzenetére
Ha jól rémlik, akkor azért az Intel mostanság elég sok mindenben hagyatkozott az AMD-re, ha OpenCL-ről volt szó. Ennek pedig a fő oka, hogy Ők nem foglalkoznak komolyabban a témával, az AMD meg legalább csinálja.
Az nVIDIA meg jelenleg nincs olyan helyzetben, hogy diktáljon a piacnak, szóval a driver támogatás szerintem a részükről is meglesz.
-
Meteorhead
aktív tag
NV nincs olyan helyzetben, hogy diktáljon?!?! Ez nagyon tetszik! Bár igazad lenne... NV még mindig a CUDA-val nyert előnyét lovagolja meg és szándékosan hanyagolja el OCL 1.1 driver kiadását. Olyannyira diktál, hogy a többség OCL 1.0-val foglalkozik, mert NV még csak azt támogatja. 6 hónapja nem képesek egy új drivert kiadni ami vinné. Gusztustalan és szánalmas. (Én ezért utálom NV-t, mert rengeteg ilyen húzásuk van) Persze mindenki védi a piaci pozícióját, de amikor valaki ennyire látványosan lehetetleníti el a gyártó-független szabvány terjedését, akkor azért felforr a vérem. Senkinek sem fájna, ha tényleg OCL-en keresztül mérlegre lehetne tenni a kártyákat. NV kártyák nagyon jók és a GPGPU szegmensben bármikor megállják a helyüket, bármilyen API-n keresztül is éri el őket az ember.
Én személy szerint AMD párti vagyok, de ez hosszú és kitartó (ön)lejáratókampányába került Intelnek és NV-nek is. AMD azért nyomatja OCL-t annyira, mert neki nincs más. Intel is azért kapaszkodik mert neki sincs más, de neki is van miért csinálni. OCL-en keresztül lehet majd Knights Corner kártyákat értelmesen programozni. Nekem nem fáj, hogy csak a HPC szegmensben fognak játszani, mert én HPC programokat írok. És léteznek olyan alkalmazások, ahol a shaderek túl fájdalmasak és lenne létjogosultsága Intelnek is.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest