Új hozzászólás Aktív témák
-
#58
Oliverda
félisten
Balala2007
#57
Oliverda
félisten
válasz
Balala2007
#57
üzenetére
Ugyan kissé OFF, de arról esetleg nem tudsz listát, hogy milyen alkalmazások használják az AVX-et, és isten ne adja az AVX2-t?
Az AIDA tudom, hogy használja őket.
-
#57
Balala2007
tag
Balala2007
tag
Publikusak a Skylake/Knights Landing uj utasitasainak a reszletei: AVX512
-
#56
dezz
nagyúr
Mindreader
#55
dezz
nagyúr
válasz
Mindreader
#55
üzenetére
Végülis jobb is, ha nem ugyanabból a forrásból lesz FMA3 vagy 4 kód, linker paraméter alapján, mert akkor nem lehetne egy forrásban mindkettő. Viszont az nem lenne rossz, ha forrási fordítási parancsként lehetne adott kódrészt egyikre vagy másikra fordítani. De még ez sem létszükséglet, nem sokból áll átírni egyikről a másikra.
-
#55
Mindreader
tag
dezz
#53
Mindreader
tag
De akkor talán az MS sem kifejezetten FMA4-et emlegetne hanem csak simán FMA Intrinsics-eket. Mellesleg az _mm_nmacc_ps esetében a dokumentáció világosan kimondja: Generates the FMA4 XMM instruction vfnmaddps to perform a single-round floating-point negative multiply-add of its sources.
Ilyen utasítás viszont nem létezik FMA3-ban, ott ezek vannak: VFNMADD132PS, VFNMADD213PS, VFNMADD231PS.
Értem hogy mit mondasz, hogy a fordító megtudná tenni, ennek ellenére nekem most nem tűnik úgy hogy a fordítóra akarnák bízni hogy FMA3-ra vagy 4-re optimalizáljon. Helyette neked magadnak kell mindkét utasításkészletre megírni a kódodat ha akarod, és neked kell lekezelni azt is hogy a CPU lehetőségeinek függvényében melyik megoldást futtatod/futtathatod. A compiler nem valószínű hogy ilyen ellenőrző rutinokat fog neked a kódhoz fordítani.
OpenCL-ben viszont valószínűleg simán megcsinálhatják amit mondasz, az pont erre van kihegyezve. Azt viszont nem tudom hogy vajon lesznek-e utasítás intrinsics-ek vagy a pure C kódot próbálja majd a fordító FMA-ra vagy más SIMD utasításokra fordítani.
-
#53
dezz
nagyúr
Mindreader
#52
dezz
nagyúr
válasz
Mindreader
#52
üzenetére
Nos, itt van pl. az _mm_macc_ps:
__m128 _mm_macc_ps (
__m128 src1,
__m128 src2,
__m128 src3
);Mivel nem adhatod meg konkrétan, mely regiszterekről is van szó (csak azt, hogy lehetőleg regiszterek legyenek), ezt a fordító le tudná fordítani FMA3-ra és 4-re is. A fordító dolga kiválasztani a konkrét regisztereket és kezelni az esetlegesen szükségessé váló cseréket, stb.
-
#52
Mindreader
tag
dezz
#51
Mindreader
tag
Ennél közvetlenül regiszterekkel is dolgozhatsz?
Ez úgy van hogy az __m128x illetve __m256x típus közvetlenül map-elve van az xmm regiszterekre, szóval elméletileg igen, de konkrétan nem nevezheted meg a regisztert. Mindenesetre amíg kisebb vagy egyenlő a változóid száma a regiszterek számával, addig egy változó egy regiszternek fogható fel.
Register Shortage
When using temporary __m128 or __m256 variables for single instruction multiple data (SIMD) programming, the optimizing compiler usually does a good job of keeping these as registers. Even with optimizations, the compiler may still sometimes generate assembly code that copies temporary values to the stack.Szerintem ez a C-szintű megfelelő egyforma FMA3 és FMA4 esetén is
Hát én ezt nem nagyon hiszem. Akkor az MS miért tette bele a VS2010 SP1-be szépen külön az FMA4 intrinsics-eket? FMA4 Intrinsics Added for Visual Studio 2010 SP1
-
#51
dezz
nagyúr
Mindreader
#42
dezz
nagyúr
válasz
Mindreader
#42
üzenetére
Te figyu, ez annyira nyílvánvaló, hogy ha már Intel oldalról nem elérhető a dolog, akkor amennyire lehet, az AMD vitorlájából is ki akarták fogni a szelet, hogy csak az nem látja, aki nem akarja... Az Intel mindig is így játszott. Amikor az AMD megcsinálta az x86-64-et (azaz AMD64-et), arról sem akartak hallani, hanem továbbra is azt a desktopra teljesen alkalmatlan Itaniumot erőltették, aztán amikor látták, hogy nagyon nem megy, 1-2 éves késéssel inkább kidolgozták a saját, AMD-énél primitívebb 64-bites kiterjesztésüket. Még szerencse, hogy a MS beintett... (A legszánalmasabb az egészben, hogy amikor végül kénytelenek voltak átvenni az AMD64-et, jó ideig olyan néven futtatták, mintha csak a memóriakezelés lett volna kibővítve 64 bitre: EM64T, Extended Memory 64 technology...)
"vagy használtad az utasítások intrinsic megfelelőjét ami majdnem ugyanaz mintha asm-ben kódoltad volna."
Ennél közvetlenül regiszterekkel is dolgozhatsz? Gondolom, nem, az túl nehézkes lenne. Szerintem ez a C-szintű megfelelő egyforma FMA3 és FMA4 esetén is, a többit (regiszterek kezelése, FMA3 esetén a felülírandó regiszter tartalmának másik regiszterbe másolása, stb.) a fordító végzi.
Az persze lehet, hogy itt elsősorban az OpenCL-re fognak építeni.
(#44): Szuperszámítógép, HPC =/= szerver. Az utóbbinál ritkán számít a lebegőpontos teljesítmény.
(#47) Mozsa: Teljesen kifordítva látod a dolgokat (szokás szerint). Az általános az, hogy az Intel jutalmaz... Telik rá... Ebben az Intel dominálta környezetben aztán a semleges vélemény is AMD-barátnak tűnik...
-
#50
Oliverda
félisten
Mindreader
#49
Oliverda
félisten
válasz
Mindreader
#49
üzenetére
Na de az FMA4 eredetileg Intel fejlesztés.
Másfelől mint feljebb írtam, 2013-ig minden bizonnyal csak FMA4-et támogató CPU-t lehet kapni.
-
#49
Mindreader
tag
Oliverda
#48
Mindreader
tag
Hát az Inteltől nem sűrűn láttunk olyat hogy AMD-s kiterjesztéseket implementálnának a saját rendszerükre, az x86-64 -en kívül nem is nagyon tudok mást amit az Intel vett át az AMD-től és nem fordítva. Ja de, volt még valami: az NX bit. De legyen úgy, a minél nagyobb fokú kompatibilitás az csak jó lehet.
-
#48
Oliverda
félisten
Mindreader
#46
Oliverda
félisten
válasz
Mindreader
#46
üzenetére
Igen, ezek biztosan nem fél vagy egy év alatt fognak kiderülni.
Még egy érdekes csavar lehetne, ha esetleg később a Haswell utáni Broadwell behozná az FMA4-et. Mondjuk a Haswell környékére már az AMD-nek is meglehet az FMA3 (is).
Mindenesetre 2013-ig annak nem lesz túl sok választási lehető aki esetleg FMA-t szeretne használni.
-
#45
Oliverda
félisten
Mindreader
#44
Oliverda
félisten
válasz
Mindreader
#44
üzenetére
Majd az idő megválaszolja ezt a kérdést. Mindenesetre a Cray már épít erre szuperszámítógépét. A 3DNow-ra alapozva nem hiszem, hogy sok ilyen masina készült volna.
-
#43
Oliverda
félisten
Mindreader
#42
Oliverda
félisten
válasz
Mindreader
#42
üzenetére
Nem arra a nyilvánvaló párhuzamra gondoltam, hogy a 3DNow-hoz hasonlóan az FMA4-et is csak az AMD fogja támogatni, hanem a két utasításkészlet közötti alapvető különbségre, valamint arra a nem elhanyagolható tényre, hogy a 3DNow idejében az AMD még nem igazán volt jelen a szerver piacon. Ennek köszönhetően alapvetően nem is ilyen felhasználásra készült a 3DNow.
"3DNow! was developed at a time when 3D graphics were becoming mainstream in PC multimedia and gaming software. Realtime display of 3D graphics depended heavily on the host CPU's floating-point unit (FPU) to perform floating-point calculations, a task in which AMD's K6 processor was easily outperformed by its competitor, the Intel Pentium-II."
-
#42
Mindreader
tag
Mindreader
tag
Nem hiszem hogy túl erős lenne a párhuzam. FMA4 várhatóan ugyanúgy csak az AMD-nél lesz mint ahogyan a 3DNow volt. FMA3 viszont lesz mindkettőnél. 3DNow is egy király ötletnek indult, kezdetben volt is némi támogatottsága, de aztán a kutya nem használta, mert minek amikor csak az AMD-n fog menni, lásd el is vetette az AMD. Nem értem hogy mivel lenne más a helyzet FMA4 esetében.
Hát hogy pontosan mi oka volt annak hogy az Intel az FMA3-at választotta azt nem tudom, egyszerűen csak egyik verzió sem szimpatikus nekem.
Nem akkor kezdtek rajta dolgozni, amikor nyilvánosságra hozták.
Mindegy, szerintem az architektúra egységesítése érdekében megért volna némi csúszást az első chip-ek megjelenítése. Bár ezt ők nyilván nem így gondolták.Fordítói támogatás márpedig lesz
Nos ezt igazából nem kétlem, és ezzel nem is akarok vitatkozni, de nagyon kíváncsi vagyok hogy ezt hogyan is tervezik megoldani. Eddig ha bármilyen SIMD utasításkészletet akartál használni vagy szépen beszúrtál egy __asm blokkot és megírtad assemblyben, vagy használtad az utasítások intrinsic megfelelőjét ami majdnem ugyanaz mintha asm-ben kódoltad volna. Persze ha kizárólag OpenCL-ben gondolkozunk mindjárt egyszerűbb a helyzet. -
#41
dezz
nagyúr
Mindreader
#38
dezz
nagyúr
válasz
Mindreader
#38
üzenetére
Ja, és csak 5 hónap.
-
#40
dezz
nagyúr
Mindreader
#38
dezz
nagyúr
válasz
Mindreader
#38
üzenetére
A #28-asban te magad írtad, hogy szerinted nem volt rá technikai okuk... Nos, akkor mi marad? Más szóval: igen, te vagy túlzottan jóhiszemű...
"A két spec release date között eltelt 8 hónap"
Nem akkor kezdtek rajta dolgozni, amikor nyilvánosságra hozták.
"Mivel az AMD támogatni fogja az FMA3-at viszont az Intel az FMA4-et valószínűleg nem, így csak idő kérdése lesz hogy az FMA4 a 3DNow sorsára jusson."
Az közel sem biztos, mivel:
1. A magas szintű nyelvekben nem FMA3 vagy FMA4 támogatás van (kiterjesztéssel), hanem simán FMA, és az, hogy a fordító mire fordítja, részletkérdés.
2. Annyi, hogy egy FMA4 code-path-t is tartalmazó program valamivel gyorsabb lesz AMD procikon, mint az FMA3-as.
3. Fordítói támogatás márpedig lesz (ha nem is az Intel részéről), mivel az FMA-képesség az egy egyik fő ok, hogy a Cray a Bulldozert válaszototta új, listavezetőnek szánt szuperszámítógépében -- szintén FMA-képes Nvidia GPU-k kíséretében. -
#39
Oliverda
félisten
Mindreader
#38
Oliverda
félisten
válasz
Mindreader
#38
üzenetére
Azért az FMA4 és a 3DNow között talán kicsit erős párhuzamot vonni.
BTW, így bő fél évvel az AVX-et támogató SB procik rajta után is még nagyítóval kell keresni hozzá az olyan alkalmazást, ami képes kihasználni az utasításkészletet.
-
#38
Mindreader
tag
Oliverda
#37
Mindreader
tag
Világos, az AMD már túlzottan benne volt a fejlesztésben ahhoz hogy implementálja a változásokat, bár én továbbra sem feltételezném hogy az Intel direkt kiszúrásból vagy üzleti húzásból változtatott a terveken, persze lehet hogy csak én vagyok túl jóhiszemű.
A két spec release date között eltelt 8 hónap és az AMD már nem akarta felrúgni a saját terveit, pedig még így is az ő processzoraiba jelenhetett volna meg hamarabb az új technológia, így viszont lett két egymással teljesen inkompatibilis kiterjesztés. Mivel az AMD támogatni fogja az FMA3-at viszont az Intel az FMA4-et valószínűleg nem, így csak idő kérdése lesz hogy az FMA4 a 3DNow sorsára jusson.Mellesleg a linkelt hírről nem hallottam, vagyis nem emlékszem rá, kicsit régi már, bár ez azt hiszem irreleváns.
-
#37
Oliverda
félisten
Mindreader
#36
Oliverda
félisten
válasz
Mindreader
#36
üzenetére
-
#36
Mindreader
tag
dezz
#34
Mindreader
tag
Nem hinném hogy rossz lenne:
August 2007: AMD announces the SSE5 instruction set, which includes 3-operand fused multiply-add instructions. A new coding scheme (DREX) is introduced for allowing instructions to have three operands.
April 2008: Intel announces their AVX and FMA instruction sets, including 4-operand fused multiply-add instructions. The coding of these instructions uses the new VEX coding scheme which is more flexible than AMD's DREX scheme.
December 2008: Intel changes the specification for their FMA instructions from 4-operand to 3-operand instructions. The VEX coding scheme is still used.
May 2009: AMD changes the specification of their FMA instructions from the 3-operand DREX form to the 4-operand VEX form, compatible with the April 2008 Intel specification rather than the December 2008 Intel specification.
Forrás: [http://en.wikipedia.org/wiki/FMA3_instruction_set]
Az Intel kivár
Nem értem hogy miért feltételezed az Intel rosszindulatúságát a témában. -
Abu85
HÁZIGAZDA
Teljesen érthető a szimpátia, csak nem értjük, hogy mire. Mi mit nyerünk a C++ AMP-vel? Az MS bármikor odaszögezheti a Windowshoz, és az sem jó, hogy hivatalosan az AMD felel a többi oprendszeren történő támogatásért. Ez az MS-nek és az AMD-nek biztos jó, de nekünk miért lenne az?
-
#34
dezz
nagyúr
Mindreader
#28
dezz
nagyúr
válasz
Mindreader
#28
üzenetére
Rossz a sorrent és pontatlan a felsorolás!
- Az AMD kidolgozza az SSE5-öt, aminek része egyfajta FMA3 is.
- Az Intel válasza: AVX, FMA4, VEX prefix.
- AMD átveszi az AVX-et; az eredeti SSE5-öt pedig átalakítja, VEX-kompatibilissé teszi és szétbontja XOP-ra, FMA4-re és CVT16-ra, és mindezt elkezdi implementálni a Bulldozerben.
- Az Intel kivár, majd amikor már az AMD nem tud változtatni a terveken, az Intel bejelenti, hogy az FMA4 helyett (mégis) az FMA3-at fogja támogatni. (Szóval, azért sem az FMA4-et...)
- Az AMD bejelenti, hogy a köv. gen. Bulldozerben az FMA3-at is támogatják. -
#33
Mindreader
tag
LordX
#32
Mindreader
tag
Szóval ha veszel egy x86-64-es procit, akkor sem 64 bites a regiszterek mérete, sem nem 64 bites a címzés. Csak az EIP 64 bites.
Maga az x86 jelenleg 64bites kiterjesztés támogat. Tehát az architektúra 64 bites,a fizikai kialakítás és a kiterjesztések nyilván ettől eltérhetnek és el is térnek.
Akkor nyilván a REX prefixet is tök feleslegesen találták ki. Dehogy csak az IP 64 bites. Már hogyne lennének 64 bitesek a regiszterek? Szinte minden 64 bites ami nem SIMD illetve FPU utasítás: 64 bitesek a GP regiszterek mind a 16 darab, 64 bites a címterület (megtaláltad az egyetlen példát, a 64bites címzést ahol nem), 64 bitesek a control és debug regiszterek, az IDTR és GDTR -ben is a báziscím szintén 64 bites,és 64 bites a FLAGS is, az FPU instruction és data pointere, hogy a call gate-ekről meg ilyesmiről már ne is beszéljek. -
#32
LordX
veterán
Mindreader
#30
LordX
veterán
válasz
Mindreader
#30
üzenetére
Az SSE2 regiszterei (az XMM regiszterek) 128 bitesek, az AVX regiszterei (az YMM regiszterek - marha fantáziadús név, nem?) 256 bitesek.
A memóriacímzés a 64 bitből esetében a felső 16 bit ignorálva vagyon, tehát csak 48 bites (4 TLB szinttel egyenként 9 bit a lapcím, az alsó 12 bit meg a lapon belüli cím - összesen 4*9+12=48 bit).
Szóval ha veszel egy x86-64-es procit, akkor sem 64 bites a regiszterek mérete, sem nem 64 bites a címzés. Csak az EIP 64 bites.
-
#30
Mindreader
tag
LordX
#29
Mindreader
tag
Az x86-os arhitektúra jelenleg 64bites (AMD x86-64, Intel 64), 64 bitesek a GP regiszterek, a EIP, és a 64 bites a címzés is. Attól hogy vannak 128/256 bites SIMD utasítások attól még az arhitektúra 64 bites.
Mivel már vannak az Intelnél is 4 operandusú AVX utasítások, így nyilván ezeknél már megoldották a dolgot. Nyilván van oka amiért a 3 operandusú megoldás mellett döntöttek, de én személy szerint nem tartom valószínűnek hogy a felépítés bonyolultsága lenne az oka, főleg hogy az AMD később döntött az FMA4 mellett és sokkal hamarabb lett vele kész.
-
#29
LordX
veterán
Mindreader
#28
LordX
veterán
válasz
Mindreader
#28
üzenetére
Az MMX, SSEx és az AVX mi, ha nem 128 bites / 256 bites kiterjesztés?
Az egy dolog, hogy a VEX kódolással lekódolható a FMA4 utasítás, más dolog azt implementálni a dekódolóban, a regiszterfájl vezérlőjében, a ROB-ban, meg mittudomén mi mindent érinthet még.
-
#28
Mindreader
tag
Mindreader
tag
Egyre bonyolultabb lesz az egész x86 architektúra, már megélt egy 16-ról 32 bitre bővítést, aztán egy 32-ről 64bitre bővítést, gondolom lesz még 64-ről 128-ra is, a sok plusz utasításkészletről nem is beszélve plusz még az AMD saját megoldásai. Már így is nagyon robusztus, kíváncsi leszek meddig lehet ezt majd még fokozni.
Egyébként érdekes ami FMA témában ment:
- Az AMD kitalálja az SSE5-öt
- Az Intel kitalálja az AVX-et, FMA4, VEX prefix
- Intel meggondolja magát FMA4 helyett FMA3
- AMD követi az Intelt, elvetik az SSE5-öt, átveszik az Intel eredeti (nem ám a módosított) FMA4-es terveitAz eredmény: Semmilyen módon nem kompatibilis FMA megoldások a két cég részéről.
Például VFMADDPD utasítás:
Intel:
VFMADD132PD ymm0,ymm1,ymm2/m256
[ymm0 = (ymm0 * ymm2/m256 +ymm1)]
VFMADD213PD ymm0,ymm1,ymm2/m256
[ymm0 = (ymm1 * ymm0 + ymm2/m256)]
VFMADD231PD ymm0,ymm1,ymm2/m256
[ymm0 = (ymm1 * ymm2/m256 + ymm0)]AMD:
VFMADDPD ymm1,ymm2,ymm3/mem256,ymm4
[ymm1 = (ymm2 * ymm3/mem256 + ymm4)]
VFMADDPD ymm1,ymm2,ymm3,ymm4/mem256
[ymm1 = (ymm2 * ymm3 + ymm3/mem256)]Az Intel nem indokolta meg, hogy miért döntöttek az FMA3 mellett, de valószínű, hogy a hardveres implementálás volt az oka, ugyanis az FMA4 támogatását sokkal nehezebb beépíteni.
A VEX prefix segítségével elméletileg 5 operandusú utasítások is létrehozhatók, na most mivel az Intelnek már léteznek 4 operandusú AVX-es utasításai:
VBLENDVPD ymm1, ymm2, ymm3/m256, ymm4
VBLENDVPS ymm1, ymm2, ymm3/m256, ymm4
VPBLENDVB xmm1, xmm2, xmm3/m128, xmm4így nem teljesen értem hogy mitől lett volna olyan nehéz a négy operandusú megoldást alkalmazni FMA esetében is.
-
hohoo
senior tag
Az ms mindig is az volt, intel csak néha
Ezt kéne a hatóságoknak felügyelni, hogy ne szabványtalaníthassák a szabványt, meg ne lehessen ilyen direkt inkompatibilitásra gyúró dolgokat csinálni, ahelyett hogy a szabadalmi trollokat babusgatják...
#21: aztán megint ott lesz a jó kis intel c fordító ami nem használ ezt meg azt ha amd procin fut a kód
-
dezz
nagyúr
Cikk: "Az FMA4 az összes operandushoz külön regisztert használhat, míg azt FMA3 esetén az eredményt a három operandushoz használt regiszterek közül az egyikbe kell írni."
Már a múltkor is szóltam, hogy ez nem valami jó megfogalmazás (úgy hangzik, mintha a programnak kellene odaírnia). Jobb lenne így: az eredmény a három operandushoz használt regiszterek közül az egyikbe kerül (v. egyikébe kerül).
(#3) FireKeeper: Szerinted mennyien fejlesztenek manapság ASM-ben? A magasabb szintű nyelvekben simán FMA támogatás van, nem FMA3 vagy FMA4. Az már részletkérdés, hogy a compilerek melyikre fordítják. Egyszerűen AMD-n valamivel gyorsabb lesz, ha FMA3 low-level kód helyett FMA4 fut.
-
Abu85
HÁZIGAZDA
Súlyosan félreérted a C++ AMP-t, ugyanolyan driver kell hozzá, mint az OpenCL-hez. Szerinted a gyártók fogják tesztelni egymás hardvereire?
Az MS megoldása semmiben nem különbözik az OpenCL-től, csupán egy alternatíva kvázi ugyanazokkal a lehetőségekkel és funkciókkal. Ha hibátlan heterogén kihasználtságot akarsz, akkor platformban kell gondolkodnod. Esetlegesen követeld a konzumer programok fejlesztőitől, hogy kerneleket (a C++ AMP-ben nem tudom ennek mi lesz a neve, de ugyanarról van szó) párhuzamosítsák több OpenCL eszközre, mert így mehet a gyártók mixelése, és te gondolom szívesen teszteled két eltérő funkcionalitású driverrel a működést, ha már a gyártók/fejlesztők nem teszik meg. -
Abu85
HÁZIGAZDA
Aki magasabb szinten kódol, az úgyis a fordítóra bízza a dolgot. Azoknál meg kell oldani az FMA4 támogatást most, mivel pár hét és jön rá Bulldozer, míg később az FMA3 is bekerülhet. A támogatás ebből a szempontból biztosított. Persze ahogy az új utasításkészleteknél nem lesz azonnal konzumer program rá, előbb be kell kerülnie a technikának a legtöbb gépbe.
A szerverpiac nyilván más, ott célirányosabb a dolog, de az gondolom nem érdekel annyira. -
#15
Bici
félisten
hugo chávez
#13
válasz
hugo chávez
#13
üzenetére
Köszi a választ!
(#12) UnSkilleD: Neked is.
Ezek szerint rosszul tudtam.
-
#13
hugo chávez
aktív tag
hugo chávez
aktív tag
Abu, ezt kár, hogy nem írtad bele, pedig az Ivy-k szempontjából (amik ugye már év végén-jövő év elején kint lesznek) szerintem elég lényeges: "These build upon the instructions coming in Intel® microarchitecture code name Ivy Bridge, including the digital random number generator, half-float (float16) accelerators, and extend the Intel® Advanced Vector extensions (Intel® AVX) that launched in 2011." - Haswell New Instruction Descriptions Now Available!
Tudomásom szerint ugyanis a VIA procijain kívül jelenleg nincs olyan x86-os CPU, amiben van véletlenszám generátor.
(#7) Bici:
FMA3 lesz.
(#10) Bici:
A Sandy nem tud FMA-t, csak AVX-et, ami lényegében egy új SIMD utasításkészletet és a lebegőpontos SIMD egységek regisztereinek 128-ról 256 bitesre szélesítését jelenti.
-
#11
nuke7
veterán
FireKeeper
#3
nuke7
veterán
válasz
FireKeeper
#3
üzenetére
+1...
sokat számít a jó kezdés.. -
#3
FireKeeper
nagyúr
Mozsa
#1
FireKeeper
nagyúr
muszáj volt meglépniük, hiszen hiába kényelmesebb az FMA4, ha egy fejlesztő azt mondja, ő akkor is FMA3-mal csinálja meg, mert akkor az inteleken is jól fog futni, akkor az AMD feld*ghatja magának a fejlettebb FMA4 megoldását, Intelen lesz az adott program gyorsabb (legalábbis nekem ez jött le). ez történik, ha egy cégnek akkor a piaci részesedése, hogy nyugodt szívvel bemutathat a konkurenciának és megszívathatja a programozókat, csak hogy neki egyszerűbb dolga legyen.
A két spec release date között eltelt 8 hónap és az AMD már nem akarta felrúgni a saját terveit, pedig még így is az ő processzoraiba jelenhetett volna meg hamarabb az új technológia, így viszont lett két egymással teljesen inkompatibilis kiterjesztés. Mivel az AMD támogatni fogja az FMA3-at viszont az Intel az FMA4-et valószínűleg nem, így csak idő kérdése lesz hogy az FMA4 a 3DNow sorsára jusson.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- Thrustmaster TMX Force Feedback Kormány- és Pedálkészlet
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- ThinkPad T14s Gen 2 i5-1135G7 16GB 512GB FHD 1 év garancia
- BESZÁMÍTÁS! ASRock Phantom Gaming RX 7900XTX 24GB garanciával hibátlan működéssel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest