Meg lett modva az elején, hogy soha.

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Itt nem erről van szó. Az AMD szoftveres csomagja a SoC fejlesztésekre vonatkozóan nagyon komplex, mert megközelítőleg nem épít senki sem olyan gyorsítókat, mint ők, és ahhoz, hogy ebből kihozzanak 15 wattos APU-kat saját szoftvereket használnak az automatizált tervezésnél. Ezeket előbb át kell tervezni a FinFET-hez, különben a hatékonysága csak romlani fog.

Ezt meg lehet nézni most is. Egy 15 wattos top Carrizo SoC teljesítménye ~580 GFLOPS, míg az Intel top 15 wattos Skylake ~330 GFLOPS-ot tud. Ezek tényleges szintetikus mérések. Mérnöki szemmel az AMD ugyanakkora fogyasztásba nagyobb kombinált számítási teljesítményt épít, kisebb egységnyi területet foglaló gyorsítóval, annak ellenére, vagyis tulajdonképpen leginkább pont azért, mert jól ismert és kiforrott node-on vannak.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Vagy szimplán a igp-nek nagyobb a számítási teljesítménye, de ezt bizonyos dolgok miatt nem tudják kihasználni !? Nyilván egy hasonló l4 cashes megoldással megint visszalophatnák a trónt APU-k terén, ami a gpu-t illeti!

látok, hallok, érzek és gondolkodom.

"Ezek tényleges szintetikus mérések."

Nahat, ujabban megsem olyan nagy hulyeseg a szintetikus benchmark? Par eve me'g egy legyintessel elintezted az osszes szintetikus benchmarkot.

"AMD ugyanakkora fogyasztásba nagyobb kombinált számítási teljesítményt épít, kisebb egységnyi területet foglaló gyorsítóval, annak ellenére, vagyis tulajdonképpen leginkább pont azért, mert jól ismert és kiforrott node-on vannak."

Mihez kepest? Es mit mivel hasonlitasz ossze pontosan? Mert ha egy fullos, 4 magos / 2 modulos SKU-t nezek, akkor baromira nem kisebb a Carrizo (247 mm2), mint a Skylake (122 mm2). De ugye ott van az FCH/PCH is... De van egy sanda gyanum, hogy valami homalyos, iGPU CU/EU-ra szamitott teruletre celoztal

"a partnereik igényeinek eleget téve a teljes linuxos meghajtóarchitektúrát nyílt forráskódúvá teszik. Ezzel gyakorlatilag az egyes megrendelők az AMD segítsége nélkül is módosíthatnak a használt meghajtókon, tulajdonképpen teljesen személyre szabva a rendszert. Ennek a támogatási formának a másik előnye, hogy akár az AMD hivatalos terméktámogatási idejének lejárata után is használható marad a rendszer, hiszen a hibák harmadik fél által vagy akár házon belül is javíthatók. "

Ezen meg akkorat nevettem, hogy me'g a szomszedban is hallottak. De aztan rajottem, hogy valojaban mennyire szomoru az, hogy valaki, plane egy ujsagiro, egy ekkora baromsagot elhisz Marmint nem azt a reszet, hogy nyilt forraskod rulez, meg nem is azt, hogy az AMD alapvetoen joszandeku (angol kifejezessel elve: desperate -- aki tud angolul, az erti majd ezt a poent). Hanem azt, hogy egy XY ceg majd egy, az AMD altal fejlesztett, parszazezer/millio soros drivert fog bugfixelni, hazon belul. Hogyne. A teljes architektura dokumentacio nelkul, kulonosen valoszinu. Amikor mar amiatt komplett uj website-ot rendelnek a cegek, mert a regi webfejleszto lelecel a cegtol, es senki nem tudja atvenni a munkajat, mert senki nem erti a website source-at, hiaba van meg a cegnek, hiaba a ceg sajat maga fejlesztette..

[ Szerkesztve ]

Főnök, mikor lesz valami Zen hír? Többnyire arra várok már, de ha Te sem írsz még róla, akkor az jövő karácsony előtt nem lesz

Hold on, trying to give a fuck... Nope, not Happening • Powered by Fedora Linux • "Az élet olyan sz@r, szerencsére a felén már túl vagyok" Al Bundy

Fejlesztes alatt allo termekrol jot vagy semmit

Melyik ev karacsonyara gondolsz? Csak mert me'g az AMD sem varja a jovo ev vege elott a Zen piaci startjat. Ha pedig ok valamit elhelyeznek a naptarban, nos ... Az altalaban nem hamarabb szokott megvalosulni.

Meg fogsz lepodni, de attol meg bugfixelnek. Foleg ha nem olyan sulyos a bug.

Kik? Konkretumot szeretnek kerni.

Konkretumot nem tudok az APU-khoz. Viszont azt tudom, hogy ahol eddig dolgoztam, ott nem akadnak fent ilyen aprosagon, ha kell barmilyen driverbe belenyultunk, ha meg tudtuk talalni a hibat. Egy mamut cegre varni nem mindig kifizetodo es inkabb ratolnak 5 embert, hogy jarjanaka utana a bugnak. De megjegyzem nem ritka jelenseg a reverse enginneringes driver sem a linux kernelben, szoval a doksi hianya nehezito korulmeny, de nem akadaly.

Hat, erre nehez mit mondani Nem tudom, mekkora driverrol volt szo, amire 5 embert raallitott a ceg, es az hogyan aranylik mondjuk egy GPU vagy chipset driverhez. Mindenesetre eleve ritka az olyan ceg, aki 5 embert egy ilyen bug levadaszasara ra tud allitani: ez minden, csak nem kifizetodo.

Mindenesetre, ha a konkretumoknal maradunk, azt tovabbra sem tudom elkepzelni, hogy valaki hazon belul elkezd faragni egy mas altal keszitett, parszazezer/parmillio soros driver source-ot. Kulonosen amikor sok esetben me'g a driver keszitojenek is kihivast jelent egy-egy hiba megtalalasa vagy javitasa -- pedig naluk aztan minden megvan a munka elvegzesehez.

Azt persze el tudom kepzelni, ha egy adott ceg, aki vasarol parszazezer embedded APU-t, ragaszkodik hozza, hogy megkapja a driverek forraskodjat. De ez nem open-source kategoria, es nyilvan nem minden cegre vonatkozik.

Pl. ha porog egy kotber?

Ja, en meg azt nem tudom elkepzelni, hogy valaki exploitot talal idegen kodban, amikor a keszitoje se vette eszre... Vagy varjunk.

[ Szerkesztve ]

Egy exploitot hozol parhuzamba egy tetszoleges driver hibaval? Jesszum... Ne vicceljunk mar... Nyilvan egy sztring kezelesi bakit konnyebb megtalalni, mint kisakkozni azt, hogy mondjuk egy GCN GPU warp kezelese milyen idozitesi problemak miatt nem mukodik megfeleloen. Nem az olyan trivialis hibakrol beszelek, ami egy tetszoleges C kodban elofordulhat. Hanem amikor pl. a chipset vagy a GPU lelkivilagaban borul meg valami, es azt driverbol kell tweakelni/workaroundolni. Na az, a megfelelo architektura dokumentacio nelkul kicsit mas kihivas, mint szemre kiszurni egy exploit lehetoseget.

Csak, ha helyiértéken vannak kezelve. A top 15 wattos Carrizo és a top 15 wattos Skylake teljesítményéből azt is láthatod, hogy miért, mert a hol az egyik, hol a másik gyorsabb. Csak a munkafolyamattól függ.

A lapkaterületen elfoglalt IGP-terület százalékosan.

Az AMD nem szüntette meg a támogatást. Továbbra is van gyári normál, illetve kiemelt, aki igényli. Utóbbi esetben speciálisan gyorsan javítják a hibát. Viszont vannak olyan extrém kérések, amelyeket nem tudnak biztosítani gyári formában. Például nem ritka kérés a libdrm megkerülése, ami gyárilag nem kivitelezhető. De birtokold te a rendszert, és írd meg rá magad a drivert. Ott a forráskód, lehívható a teljes hardverdokumentáció és hajrá.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Hat ha neked az exploit=string kezelesi baki, akkor meg nem sokat lattal a vilagbol. Ez kb. a legalja az exploitoknak, amit szoftveresen is eszre lehet venni.

En csak azt mondom, hogy egy exploit megtalalasahoz nem kell a platformot ismerni. Egy C kodban exploitot barki megtalalhat, mig egy platform (chipset, CPU, GPU, IMC, stb) specifikus hibat megtalalni es javitani egy teljesen mas nagysagrendu problema. Egy exploit lehetoseg sokkal altalanosabb kodolasi problema, mint ha valaki 40 helyett 30 nanosec kesleltetest hasznal pl. egy GPU driverben, tok veletlenul. Ha nem az adott cegnel (aki a hardvert fejleszti) dolgozol, ha nincs hozzaferesed a _reszletes_ platform specifikaciohoz, akkor honnan fogod tudni, hogy a 30 helyett 40-nek kene ott lennie?

"Csak, ha helyiértéken vannak kezelve"

Tehat ha egy AVX optimalizalt szintetikus benchmarkrol van szo, akkor az hulyeseg es semmit nem jelent, de ha egy akarmilyen benchmarkban a Carrizo lenyomja a Skylake-et, akkor azt korbe kell hordozni es piedesztara emelni. Vilagos. Legalabb lennel kovetkezetesen szintetikus benchmark gyulolo, az me'g mindig jobb lenne mint ez a koponyeg forgatas...

"A lapkaterületen elfoglalt IGP-terület százalékosan."

Oke, tehat arra celzol, hogy %-osan kisebb teruletre tud nagyobb szamitasi teljesitmenyt zsufolni az AMD, mint az Intel. Ez abszolut igy van, csak kar, hogy ezt a x86 resszel nem tudjak megcsinalni. Es az is kar, hogy az osszteljesitmenynek ill. az akkumulatoros idonek sem hasznal a nagy es eros iGPU. Es igy -- sajnos -- fabatkat nem er az egesz Az lenne az igazan hasznos, ha le tudna menni az AMD is 5W TDP kornyekere, vagy ha az x86 resz a mostaninal is agresszivabb turbora lenne kepes. Majd a Zen megold mindent.

"Ott a forráskód, lehívható a teljes hardverdokumentáció és hajrá."

Tok egyszeru, valoban

[ Szerkesztve ]

Felőlem lehet a szintetikus teszt AVX-re optimalizált. Ez nem von le az értékéből, ha a megfelelő szinten van elemezve.

Mérnöki szempontból itt arról van szó, hogy a Carrizoba 15 watton belül több GFLOPS van, mint a Skylake-ben 15 watton belül, és ezt úgy érték el, hogy ez 28 nm-en van, míg az Intel 14 nm-en. Az már egy másik tényező, hogy ez a teljesítmény hogyan oszlik el. Ezért van az, hogy a gyakorlatban a Carrizo ott gyorsabb, ahol az IGP van használatban, míg a Skylake ott, ahol a CPU.

Másképp az olyan extrém igényeket, amelyek tényleg egyedi implementációra vonatkozónak nem tudják megoldani. Nem köteleznek rá senkit, hogy csinálják meg, de megnőtt a "roll your own" Linux koncepciókra az igény. Ennek az egyik komponense a nyílt driver.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Az 5 watthoz annyit, hogy nem érdekes ezen a felvevőpiacán az x86. A Mullins még ma is a leggyorsabb tablet SoC az x86-os szinten, és nem érdekel senkit. A normál Atom sem érdekel senkit, amióta az Intel pénzért árulja. Tudod mi érdekli a megrendelőket? A Rockchip és a Spreadtrum TSMC-nél gyártott Atom x3 generációja. De erre is megszűnik az igény, amint 6 dollár fölé megy a lapkánkénti ár

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Helyesebben, nem feltetlenul kell a platformot ismerni. De vannak platform szintuek is.

Az tetszett leginkább, hogy lesz nyílt forrású hivatalos driver. Az első lépés afelé, hogy végre vga-khoz is legyen Na persze belelóg a kezem a bilibe, de az első lépések

Mutogatni való hater díszpinty