Re: Gyenge negyedév volt az AMD-nél
#1
Elküldve: 2012. 10. 12. 10:49
https://www.hwsw.hu/hirek/49196/amd-intel-processzor-piac.html
#2
Elküldve: 2012. 10. 12. 10:49
#4
Elküldve: 2012. 10. 12. 10:59
#5
Elküldve: 2012. 10. 12. 11:00
#6
Elküldve: 2012. 10. 12. 11:05
Elõször, amikor ezt a kezdeményezést beindították 20000 darabot osztottak ki. Azóta még csináltak párat. Mivel sikeresnek tûnik, így nagyon valószínû, hogy nem csak Amerikában csinálják tovább, hanem a világ minden táján. Úgy sem fogja elvinni senki a Trinity mellett.
Szerkesztette: Abu85 2012. 10. 12. 11:07 -kor
#7
Elküldve: 2012. 10. 12. 11:07
#8
Elküldve: 2012. 10. 12. 11:11
Igazából van logika abban, amit Rory kitalált, hiszen megveszik konkrétan a szoftver támogatását, vagy elérik valahogy, hogy annak egy bizonyos funkciója csak AMD-n fusson. Ugyanakkor túl agresszív az anyagiak átcsoportosítása. Emellett ennek az egésznek reklám mellett lenne értelme, mert az AMD már felrakott az ftp-jére nagyjából 1 GB-nyi OpenCL alkalmazást, amit ők pénzeltek, de senki sem tesztel velük, illetve senki sem tudja, hogy léteznek.
Szerkesztette: Abu85 2012. 10. 12. 11:14 -kor
#9
Elküldve: 2012. 10. 12. 11:13
#10
Elküldve: 2012. 10. 12. 11:21
Értem a muxless koncepciót az AMD-nél és az NV-nél is, hiszen a muxed az a juzernek kellemetlen a manuális váltás miatt, míg a dGPU állandó meghajtása lezabálja az aksit. Ugyanakkor, ahhoz hogy ez mûködjön az egész minden fejlesztõnek oda kellene raknia magát egy direkt támogatással, mert nagyon sokan egyszerûen nem tudják, hogyan kell ezt mûködésre bírni, ilyenkor pedig bármit csinálsz az IGP fog dolgozni, mert az van direkten rákötve a kijelzõre. Nem bonyolult ezt megoldani működőre, csak nem egy fejlesztő nem csinálja meg normálisra a támogatást. Ennél nagyobb baj, hogy miután kiderült, hogy nem megy, még úgy sem javátják patch-ben. Ne kelljen már hackelni egy notit, hogy a Max Payne 3 észrevegye, hogy az IGP mellett van egy dGPU is. A Skyrimet becsületükre legyen mondva, legalább javították, mondjuk szerintem csak azért, mert az semmilyen hackel nem volt működőképes.
Szó se róla, vannak hibák a programokban, de ha már benne maradt, akkor ott a patch lehetősége. Élni kellene vele. Ebből a szempontból a gyártókat azért hibáztatom, hogy nem magyarázzák el a fejlesztőknek, hogy a muxless átkapcsolás nem csak móka és kacagás, hanem támogatás is kell hozzá, legalábbis bizonyos feltételeket be kell tartani az erőforrás allokációjában. Értsd ne a GPU1 hardvert kérje az alkalmazás direkten, mert jellenző, hogy a muxless hardver GPU2 (az Intel procis gépeken biztosan, az AMD-nél a GeForce lenne a GPU1, de abba meg nem raknak GeForce-ot).
Szerkesztette: Abu85 2012. 10. 12. 11:29 -kor
#11
Elküldve: 2012. 10. 12. 11:34
Aksi időt meg leszarom mert ha játszik az ember be vna dugva a hálózatba, egyéb estbe meg szinte minden lapos kibír 1,5-2 órát ált felhasználás mellett, ennyinek elég kell lennie.
Szimplán kutya se fogja nézni megint hogy ez így job vagy ugy jobb, azt fogják látni hogy A laposba van egy INTEL erős CPU amiről tudjuk hogy erősebb mint a B laposban lévő AMD vel szerelt változat, illetve ha kell akkor az A laposban van egy diszkrét jól használható VGA ami megegyezik teljesítményben a B ben lévővel, de mégis azt látják hogy A lapos kb ugyanannyi vagy még tlaán olcsóbb is mint a B.
Szerinted mit fog venni a vásárló? SENKIT NEM ÉRDEKEL HOGY 1 ÉV MÚLVA JÖN E SOFTWARE FRISSÍTÉS HOZZÁ, csomó ismerős aki kkevésbé jártasak az informatikában telepítésk után még szine mindig a vásárlákos kapott drivert rakják fel.
Ezért rakat hulladék ez a politika, mert ahogy irtad elvonják tőlük a pénzt meg gondolom a gyártóknak még + mányba is került a terméktámogatás ilyne irreális távlatokban.
#12
Elküldve: 2012. 10. 12. 11:55
A Skyrim a másik hibát követte el, vagyis azt az erõforrást érvényesíti, amelyikre a kijelzõ van kötve. Nyilván ezt egy muxless rendszer köszöni szépen, mert a gyártók az IGP-re kötik a kijelzõt. Erre nincs is gyógyír, mindig az IGP-n fog futni a játék, és leszarja, hogy van egy dGPU a notiban. Ezért jött rá egy patch, hogy érvényesíteni tudja a program azt a hardvert is, amelyikre nincs kötve kijelzõ, vagyis a dGPU-t.
Ezek elég komoly problémák, amik elkerülhetõk, de rendszeresen beleütköznek a fejlesztõk. Maga a gond is általános. Nem csak az Optimusra hat, hanem az AMD muxless átkapcsolására is, ami a PowerXpress, vagy az Enduro. Egyedül a Dual Graphics immúnis ezekre, mert az hibrid megoldás. Ott mindig az IGP lesz érvényesítve, és a driver a CF profilból hozzárendeli a megfelelõ Dual graphics módot, ha ez lehetséges az adott programra. Mivel az AFR-nél eleve el kell fedni a hardverek közötti különbséget, így teljesen mindegy, hogy az IGP, vagy a dGPU erõforrását érzékeli a program, a két egység között el van fedve a technikai eltérés.
A Hd 5450/6450-et muxedben lehet bekötni, vagy direkten. A gondok a muxless bekötésre vonatkoznak. Ezért nem érzel problémát. A muxed mód az eleve úgy mûködik, hogy ahogy bekapcsolod az egyik erõforrást, így leválasztódik a másik drivere. Ezáltal a program csak egyetlen GPU-t tud érvényesíteni.
Az AMD a GPU-s gyorsítás felé megy. Ilyen esetben kötelezõ egy hosszú terméktámogatás, mert ha 2,5 év múlva érkezik egy program, akkor annak lehet hogy új driver kell. Ez persze világos, hogy a gyártóknak nem tetszik, mert megnöveli a supportra rakott terhet, és ezzel a már eladott termékbe fektetett költségeket, de neked ugyanakkor nem lesz mindegy, hogy az adott program elindul-e, vagy sem.
Az viszont igaz, hogy az Intel terméktámogatás a gyártók szemében sokkal kedvezõbb. Egy év mainline és kész. Utána ami nem fut, az nem fut, ott az új platform, amit meg lehet venni. Az OEM-eknek ez kevés költség, és még nyernek is vele, hiszen gyorsabban sarkalnak téged vásárlásra.
Szerkesztette: Abu85 2012. 10. 12. 11:56 -kor
#13
Elküldve: 2012. 10. 12. 11:59
#14
Elküldve: 2012. 10. 12. 12:07
Aztán meg mennek a bíróságra mert az intel tisztességtelenül viselkedki mert 10 laposból jó ha 1 tartlamaz nyomokban AMD terméket a polcon.
#15
Elküldve: 2012. 10. 12. 12:19
Azzal meg hogy negyedévente jelentenek be ilyen olyan apikat, amik majd a jövő meg a heterogén programozás meg az opencl meg akármi... semelyikből nem lesz soha semmi, egyik mögött sem lett sosem érdemleges támogatás, csak a nagy szavak, puffogtatások és közben meg nagy nulla, mert a szoftveres részlegük is ramaty. Nem képesek professzionális termékeket készíteni professzionális szoftvertámogatással.
Folyamatosan megy a CUDA megfog halni, mert a zárt .... aztán mi van? A CUDA él és virul abban a környezetben ahova szánták, mert az NV képes mögé rakni egy profi szoftveres támogatást (ahelyett hogy minden hónapban valami spanyol viaszt találnának fel). Ennek köszönhetik a Quadrok és a Teslák a sikereiket, és verik bucira az AMD minden suta kezdeményezését ezekben a szegmensekben is.
R.I.P. AMD
#16
Elküldve: 2012. 10. 12. 12:54
Megkapta az HSA (FSA) terveket. Meg kellett egyezni számos céggel, hogy támogassák, és úgy kellett kidolgozni az 1.0-s draft speckót, hogy megfeleljen a partnereknek. Azóta ez egy picit húzódik, mert a Samsung és a Qualcomm is belépet gyorsan, de idén véglegesítik. Nyilván ez az irány, amit kigondoltak szoftveres fejlesztésekért kiált, így ennek megfelelően kevesebb pénzt kapnak az OEM-ek, és többet a szoftveres fejlesztések és a programok támogatására szintén több megy el. Nyilván a HSA 1.0 véglegesítésével el kell készülnie a CodeXL-nek, szóval az most egy alapvető priorítás.
Rory stratégiája nagyon egyszerű lett. Felkínálnak egy alapítvány keretein belül a fejlesztőknek egy olyan open infrastruktúrát, amire ha megírják az alkalmazást, akkor az módosítás nélkül minden cég hardverén futni fog. Ezért is csúszik egy picit a HSA 1.0, mert tudják, hogy az Intel nem fogja támogatni, hiszen oda lenne az x86 előnye, azaz még a véglegesítés előtt megcsinálják úgy, hogy ne is kelljen támogatni, így a rendszer kap egy legacy módot. Ezzel akkor is fut a HSA program, ha az adott hardver direkten nem támogatja.
Most minden ennek van alárendelve. Ezért megy több pénz a fejlesztőknek. A mai DX11-es és OpenCL-es programok 80-90%-a el sem készülne, ha az AMD nem támogatná a fejlesztést. A DX11 az talán, de az OpenCL az kizárt. Egyedül talán az Adobe az akinek az OpenCL az átjárhatóság miatt fontos. Ők valszeg az AMD segítsége nélkül is megcsinálták volna az OpenCL-re való átállást, mert kiszámíthatatlan, hogy az Apple mikor milyen hardverre épít, így csak a CUDA-ra nem lehet alapozni. A többiek szerintem bele se fogtak volna, ha az AMD nem rakja bele a pénzt. Az OpenCL-es x264-ről például mondta, Jason Garrett-Glaser az AFDS-en, hogy próbálkoztak már az Intellel és az NV-vel. Megpróbálták a CUDA-t, de eredménytelenül. Az AMD-vel összeállva viszont megcsinálták az OpenCL-es x264-et. Erre megy most a pénz, mert nem csak ezek készülnek ott, hanem még számos program és játék. Mind a Kaverihez lesz igazítva. Nyilván abban tökéletesen igazad van, hogy az a költekezés, amit a szoftverfejlesztők felé most mutat az AMD, az nagyon agresszív, és meg is van az eredménye, így talán jobb lenne, ha megosztottabb lennének az anyagiak, ellenben az még ma sem tiszta, hogy Rory mennyi programmal szeretné várni az új termékeket. Annyit tudunk, hogy 1 millió fejlesztőt szeretnének a HSA-ra állítani, vagyis a heterogén programozással foglalkozó réteget meg szeretnék tízszerezni.
#17
Elküldve: 2012. 10. 12. 13:03
www.m12technology.com
I'm CEO bitch
#18
Elküldve: 2012. 10. 12. 13:05
A szoftveres támogatás hiányáról annak értelmében vicces beszélni, hogy az AMD partnerségében készül a legtöbb DX11-es játék és OpenCL-es program. Szintén ott a CodeXL béta, ami az első olyan fejlesztőkörnyezet, melyet kifejezetten heterogén programozáshoz fejlesztettek.
#19
Elküldve: 2012. 10. 12. 13:09
#20
Elküldve: 2012. 10. 12. 13:14
A, befuccsolnak mert már nincs gyár amit el lehetne adni vészhelyzetbe
B, az OEM ek le fogják szarni, és marad a 100 ból 1 eladott lpaosban lesz AMD
C, intel beéri őket addigra és ugyanott vannak mint a B esetben amiből meg za A következik.