- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- antikomcsi: Való Világ: A piszkos 12 - VV12 - Való Világ 12
- Luck Dragon: Asszociációs játék. :)
- crok: Youtube Android alkalmazás alternatívák reklámszűréssel / videók letöltése
Hirdetés
-
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...
-
Képeken a Honor 200 Pro
ma Az egykori anyacég, a Huawei fotós csúcsszériájára hasonlít a hátlapi dizájn.
-
ROG Ally X néven jön az ASUS kézikonzoljának frissítése
ph A fejlesztést a Computexen leplezi majd le a cég, de nagyjából lehet tudni, hogy mit hoz.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Tisztán technikai tudásban már az Ivy Bridge is beérte őket. Az AMD-t azért támogatják jobban és hatékonyabban (vagy esetenként azért futnak) a GPU-val gyorsítható programok, mert két fejlesztési fázissal az Intel előtt járnak a fejlesztőkörnyezetek tekintetében, és a driver is jelentősen jobb. A hardver csak akkor ér valamit, ha raksz elé egy drivert. De az a tény vitathatatlan, hogy a hardver elméleti képességeit figyelembe véve az Ivy Bridge is beérte az AMD-t.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Bár az Intel sosem beszélt róla, de a gyártóktól tudom, hogy a Larrabee-t az Intel eredetileg a Haswellbe szánta. De mivel a Knights Ferry nem működött, így erről letettek. Ez ugye logikus, mert egy nem működő architektúrával nincs kisegítve az Intel. Ezért is Gen7.5 az IGP, mert a Larrabee elkaszálása miatt továbbfejlesztéssel kell operálni a reformok helyett. Ebből viszont látszik, hogy az Intel is tartotta volna a lépést a Kaveri APU rendszerszintű integrációjával, legalábbis a tervekben így volt, és a Larrabee-vel még jobb is lett volna az integráció. Most ez a terv 2015-re csúszott a Skylake APU-ra. Abban igaza van az Intelnek, hogy a fővonalbeli termék nem ideális kísérletezésre, mert azzal kivégezhetik az eladást. Túl nagy a kockázata, hogy rossz lesz.
A Kaverinek a közös címtérből és a teljesen koherens megosztott memóriából igazi előnye a felhős kiszolgálókban lesz. A GPU-ra kirakott memcached rendszert alkalmazza a YouTube, a Facebook, a Twitter, a Flickr, illetve a többi nagyobb hasonló portál, de a PCI Expressen keresztüli adatmásolás eléggé korlátozó, vagyis ahhoz, hogy előnyt lássanak belőle brutálgyors GPU kell, ami viszont durván fogyaszt. Ezeknek a cégeknek egy Kaveri APU Opteronban igazi főnyeremény, mert tökéletes az IGP a memcached rendszerre, és nincs adatmásolás, hiszen közös a memória. Nyilván nem véletlenül tűnt fel a 2013-as útitervben az Opteron APU. Beledobva az új SeaMicro SM15k rendszerbe, gyakorlatilag megvan az ultimate kiszolgáló a YouTube, Facebook, Twitter, Flickr négyesnek, de még a többieknek is. A Hadoopot használó szerverek szintén nagyon sokat profitálnak a Kaveri integrációjából. Szóval ahol a Kaverinek nagy haszna lesz az újításokból, azok a felhős kiszolgálók, a mikroszerverek, de a HPC is elég komoly opció.
A konzumer szinten a játékok láthatják a Kaveri integrációjának előnyét. A fizika állandóan előkerül, de mindig gond lesz, hogy ha hat a játékmenetre, akkor nem skálázható, vagyis nem lehet eldurvulni, hiába az elérhető számítási kapacitás. Ugyanez a gond a processzor oldalán is. Ott is főleg SSE2-re építenek még a fejlesztők, mert a skálázhatóság korlátozza a továbblépést. Egyszer meglépjük, de nem ma, és nem a közeljövőben. Szóval a fizika gyorsítása az marad az eye-candy részre (részecskeszimuláció), amit persze lehet fizikának hívni, de lényegében grafika.
Amit már több fejlesztő is felvetett, mint valóban használható alternatíva az a frustum és az occlusion culling. Előbbi rengeteg vektoros számítást használ, míg utóbbi gyakorlatilag egy előrenderelés nagyon egyszerű objektumokkal. Ezek nagyon ideálisak egy IGP-nek. A sorting is nagyon értékes terep, és baromira az IGP a legjobb rá. Itt tényleg nagyon előnyös a közös címtér. Ott a tartalomkikódolás is, amivel jobb lehet a streamelés. A játékok mennek afelé, hogy ne legyen töltőképernyő, tehát valós időben kell streamelni, és ez valós idejű tartalomkikódolásért kiállt. Például az agyontömörített textúrákat ki kell kódolni a GPU számára emészthető formátumba, ha megatextúrát használ a játék. Az útkeresés is elég jó opció az IGP számára egy stratégiai játéknál.Amire az AMD még nagyon figyel az a hang-, gesztus- és mozgásfelismerés. Mindegyik nagyon illik az IGP-hez. Főleg a gesztus és a mozgás, mert alapvetően képkocka lesz a beviteli adat. Ezek már ma is léteznek csak nem elég pontosak, és a pontosságot a ma elérhető számítási kapacitás korlátozza. Az IGP-vel gyorsítva ez új szintre emelhető.
Biometrikus azonosítás a biztonság szempontjából nagyon jól gyorsítható terület. Nincs pontosabb azonosítás a retinaszkennelésnél, de zabálja a teljesítményt.Nagyjából ezek lehetnek a tényleges felhasználási módok, plusz a mostaniak gyorsulhatnak.
(#25) Jim Tonic: Az a Piledriver lesz. Jönni fog októberben-novemberben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Október és FM2 kell neki.
(#36) ddekany: A beszédet egybevettem a hangfelismeréssel, ahogy az arcfelismerést a gesztussal. A beszéd amúgy annyira nem gáz már most sem, lehet még hova fejlődni, de ami nagyon gyenge az a képi adatok pontos felismerése ... mozgás, gesztus.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
"Végül változás érte az energiamenedzsmentet is. Az Intel a készenléti módban bekapcsoló energiagazdálkodási állapotok mellett bevezet egy hasonlóan takarékos aktív állapotot. Ez lényegében arra jó, hogy az adott notebook készenlét helyett aktív állapotban maradjon, vagyis függetlenül attól, hogy nem használja a felhasználó, képes legyen fogadni az üzeneteket például. Az Intel szerint ez a jól megírt programok számára transzparens, vagyis elméletben nem lehet gond, ha a készenlét helyett a felhasználó az új aktív állapotnak szavaz bizalmat. Persze amint használatba lesz véve a mobil termék, azonnal bekapcsol a szokásos aktív idle állapot."
Köszönjük
... de a tényekkel látom te sem szállsz vitába, mert az nagybetűs tény, hogy képminőségben van mit faragni a hátrányból. 
A felvezető előadásba nem kötöttem bele, csak langyos volt. Nem azért, mert nem volt izgalmas, hanem azért, mert azt a jövőképet vázolta fel az Intel, amit az ARM és az AMD már 2010-ben megtett, és az Intel a Sandy Bridge németországi bemutatóján közölte rá, hogy nem kivitelezhető ... talán 10 év múlva. Ez így langyos, mert innovatívként mutatták be, azt amit más két évvel hamarabb felvázolt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Tehát alapvetően azzal a ténnyel van gondod, hogy a Corel és a VideoLan nem készített támogatást az Intel termékekhez, mert nem értékelték megfelelő minőségűre az OpenCL meghajtójukat. Már bocs, de ez legkevésbé az én hibám. Az Intelnek kell írni, hogy vegyenek fel több rendszerprogramozót, adjanak nagyobb anyagi támogatást a szoftverfejlesztőknek, illetve fejlesszék gyorsabban az OpenCL SDK-jukat. Ha ezeket megteszik, akkor nem lesz a jövőben olyan dolog, hogy ez meg az a funkció csak AMD hardverrel üzemképes.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Miért nem hoztok ellenpéldát az állításaimra, vagy valami kézzel fogható cáfolatot? Mindenkinek adott a lehetőség, de állandóan csak a sértődés és a levegőbe beszélés megy. Egyszerű a helyzet, ha nem tetszenek a tények, akkor ne olvasd el azokat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ha egy program feldolgozása valamitől gyorsul, jelen esetben a GPU-s feldolgozástól, és az számodra nem fontos, attól még másnak nem lehet az? Valaki szeretne gyorsabban betömöríteni egy fájlt ... például.
Elfogadható, hogy nem veszel új gépet, mert nem akarsz gyorsabbat, de ezt nem biztos, hogy érdemes általánosítani.A VLC AMD-exkluzív implementációja nem a sebességre hat, hanem a képminőségre. A sebességre az OpenCL scaling szolgáltatás hat, de az univerzális, vagyis nincs az AMD driveréhez kötve. Az OpenCL open platform, vagyis mindenki támogatja. Ha az Intel és az NVIDIA driverein is megfelelő az adott funkció működése, akkor természetesen nincs oka a fejlesztőnek letiltani azt. Éppen ezért a VLC a gyorsított scalingot nem is korlátozza az AMD OpenCL driverére.
A Corel is megmondta, hogy amint sikerül megoldani az Intel és NVIDIA termékeken tapasztalt gondokat engedélyezik. Ehhez egyrészt a fejlesztőknek kell tovább optimalizálni, másrészt a drivereket is hozzá kell igazítani ehhez. Ergo a WinZip gyorsított tömörítése sem marad örökre AMD-exkluzív.Állítottam valaha, hogy CPU-ban erősebb az AMD? Itt most tudtommal APU-król beszélünk. Legalábbis az OpenCL igazi célja a heterogén módon történő programfuttatás.
[ 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
t72killer
#72
üzenetére
Már most is van 120 Hz támogatás a driverekben. A Sandy Bridge óta. A 3D Vision viszont zárt rendszer, vagyis optimussal nem üzemképes. Csak olyan noti lehet 3D Visionös, ahol az IGP inaktív és a dedikált GPU-ra van kötve a kijelző.
Bármelyik optimusos noti kiesik ebből, mert kijelzőt nem köthetsz közvetlenül a dedikált GPU-ra. Vagy optimus, vagy 3D Vision. A kettő együtt nem lehetséges.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A hardver elméleti képességeiről beszéltem. Szoftverben még mindig fényévekre vannak. Amiről 'Geri' ír az az OpenGL driver, ami tényleg rém gyenge az Intelnél.
A hardver tempóját tekintve persze jóval lassabb a HD Graphics 4000, mint a leggyorsabb Trinity-s Radeon IGP (akár mobil, akár asztali), és ez főleg akkor jön elő, ha magas részletességet állít be a user a programnak, ahol a HD 4000 elfogy. Jellemzően médium szintig bírja. Ezek nyilván abból erednek, hogy az AMD jóval erősebb setup részt használ, hiszen órajelenként feldolgoz egy háromszöget, ami az Intelnek négy órajel, vagy a textúrázóblokk az valóban képes Gather4-et használni, ami pokoli előny DX10./11 alatt, hiszen minden ilyen játék támogatja. Az Intel tök logikátlanul csinálja, mert egy csatornán csak egy mintavételező van, míg az AMD-nél egy csatornához négy tartozik. A Gather4 utasítás az logikus. Egy helyet egyszerre négy mintavétel legyen, ehhez négy mintavételező kell, ahogy az AMD csinálja. Az Intel megoldása formálisan képes támogatni, de úgy, hogy négy órajelig csak a mintavételezéssel törődik az adott textúrázó csatorna. Ez a megoldás még lassabb is lehet, mint Gather4 nélkül, hiszen 3 kötelező üres ciklust fut a szűrő és a címző. Bárki találta ezt ki az Intelnél, az remélhetőleg már nem dolgozik ott (a jövőre való tekintettel persze, semmi személyes
). Szerencsére a Haswell IGP-je már valós Gather4 támogatást kap. A kisebb-nagyobb gyenge pontok mellett azért a Gen7 architektúra már elég jó. Gyakorlatilag a Gather4 para az egyetlen, ami komoly gond. Persze az LLC-be mentő stream out sem a legjobb, de az még benne van az elfogadható kategóriában. Ami viszont elég jó az a compute hatékonyság, és ez első nekifutásra dicséretes. Ha igazak a feldolgozók számáról érkező pletykák, akkor ez a Haswellben is javulni fog valamennyit. Persze a GCN ellen kell is.
Összességében a Gen7 architektúra tényleg nem rossz. Ami jelentősen visszafogja bizonyos szituációkban az a driver, és erre az Intel még mindig nem fordít kellő figyelmet.A WinZip és a VLC egy vitában merült fel. Nem azért, mert a legjobb példák az elérhető gyorsulásra, hanem azért, mert csak AMD-s OpenCL driverrel működő funkciókat tartalmaznak. Ez úgy jön le, hogy az AMD kisajátít egy szabványt, de valójában csak a fejlesztők nem engedik, hogy fusson a funkció Intel és NV driveren, amíg nem tudják garantálni a sebességelőnyt, vagy a megfelelő működést.
[ 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
Chriss745
#87
üzenetére
A GPGPU az sokat gyorsít a specializált feladatokon. Ezért használják. Az általánosabb feladatokhoz közelebb kell vinni a CPU-hoz a GPU-t, vagyis integrálni kell. Ezért születnek olyan OpenCL programok, mint a WinZip (GPU-s gyorsításra), mert az integráció lehetővé teszi, hogy valamennyire eltávolodjunk a specializált feladatoktól. Itt is gond azonban az adatmásolás, mert a CPU és a GPU hiába van fizikailag egy lapkán, attól még különálló memóriaterületet használnak, ahogy a CPU és a dedikált GPU. És az adatmásolás problémája jelentős, mert amit megnyert a GPU-s gyorsítással, azt az adatok másolásán elvesztheted. A következő lépcső tehát az, hogy a CPU és az integrált GPU közös címteret és megosztott memóriát használjon. Ilyenkor adatmásolásra nincs szükség.
A másik gond, hogy ha a hardver adott lesz, akkor felmerül a programozok szemszögéből az a probléma, hogy van egy rakás eltérő rendszer, teljesen különböző fizikai ISA-kkal, és ezeket nehéz programozni. Erre kell majd egy teljes infrastruktúra, mely bevezet egy mindenki által támogatható virtuális ISA-t. Például HSA.Az új dolgok mindig lassan terjedtek, ezen nincs semmi meglepő.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Két részre kell bontani a kérdést. El lehet érni így is a megfelelő throughput teljesítményt ilyen homogén iránnyal, de csak akkor, ha a fogyasztást másodlagos tényezőként kezelik (szerverekben tolják is ki a TDP limiteket már a következő generációnál). Ha a mobil irányt ide vesszük, akkor egységnyi fogyasztás mellett semmi esélye olyan throughputot elérnie egy ilyen rendszernek, amilyenekkel az IGP-k dolgoznak. A felét talán lehet hozni, de akkor is az Intel homogén megvalósításának lesz a legnagyobb fogyasztása, beleszámolva két node előnyt (persze a Dennard Scaling hanyatlásával ez egyre kevesebbet ér). Ez a koncepció akkor érne valamit, ha az NTV technológiák már most bevethetők lennének, de egyelőre még kísérleti fázisban van.
Az AVX-1024-re inkább logikai szempontok szerint lenne érdemes gondolni. Már 512 bitre ki van terjesztve a Larrabee-ben. A következő lépcső az 1024 bit. Na most nem kötelező ám 1024 bites AVX utasításokat ilyen széles feldolgozókon végrehajtani. Lehet akár 256 biteseken is. Az látszik a Larrabee-n, hogy az Intel Pollack szabályát veszi figyelembe, ami ugyanolyan gyógyír a Dennard Scaling hanyatlására, mint a GPGPU.
Az Intelnek a rendszerszintű integrációja az olyasmi lehet, hogy megvan a gyűrűs busz alapnak, amire ott az LLC. A tárat le kell cserélni egy SRAM-nál jobb sűrűséget adó megoldásra. eDRAM is jó, ha az FBC nem jön be. A lapkában meg lesznek a magokhoz való szeletek, a gyűrűs busz, és azokra fel lesz fűzve x CPU-mag és "jóval több mint x" Larrabee mag. A Larrabee Pollack szabályára építkezik, míg a CPU-magokat meg kell tartani az értékelhető egyszálú teljesítményért. Az AVX támogatást egységesíteni lehet a két mag között, vagyis a Larrabee kaphat 1024 bites feldolgozókat, míg a CPU-magok képesek lehetnek 256 bites feldolgozókkal dolgozni, de ugyanúgy támogathatók az 1024 bites utasítások. És persze a CPU-magok más órajelen kell, hogy fussanak, mint a Larrabee magok, de ez a legegyszerűbb gond amit meg kell oldani a koncepcióban. Én ezt raknám össze, hogy versenyképes maradjak. Nyilván sok a buktatója, és sok a kockázat is, de most ezt fel kell vállalni.A HSA-t szerintem mindenképpen támogatni kell. Vagy, ha azt nem, akkor egy másik hasonló koncepciót. A fejlesztői nyomás itt most óriási lett, ahogy az AMD megmutatta mit tud egy ilyen rendszer. Johan Andersson már kiállt, hogy nem pont a HSA érdekli, hanem az a koncepció, amit az infrastruktúra felkínál a fejlesztőknek. Szerinte ez a jövő, és felszólította az összes gyártót, hogy álljon be mögé, vagy ha nem, akkor egyezzenek meg egy másik hasonló megoldásról, amit tényleg mindenki támogat. Erre egyébként az Intel kivételével szerintem mindenki hajlandó lenne, hiszen ellenérvet nehéz felhozni ellene. Az Intelnek az a baja, hogy a HSA, vagy a HSA-hoz hasonló koncepcióval teljesen bukó a felépített monopóliumuk. Gyakorlatilag az x86 mint jelenlegi erős érték szart sem fog érni.
A HSA azért opció, mert annak már kész van az 1.0-s draft specifikációja, és az úgy van kialakítva, hogy könnyű legyen támogatni a hardver oldaláról. Emellett a HSA-nál nyíltabb alternatíva aligha lesz. Minden alapító besorolású tag egységes anyagi támogatást ad, egységes a szavazati jog, egységes a beleszólás, egységes a marketing, szóval akár csinálnak mellé még egy másik alternatívát ennél egységesebb formai működést az sem tud majd felmutatni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
... de a tényekkel látom te sem szállsz vitába, mert az nagybetűs tény, hogy képminőségben van mit faragni a hátrányból. 
Új hozzászólás Aktív témák
ph Az új generációs architektúra lényegében az IGP szempontjából fejlődött, de az AVX2 utasításkészlet is hasznos.
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Autós topik
- Kerékpárosok, bringások ide!
- Asztalos klub
- Redmi Turbo 3-ból készül a Poco F6, megvan a start dátuma
- DOOM (Reboot)
- Miért vezet mindenki úgy, mint egy állat?
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Projektor topic
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- További aktív témák...
- Beszámítás! Intel Core i7 4790K 4mag 8szál processzor garanciával hibátlan működéssel
- Intel Core i7-7700 processzor (használt)
- Fris AMD AM5 Processzorok - Új - Garanciás
- Hibátlan - AMD Ryzen 3 2200G - 4 mag 3.5GHz + Radeon Vega 8 IGP + gyári hűtő AM4
- Intel I7 12700KF 14mag/20szál - Új, Tesztelt - Eladó! 85.000.-
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen