Hirdetés
- ZIDOO médialejátszók
- Milyen billentyűzetet vegyek?
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Milyen videókártyát?
- Egy vagy két tápkonnektor lesz az új csúcs-GeForce-on?
- Elstartolt az Ulefone 5G-s, hőkamerás strapatabletje
- Fejhallgató erősítő és DAC topik
- Vezetékes FEJhallgatók
- VR topik (Oculus Rift, stb.)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
Hirdetés
-
Játékos TWS headsettel gyarapodott a SteelSeries kínálata
ph Az Arctis szériás újdonság számos platformon működésre bírható, és konzolok szintjén van a Microsoft gépeihez való verziója is a Sony-t favorizáló mellett.
-
StarCraft hírek: Készülhet egy új játék, miközben Game Pass-be tart a széria
gp November elejétől az előfizetők hozzáférést kapnak a sorozat első részének remaster kiadásához és a folytatáshoz.
-
Texasban készül az első 3D-nyomtatott hotel
it A daru méretű 3D-nyomtatóval most egy hotelt nyomtatnak a sivatagba, rétegenként.
Új hozzászólás Aktív témák
-
7time
senior tag
Lehet de most valahogy mégis a Samsung, TSMC volt hírben mint következő gyártó (a GLOFO nekem ugrott be) és 2016 lett vizionálva a gyártás, szerintem az idén már az Nvidia nem sokat fog mutatni készül a 14-16nm HBM -re, az AMD meg úgyszintén csak nekik van egy 2015 töltetük, max karácsonyra kijön egy 2 GPU Maxwel ami nem olyan rossz a kis fogyasztás miatt de nekem a 2 GPU-s dolgok elég unszimpatikusak lettek mindegy hogy ki gyártja.
[ Szerkesztve ]
-
SylverR
senior tag
Nem nagyon van kedvem minden hír, minden kommentjét végigolvasni. Tudom, hogy szoktál kommentelgetni. De míg az Intelnél építőjelleggel kritizálsz, az AMD-nél csak puffogsz.
Mi baj van a GloFo-val? Nem értem. 2016-ra ígérték a Zent. Ez 2016 októbere. Sacc perkb. Addigra még elkészülhet egy normális 16 nanos gyártósor. GPU-k tekintetében meg amúgyis a TSMC-nél fognak gyártatni. Még csak 2015 első negyedében járunk. Hogy a hírt hogyan kell értelmezni, nem tudom. De nem is érdekel. Csinálják, ennyi a lényeg.@(#11) adamssss:
Hát ja. Amikor képes az objektivitásra. De egyre ritkábban van ilyen.[ Szerkesztve ]
Nem!
-
SylverR
senior tag
Először is. Tudom, hogy a GloFo kivált az AMD-ből. Nem is akarok IT szakmabeli lenni, szóval nem zavar.
Viszont továbbra is az a véleményem, hogy a GloFo dolgozik a dolgon. Tekintve mennyit töketlenkedtek, hirtelen 28 nanonról 14-re lelépni azért egyből két lépésnek számít. Persze lehet rosszul látom, ez az én véleményem. Majd meglátjuk mi lesz belőle. Tény, a Samsung segített nekik, így haladhatnának gyorsabban is. De ezért nem kell pampogni, attól nem lesz hamarabb kész.Másrészt, láttam annyi kommentet a részedről, hogy meglegyen a véleményem. Nem fikáztalak, az egy kérdés volt. Abból is költői típusú.
Még valami: ha ez lenne az egyetlen ilyen eset, megérteném, hogy rosszul esik. De nem ez az egyetlen eset, hogy indokolatlan, és megalapozatlan fikázol AMD-s hír alatt. 20-ból jó ha 1-szer pozitív a véleményed. Akkor is fanyarédes, és megvan az az érzésem, hogy csupán mézesmadzag.
Igazad van. Nem az Intelről szól. Bár jó lenne ha arról szólna. De nem. Az AMD utálatodról szól.
Nem!
-
Abu85
HÁZIGAZDA
A Samsung gyártástechnológiája megegyezik a GloFo gyártástechnológiájával. Ugyanazt használják.
Többször is írtam és más is írta neked, hogy hatalmas tévedésben élsz, hogy az AMD feladta volna a Mantle-t. Csupán annyit mondtak, hogy ha valakinek elég az 1.0-s API funkcionalitása, az használjon Vulkant és DX12-t. Ez logikus, mert minek dolgozzon többször a programozó. De biztos tudsz róla, hogy nemrég elérhetővé vált a LiquidVR. Ez az SDK kizárólag a Mantle alatt működik. Konkrétan ez a VR mellékág.
Az OpenCL kapcsán korábban pont sérelmezted, hogy AMD specifikus programok születnek: [link] - ami egyébként szerintem is baj.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
7time
senior tag
Mindenkinek javaslom, hogy olvassa vissza Abu remek irasat a Mantle 2013-as debutalasarol, es vesse ossze a mai rideg valosaggal.
Nem tudom hogy konkrétan mit nyer ebből az AMD számszerűsítve de nekem eddig a Mantle jónak tűnik, átvette a Vulcan API és a DX12-be is bekerült, nekem ennyi a lényeg ha az AMD vesztett ezen ez már legyen az ő gondjuk, lényegben üzleti és ipari titkokban kotorászunk úgy hogy a sajtóra támaszkodhatunk, nem túl biztató.
[ Szerkesztve ]
-
7time
senior tag
Akkor hogyhogy az egyik kesz van, es termel, mig a masik a kanyarban sincs?
Ez szerintem nem meglepő, ha te gyártasz barmit és én átadom vagy megveszem a technológiát nem jelenti hogy egyszerre tudjuk ugyanazt nyújtani, nem tudom mennyi idő egy ilyen technológia átvitele de biztos nem 1-2 hónap.
-
-
joysefke
veterán
Amig az Athlon 64 legyozte a Pentium 4-et es az Opteron legyozte a Xeont, addig gurult is az AMD szekere. Amikor elveszitettek a high-end koronat, onnantol egyre gyorsulo tempoban csusznak egyre lejjebb,
Alapvetően egyetértek, de szerverfronton árnyaltabb a kép: itt a max teljesítmény "csak" egy fontos tényező de nem minden. Mellé kell tenni az enterprise szoftverek socket/magszám licenszkunstrukcióit illetve a fogyasztás/teljesítmény mutatót (no és persze az árat).
Szvsz az AMD ezeken a frontokon (is) bakot lőtt. Desktopon jó ötlet lehet a 8150 Bulldózert 8 magos CPU-ként marketingelni, de hogy szerver fronton miért kell ilyen bakot lőni, azt nem fogom megérteni...
-
mekker
őstag
Miért ne lehetne ugyanaz a két gyártástechnológia? A Samsung megcsinálta, a GloFo most ezt licenszeli. Most üzembe van helyezve a Samsung gyártósora, ahhoz nem fognak "hozzányúlni" a következő átállásig.
Nem tudom hogy megy a lapkagyártásban, de egy gyártósor fejlesztése/üzembe helyezése mindenhol kritikus pont, ezért ez a nagy csúszás a két cég között.Данное сообщение (материал) создано и (или) распространено иностранным средством массовой информации, выполняющим функции иностранного агента, и (или) российским юридическим лицом, выполняющим функции иностранного агента.
-
Abu85
HÁZIGAZDA
Kihangsúlyozom, hogy ott a LiquidVR! Csak az AMD saját API-ján keresztül működik.
Ezt mondta az AMD is, hogy számos dolog van még, amire a szabvány nem kínál megoldást.
Ez kell-e a fejlesztőknek? Nos a LiquidVR-t támogatja a CryEngine, a Source 2, a Frostbite, a Dawn Engine és a Panta Rhei. A Unity és az Unreal Engine is támogatni fogja, mert a VRLA-n mondták, hogy a VR-hez kellenek a gyártóspecifikus szoftveres fejlesztések. Tehát lényegében az összes VR-t figyelembe vevő motor támogatja az AMD saját API-jának új VR-es verzióját. A potenciálisan megcélozható piacból a 100%-os támogatás mióta PR?
Például az NV-nek a VR Directje is specifikus kiterjesztéseket igényel.
Az Ocolus is mondta, hogy amelyik gyártó az általános SDK-juktól várja a csodát csalódni fog.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A GloFo-nál is van LPE node. Pont erről szól a hír. Az LPP is lesz akkorra, amikorra a Samsungnál. Csak az LPE-re nincs nagy érdeklődés, mert gyorsan kész lesz az LPP, ami jobb.
Ez a baj az OpenCL-lel. Megírnak egy tök szabványos kódot az AMD APP SDK-val, és az Intel, illetve az NV OpenCL fordítója nem eszi meg. Mivel úgyis rossz lesz a kód, így inkább előre lefordítják AMD-re. Erre a gondra jön a SPIR, illetve most már a SPIR-V.
Nem az Intel implementációja szar, csak szinte minden gyártó másképp értelmezi az OpenCL C specifikációt, ami a fordításnál gáz. Mivel az APP SDK a domináns fejlesztőkörnyezet, így azt fogod látni, hogy az AMD-n megy és máson nem. Ettől viszont még a specifikációknál vannak értelmezési eltérések.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#56
hugo chávez
aktív tag
Fiery
#53
hugo chávez
aktív tag
"Meselhetnek pl. egy erdekes tortenetet arrol, hogy egy adott szoftver egyik fejlesztes alatt (!) allo benchmarkjaval kapcsolatban hogyan probal az egyik nagy hardvergyarto puhatolozni, hogyan probalja befolyasolni annak a benchmarknak a kialakitasat, felepiteset, mukodesi mechanizmusat, annak erdekeben, hogy az o hardverehez minel jobban igazodjon, minel jobban lehessen optimalizalni a benchmarkot a hardverre es viszont. Aztan meg egy finom elutasitas utan furcsa valasz jon a hardver gyartotol, mert ugy latszik, nehezen ertik meg, hogy a fuggetlen benchmark fejlesztes mikepp mukodik. Mindenkinek a kepzeloerejere bizom, hogy milyen szinre festi a hardvergyartot, es hogy milyen hardvert gyart. Sokan meglepodnenek, hogy melyik cegrol es milyen termekrol van szo, es talan atertekelnenek bizonyos dolgokat magukban
"Khmmm... Pár éve még éppen te szerettél volna gyártói optimalizációs tanácsokat kapni. Azóta meg már gond, ha valamelyik gyártó adni akarna ilyet? (Persze amennyiben valami csalásra akarnának rávenni, vagy arra, hogy a konkurenciáét ne tudja kihasználni a bench, az tényleg gáz.) Megértem, hogy élvezed az itteni "kritikus-ellenpont szerepet" (ami gyakran szükséges is amúgy), de éppen nemrég méltattam az objektivitásodat, viszont ez most nem igazán tűnik objektív hozzáállásnak. Vagy félreértettem valamit?
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
ukornel
aktív tag
#22 Fiery
"[...] ha valaki az AMD/GF-et kritizalja, mert lassabban dolgoznak, mint a konkurencia (ne felejtsuk el, nem csak az Intelnek van mar 14 nanos tomegtermelesu gyartosora! [...]"#24 7time
"Szerintem a Zen sorsa nem a gyártón fog múlni, most van választék bőven."Választék van, de miből? Jó-jó, hogy 14 nm, de az LPE még inkább telefon SOC-hoz passzol, nem nagy teljesítményű asztali procihoz, vagy GPU-hoz. Az majd az LPP lenne az ígéretek szerint - de abból még nem turkálunk könyékig a választékban, hogy finoman fogalmazzak.
-
Abu85
HÁZIGAZDA
És lett három low-level API-nk két év alatt.
Nem mondta a fejlesztőknek az AMD, hogy ne használják az API-t. Azt mondták, hogy ha szabványosan meg tudják oldani a gondot, akkor ne használják.
Mondták a GDC-n, hogy ha vannak egyedi igények, akkor azokat beépítik és elindítják a szabványosítást, úgy hogy a forrást odaadják a Microsoftnak és a Khronosnak.
Az API-t nem a hardverhez tervezik. A GCN előnye a dokumentációban és a publikus disassemblerben rejlik. Az, hogy milyen API-t használ a program lényegében mindegy.
Amire a saját API készült az ott van a szabványban. Most jönnek a még nem kezelt dolgok, például VR. Ezek is szabványban kötnek majd ki.
Pont azt kéri az AMD a fejlesztőktől, hogy jöjjenek a kérések. Így tudják megoldani, hogy úgy fejlődjön a piac, ahogy azt ők szeretnék.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AMD világosan megmondta, hogy csak olyan node-ra állnak át, ami előnyt is jelent, mint például kisebb fogyasztás. A 28 nm SHP-ról a 14 nm LPE nem előnyösebb a fogyasztásban. Az LPP már az és arra át is fognak állni. Ez egyébként érthető. Egy középkategóriás APU-nál nem annyira kritikus a lapkaméret, mert notiba kerül, viszont az számít, hogy kevesebbet fogyasszon. Egy telefonba tervezett SoC-nál a lapkaméret fontosabb és inkább kezelik a többletfogyasztást az alacsonyabb órajellel.
Ezeket a gondokat is kezeli a SPIR-V. Írhattok saját fordítót hozzá.
(#57) GhanBuri Ghan: A legtöbb jellemző változik a gyártói implementációval, tehát ez bonyolult téma nagyon. Nagyban függ a lapka attól, hogy milyen a szoftveres alap. Ez már többet számít, mint maga a csíkszélesség.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
ukornel
aktív tag
Tyúk, vagy tojás probléma, hogy azért olvad a desktop szegmens, mert nincs jelentős előrelépés a SB óta, vagy azért nem oda teszi a fő hangsúlyt az Intel (sem), mert az embereknek elég a meglevő teljesítmény. Nyilván ezek oda-vissza ható okok, melyek eredménye egy spirál, amit az hajt lefelé, hogy a felső szegmensben elfogyott a gyártástechnológia mozgástere.
A lényeg, hogy összességében lassulást látni az Intelnél is. Az ugyanezen az úton járó bérgyártók (és gyártatók) lemaradása pedig csökkent, a 8-10 hónap már előrelépésnek számít. Összességében a pozíciójuk javult (kevésbé rossz). Nem tagadom tehát, hogy van lemaradás, és ez versenyhátrány, de a versenyhátrány csökken.
-
Abu85
HÁZIGAZDA
De van. Egyrészt a Vulkanhoz az AMD adta oda a forrást. Másképp 2018 előtt nem érkezett volna meg. Ezt az idei GDC-n a Khronos meg is köszönte nekik azzal, hogy kiemelték az AMD szerepét. A DX12-nél Max McMullen mondta még egy évvel korábban, hogy igazából az egészet az AMD indította el azzal, hogy felhozzák a libGCM-et mint koncepciót PC-re. A Microsoft erre azt mondta, hogy ha azt gondolják, hogy ez megoldható, akkor tervezzenek egy prototípust. 2011-re kész lett, működött és erre épül a DX12.
Ahogy írja a cikk is az architektúrát kell ismerni. Ez minden low-level API-ra igaz, hiszen a fejlesztő írja meg azt, ami ma (még) a driverben van.
Viszont az Intel és az NV támogathatja a Vulkan API-t, és az AMD zárva tarthatja a technológiáját, anélkül, hogy bármi kár érné az ipart.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Még annyit, hogy Johan Andersson nyilván fontos szerepet játszott ebben a történetben, mert igazából ő az a személy, aki 2011 végén kikönyörögte az AMD-től, hogy neki külön csináljanak egy API-t, mert 2013 végére szüksége lesz rá. Valószínűleg sejtette, hogy a DX11-ben nem tudja garantálni a Frostbite új verziójának stabilitását, és ez így is lett. Az összes Frostbite 3 játék random lefagyaszthatja a DXGI-t. Tehát, ha ő nem utazik el 2011 végén Torontóba és nem kéri meg Matt Skymert, hogy a Microsoftnak leadott prototípusra építve jöjjön egy saját API is (akkor még nem volt neve), akkor ma csak a DX12 lenne.
A prototípusról egyébként tudott Johan Andersson már 2009-ben, hiszen Guennadi Riguer és Brian Bennett őt kérte fel technikai tanácsadónak.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egy volt, ami a PS4-es, és abban nem szerepelt az AMD. Másrészt nem értem mi a probléma. Az iparág történelmének legnagyobb előrelépése zajlik a szemünk előtt. Nem az új hardverektől fog majd leesni a PC-sek álla, hanem az új API-któl.
Egyébként az egész abból keletkezik, hogy a fejlődés nagyjából 8 éve nem normális irányba tart. Azért képesek olyan elképesztő dolgokra a PS3 exkluzív játékok például az AI szempontjából, mert a fejlesztők hozzányúlhatnak a hardverhez. És olyan AI-t, mint ami pár PS3 címben van még csak a fasorból sem láthatunk PC-n, aminek nagyban köze van ahhoz, hogy jó ideje egy zsákutcának a falát támasztjuk.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ettől még az SDK != engine != API
Ha az Intel akar LDL-t és D2D-t, akkor szükségük van egy saját grafikus API-ra. Ezen nem lehet változtatni, mivel az említett dolgokra a szabványos API-kban ma nincs megoldás, és belátható időn belül sajnos nem is lesz. Ezért vezette be ezt a két technikát csak az AMD, illetve a Sony, de nekik ugye fix a hardver.
Nem csak gyorsulás lesz. A legnagyobb előny az, hogy szabadon felhasználható lesz a processzoridő, hiszen eltűnik a kernel driver. Ennek az egyik hozadéka lesz a jobb AI például.
Naná, hogy nem jött be az Ageia. A robbanástól keletkező picike kis darabkák rajzolási parancsba kerülnek, ami drága volt. Másrészt a middleware-ek sosem a teljesítményükről voltak híresek. Ezért akar például az EA mindent saját maga írni.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
sayinpety
tag
Sajnos a Microsoft/Khronos/Intel/Nvidia a kisujat nem mozditotta a problemak megoldasaert. Nem csak az AMD fejet fuzik evek ota, am csak ok hallgatnak rank es megoldasokkal allnak elo.
Balf*szok? Nem. Csak felnek. A Microsoft es Khronos sosem akart explicit APIt PCre. Felnek az outsourcingtol. Joggal. A stabil anyagi hatterrel rendelkezo kiadonk kiszervezte az Intel/Nvidia optimalizalast. A core team csak GCNre fokuszal. Az R&D team zero Intel/Nvidia dev hardverrel rendelkezik. Jartam szomszedos kanadai studioknal. Mindenhol GCNt lattam.
Szamunkra mindegy a verseny. Akkor is eladjuk a szoftvert, ha GCNt hasznal mindenki. Microsoft es Khronos versenyt szeretne.
Intel/Nvidia erthetoen fel. Tudjak hogyan fejlesztik a multi-platform projecteket. A console a dominans faktor.
Egyedul az AMD erdeke az explicit API. A ket console hatalmas elony. A GCNrol mindent tudunk. Maxwellrol igazabol semmit. Intel hatareset, am nem megyunk semmire vele. Annyira gany az µarch, hogy PS4-en 60%ot gyorsito optimalizalas belassitja. Ugyanezzel a koddal AMD es NVIDIA sebesseget nyer.[ Szerkesztve ]
-
#95
hugo chávez
aktív tag
Fiery
#58
hugo chávez
aktív tag
Közben leesett, vagyis azt hiszem, tudom, hogy melyik cégről és a hardverük milyen "képességéről" van szó. Ha jól sejtem, nemrégen meg is említetted ezt a dolgot.
Nos, én messze nem látok bele olyan mélységekben ebbe az egészbe (benchírás, stb.), mint te, ez tény.
"Pl. marhara nem mindegy, hogy egy adott feladatot milyen adattipusokkal, mekkora adat halmazon vegzel, ezeken nagyon sok minden mulik."
Na de ami az egyik hardvernek kedvez, az a másiknak lehet, hogy nagyon nem fog. Akkor? Mi a megoldás? Fusson mindenen egyformán szarul, a legnagyobb közös nevező, vagyis csakis a mindegyik gyártónál egyaránt meglévő képességeket használva, de semmi specifikusat? Vagy mindenre és minden képességre külön optimalizálni, amennyire csak lehet és csak a végrehajtás ideje és/vagy az eredmény számítson, a módja nem, vagyis minden hardveren az annak megfelelő legoptimálisabb módon (az akár specifikus utasításkészleteket, képességeket használva) hajtódjon végre? Mondom, nem értek hozzá, de nézzük pl. a π számolgatós bencheket, mint a Hyper PI is. A feladat adott, konkrét tizedesjegyig kiszámolni a pi-t, minél gyorsabban. De szerintem az már totál lényegtelen, hogy adott hardveren gyártóspecifikus utasításkészleteket vagy egyéb képességeket is használhat, ha történetesen lehet azokra is optimalizálni, vagy a különböző gyártók hardverein akár egymástól teljesen eltérő, az adott hardvernek a legjobban fekvő metódussal hajtódik végre, a lényeg csakis az, hogy a lehető legjobban kihasználva az adott hardver képességeit, mennyi idő alatt végez, illetve, hogy az eredmény egyformán pontos legyen minden hardveren, amin a bench futni fog.
Szóval nem értem, miért baj az, ha egy gyártó ahhoz akar segítséget nyújtani, hogy egy adott bench az ő hardverük képességeit minél jobban ki tudja használni?Vagy most arról van szó, azt akarják, hogy magát a feladatot (nem pedig a végrehajtási módját) igazítsátok a hardverükhöz? De egyáltalán egy bench elkészítésénél mit kell figyelembe venni? Az a fontos, hogy olyasmivel dolgozzon, olyasmit csináljon, ami elterjedt, széles körben használatos? Vagy az, hogy az adott hardver minden képességét megpróbálja kihasználni, akár olyan feladatokkal is, amik végrehajtása a valóságban marginális jelentőségű, csak szűk területen lenne kihasználható?
"Mindegyik_ hardver gyarto ezt csinalja, ezert is visszatetszo szamomra az, hogy nehany gyartot divatos ilyen magatartas miatt utalni (pl. itt a PH forumokon), holott mindegyik gyarto tok ugyanazt csinalja, legfeljebb a nullak szama a kulonbseg, meg a rendelkezesre allo, piacot befolyasolo eszkozok tarhaza. Minden kapitalista ceg arra torekszik, hogy penzt csinaljon, ez a lenyege az egesznek. A piaci verseny is mindannyiukra ugyanugy vonatkozik, es mindegyik remenykedik abban, hogy nem fogja senki eszrevenni, hogy epp melyik versenyzo melyik masik hosszutavfuto versenyzo tarsa cipojebe csempeszett egy rajzszoget
Ergo vagy mindegyiket utalni kellene, vagyik mindegyiket egyforman szeretni. Nincs ertelme kivalasztani egyiket vagy masikat -- de persze megertem a kognitiv disszonancia erejét is "Mások nevében nem nyilatkozhatok ugye, de én leginkább nem azért utálok pár gyártót, mert néha talán etikátlan módszerekkel akarják a termékeiket jobb színben feltüntetni. Hanem azért, amikor szándékosan akadályozzák a fejlődést a piaci részesedésükre, súlyukra támaszkodva. Soha nem voltam AMD fan (sem), de mióta itt a fórumon egyre jobban azt tapasztalom, hogy egyesek pusztán márkafanságból fikázzák az AMD-t, amikor pedig (és most maradjunk elsősorban a PC gamer vonalnál) talán az egyetlen cég (persze ők is a saját érdekükből, ez nem is vitás), aki valóban törődik ezzel a területtel, állnak elő az innovációkkal folyamatosan, akkor azért elszomorodok. Hogy lehet fontosabb a saját érdeküknél ezeknek az embereknek az, hogy az imádott cégük legyen sikeres, az gazdagodjon? Talán mind részvényesek pl. az NV-nél? Nézd, én lesz.rom, hogy az AMD mennyire lesz sikeres, mint cég, mennyit, mennyi pénzt nyer a Mantle-ön, vagy bármelyik API-n, a "low level" irányon, amit elindított. Vagy akár a HSA-n. Engem az érdekel elsősorban, hogy én, mint felhasználó és gamer, mennyit nyerek ezeken a dolgokon.
Lábjegyzetként annyit, hogy kognitív disszonancia nálam pl. nem játszik, mostanáig és jelenleg is Intel procis gépem van és elégedett is vagyok vele. Viszont emiatt az intenzív fikázás miatt azt hiszem, ha a Zen magjai a Sandy (i5 2500, i7 2600) magonkénti teljesítményét fogják hozni hasonló TDP mellett, akkor vevő leszek rá. Annyi azért kell, mert elvek ide, elvek oda, de nem vagyok saját magam ellensége. Viszont a pénzemet inkább egy olyan gyártónak adom, aki, még ha önös érdekből is, de tényleg tesz előremutató lépéseket. Videókártyára meg ez hatványozottan vonatkozik, mert az Intel még hagyján, de az NV-t nem vagyok hajlandó támogatni, amíg ilyen a hozzáállásuk.
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
#103
hugo chávez
aktív tag
Fiery
#96
hugo chávez
aktív tag
Jó, de az természetes, hogy minden gyártó azt szeretné, ha az ő hardvere valamiben jobb, mint a konkurenciáé, akkor azt a valamit ki is lehessen domborítani. Ha most egy bench ezt teszi, az szerintem nem baj még önmagában. Említetted pl. az AES-t. Oké, hogy jelenleg mindkét nagy gyártó újabb CPU-iban van direkt támogatás, de ha nem lenne az egyikben, akkor már ne is írjon senki olyan bench-et, ami a másikénál ezt a támogatást ki tudja használni,? Vagy ott van pl, az AVX. Köztudott, hogy az AMD procik ebben jóval gyengébbek, mint az Intelek. Akkor az már tisztességtelen, ha az Intel megemlíti egy fejlesztőcégnek, hogy segítene optimalizálni, vagy akár írni egy bench-et kifejezetten 256 bites AVX-re?
""Ezert is a legjobb az, ha az ember (marmint a benchmark fejlesztoje) fejben kitalal egy problemat, amit meg akar oldani benchmarkon keresztul, aminek a megoldasi idejet akarja mérni, es amikor minden fejben ossze van rakva, legfeljebb csak utana megy a hardver gyartohoz erdeklodni, hogy az adott hardveren mikepp lehetne a benchmarkot minel jobban gyorsitani."
Az a baj, hogy ettől még simán kedvezhet akaratlanul is egy adott architektúrának az adott bench.
"es idealis esetben azt is eldontod, mekkora adathalmazon es milyen modon vegzed a benchmarkot, akkor a feladat adott..."
Ezt a részt nem lehetne úgy csinálni, hogy külön minden hardvernek a legoptimálisabb módon/adathalmazon? Végül is a végeredmény (vagyis hogy egyezzen minden hardvernél), illetve az annak eléréséhez szükséges idő a lényeg, nem?
"ill. azokon a hardvereken sokkal kedvezobb lehet az eredmeny, ahol nagyobb a cache."
Na jó, de ez is egy olyan dolog, hogy oké, nagyobb a cache, de nem véletlenül pakolták oda a plusz tranyókat. Most, ha az egyik gyártó CPU-jában teszem azt kétszer akkora teljesítményű az FPU, akkor már ne is használjunk olyan bench-et, ami nagyon épít az FPU-ra? Ha valamelyik hardver elhasal, mert nem bírja a tempót valamelyik részegység, az nem a bench írójának hibája, hanem a gyártóé. Persze, ha nincs megfelelően optimalizálva az adott bench, az már más eset...
"Eleg osszetett kerdes ez..."
Amennyire belelátok így nagyon felületesen, valóban nagyon összetett. Igazából itt nem is lehet szerintem objektívnek lenni.
"es pont emiatt sem szerencses, ha egy hardvergyarto ad tippeket arra, hogy mikepp kellene benchmarkot tervezned, hiszen sosem tudhatod, melyik javaslat mogott van a gyarto önös erdeke, es melyik olyan javaslat, ami valoban objektiv jotanacs."
Azt hiszem értem a problémát és persze amikor a gyártó ad tippet, amögött minden bizonnyal az a szándék van, hogy az ő termékén jó gyors legyen a bench. Igazából az lehet itt a nehéz, hogy, amint mondod is, simán ki lehet hegyezni egy bench-ben elvégzendő feladatot, vagy akár csak annak bizonyos "végrehajtási paramétereit" egy adott architektúrára. És itt lép be az, hogy ugyanezt a feladatot más paraméterezéssel más architektúrák mennyire gyorsan lennének képesek végrehajtani, illetve, ha már maga a feladat is kifejezetten az adott architektúrához van szabatva a gyártó által, akkor ennek a konkrét feladatnak mekkora gyakorlati jelentősége lenne a bench-en kívül? Az előbbi nyilván jócskán adna plusz melót a fejlesztőnek, az utóbbi meg szerintem nagyon szubjektív dolog...
De lehet, hogy totál rosszul látom, sajna nem nagyon értek a programozáshoz.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
"
Ergo vagy mindegyiket utalni kellene, vagyik mindegyiket egyforman szeretni. Nincs ertelme kivalasztani egyiket vagy masikat -- de persze megertem a kognitiv disszonancia erejét is 
Új hozzászólás Aktív témák
Hirdetés
ph A vállalat jól halad a 14 nm-es LPE node bevezetésével, amelyre akad jelentkező is.
- Akció! MSI Radeon RX 480 8GB GAMING X - Eladó! 29.990.-
- Honda Accord - 2009/04. havi - 2.2 dízel - 150LE magyarországi - 265 ezer km, 2025/02.-ig műszaki
- SAMEBIKE MY275 Elektromos Kerékpár 27,5 500W 625Wh
- Új HP VICTUS Gamer Tervező Laptop 16,1" -35% Bivaly i5-11400H 6Mag 16GB/512GB RTX 3060 6GB FHD 144Hz
- Eladó egy Samsung Odyssey G5 32-es curved 1440p 144hz Gaming monitor!
- Hogwarts Legacy PS5
- HP ProDesk 600 G2 SFF PC, 6. generációs i3 CPU, 120 GB ÚJ SSD, 8 GB DDR4 RAM, Jogtiszta Windows 10
- Fx-8320 Félkofig 32gb ram Asrock 970m pro 3
- Keychron Q2 ANSI Knob, navy blue + switch + keycapok
- Bomba ár! Dell Latitude 5501 - i7-9850H I 32GB I 512SSD I Nvidia I 15,6" FHD Touch I Cam I W11 I Gar
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Ozeki Kft
Város: Debrecen