- Amlogic S905, S912 processzoros készülékek
- Milyen billentyűzetet vegyek?
- Adatmentés - HDD - SSD - Flash
- Házimozi belépő szinten
- LG 34GS95QE-B: OLED paneles, ívelt gamer monitor
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- Milyen SSD-t vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- RAM topik
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
Hirdetés
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
-
A Video AI lehet a One UI 6.1.1 ütőkártyája
ma Vagy hogy fogja a mesterséges intelligencia manipulálni a mozgóképeket?
-
Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
gp Továbbra is szeptemberi premierrel számolnak a fejlesztők, reméljük több halasztásra már nem kell számítanunk.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
2012 H1-ben megjelennek a tényleg új mobil Radeonok is. Úgy tavasz vége és nyár eleje környékén.
Úgy kell venni mobil gépet, hogy PowerXpress 4.0 vagy Dual Graphics ready legyen a dGPU. Ennek egyszerű módja, hogy megnézed a dGPU UVD motorját. Ha 3.0-s, akkor PowerXpress 4.0 az átkapcsolás. Vagy ott a teljes AMD mobil platform, ahol gyárilag támogatott minden energiatakarékossági fícsőr (dual graphics a hardveres átkapcsolással). Intelnél nem kapsz meg mindent, mert ehhez csak szoftverest lehet írni muxless átkapcsolásra, ez a két grafikus driver átka. Az AMD továbbá most is használ olyan fejlesztéseket, amik tisztán GPU-s technológiák, de a driver nem kapcsolja be őket, ha Intel procit érzékel. Pl.: Steady Video. A jövőben lesz még ilyen.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az összehasonlítási alaptól függ. Ezt majd akkor tudjuk meg, amikor itt lesz a termék, mert ennek a mostani SoC-ok közelében nincsenek teljesítményben. A Samsung Exynos 5250 lesz az érdekes összehasonlítás. Teljesítményben elmarad, de funkcionalitásban hasonló. A Samsungnak egyébként 5 watt a TDP-je, de átlag fogyasztás nincs megadva, az pedig fontosabb lenne.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
kleinguru
#18
üzenetére
Nem tudom. Az AMD stratégiáját már nem a processzor képzi. A Vishera 2012H2-ben jön. Kb. ennyi ami mondtak. Ezt az AMD nem részletezte. Az integráció volt a téma. Azon kívül más nem. Az APU átveszi a gaming szerepet is a sokmagos procitól.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az kb. éves szintű: 2011 a Bulldozer, 2012 a Pilledriver és 2013 a Steamroller. Utóbbi kettő biztos. A Bulldozer meg megjelent
Az Excavator az egy nagyobb lépés lesz, ami lehet, hogy nem lesz meg 2014-ben.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Lesz desktop vonal, csak az is APU-val. Gondolj olyan váltásra, minta az egymagos->többmagos CPU-k. Manapság már nincs egymagos, illetve van, csak kit érdekel kategória. Jó ez nem annyira jó példa, de a heterogén éra is csak egy evolúció.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
kleinguru
#32
üzenetére
Intelnek van ugyanilyen koncepciója. H. Goto anno csinált rá szemléltetést. [link]
A koncepció szintjén mindenki ugyanezt csinálja, csak technikai eltérések vannak, de az elv azonos.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Melyik nagy volumenű hír maradt ki az NV-től? Az Echelon projektet és a jövőbeli elképzeléseket is csak mi írtuk meg a magyar oldalak közül. [link]
Azt meg ne várd el, hogy megírjak olyan dolgokat ami nem igaz. A Keplerről senki sem tud semmit. Én magam kérdeztem meg a Compalt. [link] - le is írtam mit mondtak, ezek többnyire készpénznek vehetők. Mondjuk speckókat is kérdeztem, de arra már nem válaszoltak. Amint kapok valahonnan adatot megírom.
Asztali terméket nem láttak még az általam megkérdezett VGA-gyártók. Persze lehet, hogy egy Foxconnos kontakttal itt többre mennék, mint egy PC Partneressel, de nincs a Foxconnál senki, akinek írhatnék. Majd ha nem csak olyan találgatások lesznek, amik teljesen elborult elképzelésre épülnek (integrált Ageia gyorsító pl.), akkor megírjuk.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az notikat főleg netre veszik a júzerek. A jó ebben az, hogy már a megterhelő webes tartalmakat is a GPU gyorsítja. Ha IGP terén erősebb a rendszer, akkor az egyenlő azzal, hogy alkalmasabb a webre.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem a teljesítménnyel van gond a HD Graphics 2000-nél, hanem a terméktámogatással. Nézd az Opera 12 alpha VEGA gyorsítását ... az összes Intel IGP feketelistán van az OpenGL-es kódra. Egyszerűen nem elég jó a terméktámogatás. A hardver állítólag jó, mert a DirectX-es kóddal már nem kell tiltani. Ez lesz a végleges Opera 12-ben valszeg.
A teljesítmény főleg Silverlight 5-re, WebGL-re, Flash 11-re és később a WebCL-re kell.
Silverlight 5-re az Intel nem kínál teljes támogatást, míg az AMD és az NV igen. Ez a felület persze már halva született, de ha már létezik, akkor illene megírni rá a teljes supportot. Nem hiszem el, hogy erre pont az Intelnek nincs kapacitása.
A WebGL az implementációfüggő. Az OpenGL-es támogatás mellett az Intel nagyon lassú, de pár böngésző ANGLE módot használ, ami DX-en keresztül megy, és ott már jó. Az AMD és az NV minden szempontból jó.
Flash 11-re az Intel nem kínál teljes támogatást, míg az AMD WHQL, az NV pedig béta driver szintjén már igen.
A WebCL lesz még egy para. Arra OpenCL driver kell. Az Intel azt csak az Ivy Bridge-től tudja támogatni, míg az AMD és az NV aktuális IGP/GPU-i már most megfelelnek erre, és működő driver is van.
A teljesítmény szempontjából pedig bármelyikben tudsz írni olyat, ami egy erős VGA-t is kifektet noha valószínű, hogy erre nem kerül sor a valós weboldalakon, esetleg webes játékokban.
Szintén vannak még a böngészős játékok között Unity-s és WebVisionös holmik. Az Intel egyiket sem támogatja, míg AMD-n és NV-n ez megoldott.
Aztán vannak még projektek, pl.: Mozilla Paladin, ami HTML5-öt és WebGL-t használ, és az erre épülő webes játékok fejlesztését szeretné megkönnyíteni.Az igaz, hogy a legtöbb embernek elég a HD Graphics 2000 által nyújtott teljesítmény, de a terméktámogatás láthatóan elég gyenge a webes felületek szempontjából. Ez itt minőségi kérdés elsősorban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mivel fejlesztés alatt álló termékekről van szó, így nem érdemes a teljesítményt értékelni. Az AMD azt ecsetelte, hogy az ultra alacsony fogyasztású kategóriában 50%-kal jobb lesz a Trinity IGP-je az Ivy-énél. Ez konkrétan úgy jött ki, hogy lemérték egy A6-os 17 wattos APU teljesítményét, majd a Core i5-2537M teljesítményéhez hozzáadtak +30%-ot, mivel az Intel azt mondta, hogy ennyit lép előre itt az Ivy. Így jött ki az 50%. Az látszik, hogy pusztán spekuláció az egész, ezért is nem tulajdonítottam neki jelentőséget. Eleve a termékek teljesítménye a megjelenésig még változhat. Mindenesetre neked leírtam, hogy az AMD hogyan számol, de szerintem nem érdemes ezt figyelembe venni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
julius666
#121
üzenetére
Nem mi jósoljuk ezt, hanem a gyártók. Mi csak leközöljük, amit a gyártók mondanak, bemutatnak, vagy tanulmányban publikálnak. Lesz majd egy olyan cikk, amit nem a gyártók adataira építünk fel, és arra keres választ, hogy miért megy mindenki erre. Ehhez már több mérnökkel konzultáltam (zömében ARM-osokkal, ők a legbeszédesebbek ebben a témában, meg tapasztalataim szerint úgy általában is), és a rövid válasz itt a fizika törvényei, de nyilván ezt ki kell fejteni. Az AMD itt a legkevésbé beszédes. Még az NV-től és az Inteltől is kaptam választ a fizikai kérdésekre. Persze ebből nincs gond. Általánosan akarom a dolgot vizsgálni nem pedig gyártóspecifikusan, így az AMD véleménye nem érdekes. Főleg úgy nem, hogy az ARM, az Intel és az NV is egységesen a fizika határait jelölik meg elsődleges gondnak, és ezt több tanulmány is hasonlóan látja. Zömében olyan levezetéseket kaptam, hogy növelheted a tranyót a gyártástechnológiai váltásoknál, mivel erre lehetőséget ad a kisebb csíkszélesség, de a tranyók bekapcsolásához szükséges áram már nem csökken olyan mértében, mint amennyi extra tranyót építhetsz be egységnyi területet figyelembe véve. Ez konkrétan az alapprobléma. Erre kell megoldás találni, ami egyszerűen az, hogy a tranyókat beépítheted, csak arra kell ügyelni, hogy ne legyen mind aktív. Fred Pollack szabálya szerint jó megoldás itt a processzormagok komplexitásának csökkentése, és ezzel az egységnyi területre beépíthető magok számának növelése. Ezt az NV a GTC Asia 2011-en is megemlítette, hogy járható út, csak kivégeznék az egyszálú teljesítményt, amire azért még van igény. Ezért a másik opció a heterogén elv, vagyis meg kell őrizni pár processzormagot viszonylag erősnek, a jól párhuzamosított számításokat pedig sokkal egyszerűbb magokra kell bízni, melyek jelentősen kevesebb energiát emésztenek fel. Ezzel a gyártók reagáltak a fizika határaira. Nem tolták azokat ki, csak megint adtak maguknak pár évet, hogy jöjjön valami gyökeresen új gyártási eljárás. Innentől kezdve a dolgot a programozó oldaláról kell egyszerűvé tenni. Ez most a feladat.
A HSA támogatója az AMD mellett az ARM. Konkrétumok is vannak, de ezek nem publikusak. Ezért lesz 2012 közepén az AFDS, ahol sok dolog publikus lesz. Addig csak az férhet hozzá, akik partnerei ennek az egésznek. Itt valószínű, hogy el kell intézni a formai dolgokat, mert nem biztos, hogy mindenkinek megfelel az a specifikáció, amit az AMD dolgozott ki. Mivel ez a felület már nyílt, és a fejlesztést is alapítvány végzi, így a tényleges specifikációkat úgy kell publikálni, hogy az végül minden érintetnek megfelelő legyen.
A Xenos kompatibilis tesszellátor hasznos volt PC-n, mert az Xbox 360-ra lehetett vele dolgozni. Minden olyan multiplatform cím, ami Xbox 360-ra is elkészült, és ott tesszellációt használt az PC-re AMD hardveren lett fejlesztve. Zömében ezért készül a DX11-es játékok többsége az AMD Gaming Evolved partnerprogramja alatt. A HD 2000 óta minden GPU-ban van Xenos kompatibilis tesszellátor a DX11-es mellett. Az persze igaz, hogy a GCN architektúrába már úgy építették be, mint egy külön részegység, és nem mint a tényleges setup motor része. Ez a sebességre nem hat jól, mivel eléggé le van butítva a tranzisztorok spórolása miatt. A funkcionalitásban viszont ez nem számít, mert úgyis a fejlesztőknek készült.
Az egész tesszelláció problémás DX11 alatt, mert a legbénább NoSplit megoldást használják. Azóta már van jóval jobb DiagSplit. Persze a Microsoft mentségére legyen mondva, hogy amikor a DX11 alapjait véglegesítették még csak a NoSplit és a BinSplit volt. Ezek közül tényleg a NoSplit az előnyösebb valós időben. Ettől függetlenül a problémák jelentősek, mert sok feladatott ró a tesszellálás a művészekre, és a hardverre is, de utóbbi a kisebb gond. Amíg a DiagSplit le nem váltja a régi motort, addig a virtuális textúrázás erősítése és a Disney PTEX formátuma lehet a megoldás a művészek munkájának megkönnyítésére. A DiagSplit előnyei ezzel minimálisra csökkennek, de azért marad még jó tulajdonsága, mert a quad-fragment merging hatékonysága ehhez a modellhez a legjobb, noha alkalmazható NoSplithez is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A terméktámogatás zömében csupán szoftveres probléma. A megoldás az, hogy le kell ültetni a rendszerprogramozókat, hogy írjanak normális támogatást a driverbe. Azt ne kérdezd, hogy ez miért nem történik meg.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Truform az egy másik történet. Tesszellálás az is, de nem programozható. Óriási a különbség. Az egy szimpla fix-funkciós egység volt, ami egy belső hardveres rutinnal felbontotta a háromszögeket. A programozhatóság hiányának hátránya ott jött, hogy mindent felbontott. Esetenként a kocka eredetileg sík oldalai domborúak lettek. Ettől függetlenül 17 játékra készült normális implementáció, de a hardver csak a Radeon 8500/9100-ba került bele. A DX9+-os Radeonokban egy Truform 2.0 került, ami funkcionalitásban ugyanolyan, mint ez első megoldás, csak szimplán egy emuláció formájában, amit az R2VB-vel oldott meg az ATI. A fix-funkciós egység eltűnt. A konzoloknál használták még fel a Nintendo Wii-hez.
A tesszelláció sok fejlesztésen átment az idő folyamán. Az első megoldás valójában nem a TruForm volt, hanem a GeForce 3-ba rakott alapszintű HOS support. A baj ezzel az volt, hogy borzalmasan lassú volt, így senki sem támogatta. A TruForm a második volt ebben, csak azért maradt ez a köztudatban, mert konkrétan fix-funkciós egységen keresztül működött, így a sebesség is jó volt. Ezzel mint említettem 17 játék hivatalos implementációval támogatta is. A TruForm 2.0 csak egy spórolós lépcső volt. Mivel a dolog annyira azért nem volt jó, hogy korrekten támogatni lehessen.
Ezután jött az első hivatalos megoldás tesszellálásra, ami a Vertex Texture Fetch volt. Na most ezzel az volt a probléma, hogy az MS elkövetett egy bakit a specifikációk megfogalmazásakor. Egyszerűen semmilyen formátumot nem írtak elő kötelezően a vertex textúrázás támogatására, vagyis jó volt a VTF és az R2VB is technikailag, noha nyilvánvaló volt, hogy a VTF-et gondolták szabványosra az MS-nél. Ez ugye egy zavaros helyzet, mert van két eltérő megoldás ugyanarra. Itt az ATI nyilvánvalóan meg akarta a textúra mintavételezők helyét spórolni a vertex shader elől, és ez hátráltatta a vertex textúrázás terjedését. A DX10 alatt ez már tisztázódott, így az MS hivatalosan is a VTF-et írta elő a vertex textúrázásra, illetve a geometry shader végre lehetővé tette a programozható tesszellálást hivatalosan. Itt meg az a probléma került elő, hogy az NVIDIA hardvere a Fermi megjelenéséig gány volt geometry shader alatt, ami hátráltatta a geometry shader terjedését.
Itt állt elő az AMD először egy programozható tesszellátorral, ami a Xenos kompatibilis motor volt. Ezzel az AMD elérte, hogy az Xbox 360-ra a fejlesztéseket Radeonon végezzék.
Ezután jött a DX11 és a mai helyzet. Most a DX11-es NoSplit tesszellátor problémáira kell megoldásokat találni. Opció jelenleg a virtuális textúrázás bevezetése a PTEX textúraformátummal.
Hosszútávú lehetőség szerintem a DiagSplit, amihez persze új API kell.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#134
Abu85
HÁZIGAZDA
hugo chávez
#133
Abu85
HÁZIGAZDA
válasz
hugo chávez
#133
üzenetére
Persze, hogy kell. Egy fix-funkciós egység kell a tesszellátor elé, hogy az megmondja mit, mennyire és hogyan kell tesszellálni. Ez adja meg az UV mapok valós idejű módosításához is az adatokat.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Angel1981
#160
üzenetére
Az Intel nem túlozza el a dark silicon jelenségét. Anno amikor a Pentium 4-et fejlesztették teljesen leszarták, hogy létezik ez a probléma. Egy darabig vitték a terveket, majd látták, hogy nem működik, és követték az AMD-t a többmagos irányba. Ezzel párhuzamosan törölték is a Tejast. Ugyanaz volt a probléma, mint most is, csak most a többmagos chipek skálázásával van gond. Ezzel az Intel nem mond magának ellent, csak nem akarnak megint félrefejleszteni. Nekik sem volt könnyű a Pentium 4-es vonalat eldobni, de el kellett, mert a mérnökök képtelenek voltak a fizika törvényeit legyőzni.
Lehet jönni a gyártástechnológiai váltásoknál az előnyökkel. Rendszerint az az előny, hogy egyre több tranyó fér be ugyanakkora helyre. Aztán ott van az, hogy a tranyók bekapcsolásához szükséges energia nem csökkent olyan mértékben, mint ahány tranyóval több építhető be egységnyi területre. Ezt szokás elhallgatni, de minden gond alapja. Ha ez nem lenne, akkor most 10-20 GHz-es egymagos processzorok dolgoznának a gépekben zömében a Netbrust architektúrára építve.
A bejelentésekkel az a baj, hogy marketinges csinálja. Ez addig nem gond, amíg a termékbejelentés egyszerű. A gyártástechnológia tipikusan nehéz terep. Máig nem értem, hogy a TriGate-ből hogyan lett a marketinganyagban 3D-s tranzisztor. Ez az utóbbi évek legnagyobb baromsága, hogy egy tranyó 3D-s. Értem, hogy a júzer nem érti a TriGate-et, de most komolyan egy olyan marketinganyagra építesz, ami 3D-s tranyót említ? Ki tudja még milyen fontos részletek kerültek törlésre "a júzer úgysem értené alapon".
De ha már marketing akkor gondolhatsz a Larrabee-re is, hogy ilyen-olyan ray-tracing valós időben. Hát ... termék nem lett, nemhogy ray-tracing. Az pedig kizárt dolog, hogy egy mérnök, vagy egy programozó valóban valós idejű ray-tracinget mondott a marketingeseknek.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A programozókat felesleges szidni.
Ők egyszerű megoldásokat keresnek. A kétmagos CPU-kra való átállás sem volt gyors. Azt mindenki tudta, hogy ez a következő lépcső, csak mondhatni nem akarták. De amikor egy magon a skálázódás megszűnt, akkor az egyetlen úttá vált, és ez versenyt gerjesztett a programozóknál is. Amelyik szoftver megfelelt az új igényeknek, fennmaradt, amelyik pedig nem. Hát lemorzsolódott.
Most is ugyanez van. Mindenki tudja, hogy a fizika korlátot szab a homogén többmagos processzorok skálázásának. Ezzel szükséges az új elv. Arra pedig át fog állni minden szoftverfejlesztő, mert a verseny megindul. Aki nem használja az új fejlődési lehetőséget lemorzsolódik, ahogy ez az egymagos éra végén történt. Erre a helyzetre még rátesz a fene nagy mobil irányvonal, vagyis minden sokkal gyorsabban történik mint korábban, mert a mobil igények még kisebb fogyasztást követelnek, és az emberek elvárják, hogy legyen teljesítményben is előrelépés. A gyártóknak egyszerűen nem adnak választási lehetőséget a vásárlók, a heterogén éra az egyetlen megoldás az igények kielégítésére.Az Intel ugyanúgy beáll a sorba. Hiba lenne önfejűen újra a fizika törvényeinek legyőzésére törni, mint a Pentium 4 idején. Egyszer már megtapasztalták, hogy ez lehetetlen. Még egyszer megpróbálni szerintem nem érdemes. Működésre kell bírni a Larrabee-t, és az az Intel fegyvere itt. Akkor lesz gáz, ha nem fog működni. Ha nagyon agresszív a stratégia, akkor már a Broadwellbe be kell rakni. Kockázatos, de a Skylake-ig várni még nagyobb kockázat, hiszen akkor az AMD és az NV közül az Intel lesz az integrációs versenyben a legutolsó, ez az SDK-k terjesztésénél katasztrófával ér fel. Az Intel a legkevésbé sem akarja, hogy az AMD vagy az NV SDK-jával készüljenek az új programok. Az AMD-t időben valszeg már nem lehet verni, mert a Kaveri 2013-ra van tervezve, de a 2014-re készülő NV Maxwell még elkapható.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A felhasználás módjától, a programoktól, a mobil iránytól és a dedikált GPU meglététől függ. Például a multimédiás programok fejlesztői eléggé érdeklődnek ez iránt, így manapság már egy APU a legjobb megoldás ide. Ez idén a gyártók fejlesztéseit látva nagyon kiterjed, ugyanis a Trinity és az Ivy Bridge is erősen a fejlesztők igényeit követi. Például az enkódolásra lesz egy több módban is elérhető dedikált enkódolómotor. Vagy például az otthoni videoszerkesztésnél ott van a vReveal, mely már OpenCL-re van optimalizálva, azon belül is nagy előny a sebességben, ha nem a lassú PCI Express buszon keresztül megy dGPU kezelése. Ebből a szempontból gyorsan hátrány lesz a sima processzor.
A jövőben a GPU-ra a tipikusan jól párhuzamosítható feladatok fognak átkerülni. Például a C++ AMP-re az MS biztos átírja a Kinect SDK-t, mivel a mobil termékekbe is bele akarja rakni, amit a procik nem bírnának el. Ezen a ponton is gyorsan előny lesz az APU.
A játékok még az opciós terület. Például a Shogun 2 IGP-n számolja az AI-t, ha AMD Brazost, vagy Llano APU-t használsz. Ez nem annyira általános megoldás, mert CTM-ben van írva, de erre lehet vinni a játékokat, hiszen működik.
További opció a WebCL, amit a mobil cégek erőltetni fognak, mivel GPU-t használja a weben az általános számításra. Ezzel energiát spórolnak meg az üzemidőben, és még gyorsabb is a feldolgozás.
Nagyjából ezeken a területeken lesz erős fejlődés.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A jelszótörésben régóta a GPU a király. De egy jól megválasztott jelszóval akkor sem tud mit kezdeni. A rövid jelszavakat természetesen gyorsan bezúzza.
Ennél a résznél a fájltömörítésben lehet előnyt kovácsolni. A Corel már készíti is a APU/GPU-val gyorsított WinZip 16.5-öt.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az otthoni videószerkesztés egyre jobban kezd terjedni. Ma már boldog-boldogtalan vehet olcsó kamerát, amivel szépen csinálja a családi fotókat. Ezek nem biztos, hogy profi szintűek lesznek, amire a vReveal program a jó, mivel ez gyorsan feljavítja a minőséget, és elveszi a zavaró rázkódást. Ez a OneClickFix opció például CPU-val jóval tovább tart, mint egy APU-val. Persze lehet mélyebben is szerkeszteni, ami még tovább tart. Az otthoni videószerkesztés, az egy nagyon menő üzletág ma. Nem véletlen, hogy ennyi alternatívát kínálnak már rá a fejlesztők. Egyszerűen mindenki fel akarja tölteni a youtube-ra az anyagát. Szintén nagyon terjedő dolog a képekben való információkeresés ... Pl.: arcfelismerés, mivel a közösségi szolgáltatások behálózzák a júzerek életét. Erre is vannak programok, amelyek OpenCL-lel a APU/GPU erejét kihasználva keresik a megadott arcot több ezer kép közül.
A Kinect egyelőre egy beköszönő technológia. Még nem beszélhetünk arról, hogy mennyire jön be az embereknek, mert a konzolos megoldás más, mint a PC-s. Ha viszont bejön, akkor szintén nem kérdés, hogy a GPU-n érdemes a képkockákat feldolgozni. Nem csak energiát spórolsz vele, de gyorsabban is dolgozható fel az adott tartalom. Sajna a kinectnek azért van egy elég komoly lagja, ami nem csupán az adatok feldolgozásából jön, de jórészt onnan is, amit a gyorsabb feldolgozás csökkenthet. Persze eltüntetni nem lehet, de manapság azért nagyon érezhető lagról van szó.
Növekvő terület még a telekonferencia, mely most kezd otthoni szinten is kialakulni. Szintén vannak rá programok OpenCL-es gyorsítással. Persze itt valszeg majd a Skype adja a reformokat, de az MS-nek ott a C++ AMP.
Ezek mind terjedő dolgok. Zömében azért is megy erre a piac, mert a fizikai korlátok mellett az igények is a GPU-val való kiszolgálás felé tolódnak el. Egyszerűen egyre gyorsabban akarnak a júzerek videót szerkeszteni, egyre gyorsabban akarnak arc alapján keresni a képek között. És persze mindezt egyre kisebb fogyasztással. A CPU nem skálázható olyan mértékben, hogy ezeket az igényeket lefedje.A hardcore játék, aminek a célcsoportja szűkül. Ez zömében a konzolok miatt alakult így. A PC-s játékpiacnak nincs vége. Ezt az AMD is mondta az előadásokon, de nem lehet elmenni amellett, hogy a social gaming válik meghatározóvá. Mondta Lisa Su, hogy a hardcore réteg egy nagyon fontos terület, és mindig lesz erre igény, de a hétköznapi játékosok nagyságrendekkel nagyobb piacot képeznek, ami üzletileg kihagyhatatlan lehetőség. Nyersebben fogalmazva a social gamingben van a pénz, míg a hardcore csak úgy van már. Néha hoz egy kis nyereséget, majd egy kis veszteséget, de a social gamingből, vagyis az APU-val/IGP-vel megcélzott területekről származó nyereség, ezt messze kompenzálja. Pénzből élő cégek hülyék lennének kötni magukat a régi trendekhez. Ha változik az igény, akkor változtatni kell a termékeken is. Most ez történik.
A social gamingnél valszeg a web lesz a meghatározó. Azon belül is a Flash 11, a WebGL/WebCL/HTML5, és a többi felület, mint a Unity vagy a WebVision. ezeket kell erősen támogatni. Mindegyik GPU-val gyorsítható.A hardcore gaming egyelőre nehéz ügy. Attól függ a jövője, hogy az új generációs konzolok hogyan alakulnak. A Wii U és a pletykált új Xbox felépítése egyáltalán nem kedvez annak a modellnek, ami most a PC-ben van: egy CPU rendszermemóriával, és egy dGPU saját memóriával, mindez egy magas késleltetésű nem éppen gyors busszal összekötve. Gondolom az AMD ezért dolgozik azon, hogy a dGPU az APU kiegészítése legyen, mint egy koprocesszor, dedikált gyorsítótárral. Most arról még nehéz bármit is mondani, hogy ez mennyire jön majd be. Az biztos, hogy változtatni kell, és az új konzolok felépítéséhez kell igazodni valamilyen szinten.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Youtube-os megoldás nem valami korrekt, illetve alig használják. Ha nem így szerkesztetted le a videót, akkor nem is lesz elérhető. Egyedül az AMD kínál ilyet valós időben (Steady Video), csak ez nem érhető el minden gépen, mivel AMD platformhoz van kötve, ami szvsz baj.
Mert a skálázást nem veszed számításba. Teljesítményre mindig szükség lesz, csak más igények mellett. Most már a fogyasztás is fontossá vált. A processzormagok skálázhatósága viszont így erősen korlátozott. Csak abból indulj ki, hogy egy magról váltottunk kettőre. Ez elméletben duplázta a throughput teljesítményt. Ezután kettőről álltunk négyre. Ezzel szintén majdnem dupláztunk noha, az órajelet vissza kellett venni a fogyasztás mérséklése véget. Innen az egész turbó dolog, mert kihasználható a TDP keret egy maggal. Most már szinte csak +két magot pakolunk be, ráadásul egyre kisebb sebességelőnyt biztosítva. A skálázhatóság még nem tűnt el, de el fog. Négy mag jelenleg az ideális paraméter, és a további skálázhatóságra jobb eredményt ad, ha az IGP-t használják a gyártók. Sebességben, fogyasztásban előnyösebb. Egyedül a programozási modelleken kell változtatni.
A user azért vesz PC-t, hogy többet tudjon, gyorsabb legyen, és kevesebbet fogyasszon. Ezeket az igényeket a heterogén többmagos lapkákkal lehet biztosítani. A gyártók csupán kiszolgálnak.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azt mindenképpen vedd számításba, hogy a nextgen konzoloknál alapvető fejlesztői elvárás, hogy egy memóriatárba dolgozzon minden, illetve az összeköttetés is sokkal gyorsabb legyen. Lehetőleg integrálva, hogy ns-os késleltetéssel lehessen a feladatokat dobálni a CPU és a GPU között. Itt jön a VGA problémája. A PCI Express 300-400 ns-mal dolgozik (függően a vezérlők távolságától) és elég gyenge adatátvitellel. Nulla esélyed van egynél több adatátadásra. Sőt még ez is sok, de ennyit muszáj csinálni.
Az AMD még akar VGA-kat, de ők sem úgy gondolnak már erre, mint egy általános termék, hanem mint az APU-k kiegészítő koprocesszorai. [link] - valahogy így. Ezzel lesz gyors kommunikáció a CPU és az IGP között, amit kiegészít a GPU, ami végtére is a rendszermemóriát használja.
Szerintem ez nem feltétlen előnyös. Abból a szempontból igen, hogy lesz egy csomó SIMD még, ami gyorsítótárként használja a VRAM-ot, és logikailag hozzákapcsolódik az IGP-hez, de ez csak platformmal működik. Valszeg egy-két évig fenn lehet tartani, de vége a full integráció ennek is. Ahogy bonyolódnak a feladatok úgy válik egyre nagyobb korláttá, hogy egy külső buszon kommunikál a CPU és a GPU.Várhatjuk az új konzolokat, hogy majd felpörög a VGA-piac, de a fejlesztői igények alapján pont ezek lesznek problémásak a PC-s CPU->VGA modellre. Annyi trükk kell majd itt, hogy a portok elkészítése hosszadalmas és drága lesz. Persze több opció is van ezenkívül. Az egyik, hogy lebutítják a játékokat PC-re. Ami szvsz senkinek sem az érdeke, de egyelőre sokan vakarják a fejüket még a cégeknél is.
Pont ezért komoly téma az API-k eldobása. Ezt a szoftveres korlátot legalább ki lehet ütni. Erre lehet opció egy virtuális ISA. Az a nagy probléma, hogy minél hardver közelibb réteget csinál valaki, annál kevesebb fejlesztő követi a céget. Én úgy gondolom, hogy a lehetőségre szükség van, de a fejlesztők többsége az egyszerűbb utat választja majd. Úgy kell a fejlesztést egyszerűvé tenni, hogy kiüsd a szoftveres korlátokat, és még ne is kelljen többféle architektúrára dolgozni. Ilyen alapon tényleg egy Java bytecode-hoz hasonló virtuális ISA a legjobb, csak kellően a hardverhez igazítva.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Elvileg lehetséges, de egy külső busz, akkor is büntetés a késleltetésben. Ez csak integrálással tűnik el. Szerintem az AMD is csak próbálkozik valamit alkotni, de nem hiszem, hogy túl nagy reményeket fűznek ehhez. Az NV-hez hasonlóan ők sem számolnak hosszútávon a VGA-kkal. Próbálják életben tartani az egészet, amíg lehet, de előbb-utóbb vége lesz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Ők egyszerű megoldásokat keresnek. A kétmagos CPU-kra való átállás sem volt gyors. Azt mindenki tudta, hogy ez a következő lépcső, csak mondhatni nem akarták. De amikor egy magon a skálázódás megszűnt, akkor az egyetlen úttá vált, és ez versenyt gerjesztett a programozóknál is. Amelyik szoftver megfelelt az új igényeknek, fennmaradt, amelyik pedig nem. Hát lemorzsolódott.
Új hozzászólás Aktív témák
ph A 2012-es Financial Analyst Day rendezvényen a jövőbeni fejlesztési tervek mellett a HSA is szóba került.
- Amlogic S905, S912 processzoros készülékek
- Milyen billentyűzetet vegyek?
- Adatmentés - HDD - SSD - Flash
- Milyen NAS-t vegyek?
- A Watch7-tel debütálhat a Samsung vércukormérője
- Kerékpárosok, bringások ide!
- Magga: PLEX: multimédia az egész lakásban
- Házimozi belépő szinten
- PlayStation 5
- LG 34GS95QE-B: OLED paneles, ívelt gamer monitor
- További aktív témák...
- Újszerű - INTEL Core i5-14600KF 14mag 20 szál 5.3GHz CPU - bolti garanciával
- Beszámítás! Intel Core i7 6700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel
- Intel Core i7-11700K processzor (használt)
- AMD Ryzen 3600 (pár napig használt, szinte új)