- Magisk
- Prohardver app (nem hivatalos)
- Yettel topik
- Garmin Fenix 7 és 7S - profi sport megszokásból
- Itthon is kapható lesz a kerámia Xiaomi Band 10
- QWERTY billentyűzet és másodlagos kijelző is lesz a Titan 2-ben
- Motorola Edge 30 Neo - wake up, Jr...
- Samsung Galaxy Watch7 - kötelező kör
- iPhone topik
- Mobil flották
Új hozzászólás Aktív témák
-
P.H.
senior tag
Azért, hogy ne legyen ilyen töredezett a társalgás, legyen egyben az egész.
8.1.1 bekezdés
Az első a bekezdés igazából nem közöl érdemleges információt, csak a sorok között. És kizárólag a tárolási műveletekről szól (MOV mem,reg FST(P) mem FIST(P) mem MOVQ mem,mmreg). A 486-os esetén minden kiírt byte bitjei egyszerre jelennek meg a kiírva, továbbá minden 16 bites adaté, ha az páros memóriacímre lett kiírva és minden 32 bites adaté, ha az 4-gyel osztható címre; Pentium 1-nél továbbá minden 64 bites (=MMX, itt jelent meg) adaté, ha az 8-cal osztható címre.
Ehhez képest a P6 family (Pentium Pro, Pentium 2 és Pentium III) esetén ez lecserélődik arra, hogy bármely 2-, 4- és 8-byte méretű adat bitjei egyszerre jelennek meg kiírva, ha az befér a - az akkor még 32 byte-os - befoglaló cache line-ba, azon belül bárhova (pl. 0x07 címre) írva. Ez a csere a Pentium Pro-val jelent meg, amelyet az Intel az első valóban több CPU-s rendszerekre szánt (aztán a Pentium II sorozatban megjelent a Xeon márkanév), ennyit arról, hogy olyasmivel kell kompatibilisnek lenni, ami még messze nem volt több CPU-s rendszer; technikailag több egymagos CPU és egy többmagos CPU kezelése nem sokban különbözik.
- azaz ha egy másik mag/CPU ráolvas a változóra, vagy a régi, vagy az új értéket fogja látni, fals értéket nem; és ehhez nem kell külön szinkronizálás
- magon belül is fontos ez, mert ez teszi lehetővé a store-to-load-forwarding-ot is a magon belül (azaz ha ugyanaz a mag/CPU olvassa vissza a változót), mert a Pentium Pro az Intel első OoO felépítése.Ez a szabály azt mondja ki, hogy ha pl. 32 bites single precision lebegőpontos változóban pl. 1.1x2^2 érték van jelenleg és kiírunk oda mondjuk 1.5x2^4 értéket, akkor nem lesz olyan órajel/pillanat, amelyben a változó köztes adatot tartalmazna olyan értelemben, hogy pár bit - monjuk a kitevő byte-ja - már megérkezett, a többi még nem, pl. 1.1x2^4 érték lenne a változóban.
Persze ettől eltérően ki lehetne írni nem egyben is, csak az még lassabb is lenne. Ez amúgy nem jelentős kitétel, mert a fordítóprogramok már több évtizede gondoskodnak arról, hogy a változók jól legyenek align-olva akár stack-ben vannak, akár globális változók vagy foglalt (malloc) memóriában vannak: pl. egy byte méretű változónak pl. 4 byte-ot foglalnak le, ha utána közvetlenül uint van, vagy az említett extended precision 10 byte-os számnak 16 byte-ot, a rendszer által adott lefoglalt memória pedig NT 3.1 óta 4-byte aligned, Windows Vista óta pedig 32-es címre van igazítva.Továbbá megfigyelhető, hogy a szabály nem vonatkozik (a 10 byte-os extended precision mellett) a 128 bites (=SSE) adatokra, pedig az a Pentium III-ban jelent meg. Ennek két praktikus oka van, amit nem itt kell keresni:
- egyrészt ekkoriban (a Pentium III-ban, a Pentium M-ben és a Pentium 4-ben is) 64 bites végrehajtókon hajtották végre a 128 bites utasításokat, így a tárolásokat is, így garantálni és garantáltatni sem lehetett, hogy a 128 bites adat teljes egésze egyszerre jelenik meg a külvilág számára
- másrészt az SSE utasítások, legyenek azok load, load-op vagy store jellegűek (load-op-store nincs SSE-ben, sem MMX-ben, sem AVX-ben, legfejlebb non-temporal, de az más téma), per definition megkövetelik, hogy a megadott memóriacím 16-byte aligned legyen. Ellenkező esetben le se futnak, #invalid address (a.k.a. "runtime error 216" vagy "access violation error..." hibát dobnak; erről a programozónak kell gondoskodni (ez nem nehéz, mert a virtuális és a lefordított fizikai memóriacím 4 KB-os lapnál a 12. bittól felfele különbözik csak, tehát programíráskor látható az igazítás).Az SSE utasítások a Core 2-ben kaptak natív 128 bites végrehajtókat és hamarosan (vagy a Westmere-ben, vagy a Nehalem-ben; AMD-nél a K10-ben) eltörölték a 16 byte-aligned memóriacím követelményt, a 128 bites adatokra vonatkozó kitétel mégse jelent meg a szabályban ("elfogyott"). Ahogy a 256 bites AVX sem. Pedig kaphatott volna. Hogy bonyolultabb legyen a kép. Vagy elavultabb?
A tárolás időigénye a fentiek miatt attól függ, hogy hol van az a cache line, amire tárolunk, mivel a tárolás maga csakis az L1-be történhet (hacsak nem non-temporal, akkor meg nem függ attól, hogy van), ezért az L1-be kell hozni az adott cache line-t. Ha legrosszabb esetben RAM-ban van és nincs meg egyetlen közelebbi cache szinten se, akkor sok-sok órajelbe kerülhet. Szerencsére Intel-nél Core2 óta, AMD-nél K10 óta out-of-order a tárolás is (gondolom a store queue, teljes nevén Store Queue for L1-miss Stores szólíthatjuk, mint CPU építőelem ismerős) és mérete szokás szerint nő generációról generációra, közben az utasításvégrehajtás kedvére folytatóthat. (persze ha betelik a retirement window, azaz a ROB közben, akkor van baj, dehát azért optimalizálunk, hogy az L1-hit 95% felett legyen, bár a nagy részben megoldják a hardware prefetch-erek.
A második bekezdés már igenis hordoz lényegi információt. A fordítók készítői számára.
Mégpedig azt, hogy a tárolás nem fér fele 1 cache line-ba, akkor a fenti nem igaz, ez az eset két db tárolási műveletként van implementálva, fele ide, fele oda, a rendszer semmilyen törekvést nem tesz arra, hogy kívülről egyszerre lehessen látni a teljes adatot. Emiatt a programozónak kell gondoskodnia arról, hogy ha az adott adatra ráolvas másik mag/CPU, egy - mostmár 64 byte-os - cache-egységen belül legyen, de mint említettem, a fordítóprogramok ezt elvégzik. Persze szorgos munkával meg lehet ezt kerülni, szorosan típusos nyelvekben mondjuk nem, C-ben hosszadalmas és jól látható pointer+typecasting-gel, vagy ASM-ben pl. megnöveled a stack pointer-t eggyel, de ugye ez mind proaktív dolog.
Amúgy a Bulldozer esetében az AMD valószínűleg pont ezt tolta túl és lett 20+ órajel egy 256 bites store, mert a 256 bites AVX tárolásokra egy modulban egyetlen 128 bites FSTORE tároló végrehajtási egysége van a megosztott FPU-ban, viszont a write-through L1D cache miatt az L2-be kell átvinni az adatot és a Write Coleascing Cache-ben megpróbálták egyesíteni a két felet. Aztán a Kaveri-vel vissza is léptek ettől, mert a szabály ezt nem írja elő; más kérdés, hogy az Intel az AVX-et tudó processzorait eleve 256 bites tárolóporttal szerelte fel.
8.1.2 bekezdés
Tehát a fentiek a store illetve a másik mag/CPU által kiadott load vagy load-op kapcsolatát írják le. Van még egy eset: van egy változó, legyen VAR, ami kezdetben 0; a feladatot elosztottuk két szálra, amelyek növelik ennek értékét (pl. számolnak valamit). Ha mindkét szál lefuttatja az ADD [VAR],1 utasítást mint load-op-store műveletet, akkor nem garantált, hogy nem fog előfordulni, hogy - mivel az újabb CPU belül több mikroműveletre bontotta az utasítást, régi in-order CPU pedig a futószalag elején beolvas, közepén módosít, a végén ér), hogy beolvasva az érték 0, növelve 1, kiírva 1 lesz: azaz 2 helyett 1 lesz az eredmény.
Ezen az utasítások elé lehet kitenni a LOCK prefix-et, azaz LOCK ADD [VAR],1 lesz írva mindkét szál kódjába.
Csak ezen load-op-store utasítások elé, store vagy load-op elé nem lehet, különben jön az #UD, és csak a felsoroltak elé, tehát nincs shift vagy ROR forgatás.A rendszer garantálja, hogy ha azonos órajelben indul el mindkét utasítás, akkor is lesz egy sorrend, amelyben az egyik beolvassa-megnöveli-kiírja (az első snoopable szintre, L1 vagy Bulldozernél és Pentium 4-nél L2) az 1 értéket, majd ezt kapja meg a másik szál utasítása, növeli és kiírja a 2-t.
Amíg le nem fut az ilyen LOCK prefix-szel megjelölt utasítás, addig az adott mag/CPU nem dekódol több utasítást; ez az első magnál lehet gond, mert lehet, hogy neki kell (ha kell) beolvasni RAM-ból az adatot (load-op-store, tehát kell a forrásadat is), eredményét az L1-ből vagy L2-ből közvetlenül megkapja a másik mag/CPU. De hogy ne kelljen RAM-olvasás, van L3; vagy ha Broadwell-t veszel, akkor méretes L4 is.Az egyetlen utasítás, ami elé nem kell kiírni a LOCK-ot, az XCHG mem,reg, mert - ahogy a fejezet is említi -, a CPU automatikusan odagondolja.
Ezek által lehet kezelni a szinkronizációs változókat.
Meglehetősen nehéz kimérni egy memóriaoperandusú utasítás végrehajtását (meg amúgy életszerűtlen), ha az L1-hozzáférés időigényét nem számolod hozzá... De ha sűrűn módosítod a változót, megtalálod az L2-ban vagy az L3-ban (adj a kiírt órajelhez ~15 vagy ~25 órajelet Intel-nél); ha meg nem, akkor 600 órajel se tétel.
8.2.2 bekezdés
Ennek felelnek meg teljes egészében a leírtak. Hogy konkretizáljam:
- az LFENCE, MFENCE, SFENCE, MOVNTxx non-temporal utasítások, külön faj (a lényegük, hogy semmilyen konzisztenciát nem biztosítanak, a tárolt adat semelyik cache-ben nem jelenik meg, egy átmeneti pufferből azonnal a RAM-ba kerül, jelentősen gyorsabb így nagy mennyiségű adat kezelése, mintha cache-be tennék az eredményt, és a cache tartalma is megőrizhető. Az MOVNT-csoport ír, a FENCE-csoport puffert ürít).
- a CLFLUSH a Cache Line Flush to RAM, pl. ha laptáblát módosítasz (pár bitenként egyszerre, mint hozzáférési jogok, címrész) és végül globálisan láthatóvá akarod tenni.
- az I/O műveletek (IN és OUT egy megadott portra) ugyanúgy viselkednek, mint a LOCKED prefix-es utasítások, addig nem dekódol a CPU, amíg ez véget nem ért."Reads may be reordered with older writes to different locations but not with older writes to the same location.[I/]"
Ha ez nem így van bármely CPU-t, a teljes integritást veszélyezteti."Writes are not reordered with older reads."
Szintúgy."The only enhancements in the Pentium 4, Intel Xeon, and P6 family processors are "
"• Added support for speculative reads, while still adhering to the ordering principles above."
Ez tisztán hardware-es. Nagyrészt kiüti "Reads are not reordered with other reads." kitételt, látszólagos megfelelőséget biztosít neki; továbbá az előző pontot is spekulatívvá teszi, nem kell tudni előre, hogy a korábbi tárolás milyen címre történik; ha kiderül később, hogy azonosra, újraindítja a pipeline-t, mint egy sima branch misprediction-nál. Memory Disambiguation a neve."• Store-buffer forwarding, when a read passes a write to the same memory location."
Ezt említettem fejlebb, a load vagy load-op utasítás a store queue-ből veszi a kiírt adatot, nem az L1-ből.A képen látható bal "Writes are in order with respect to individual processes." és a jobb "Writes from all processors are not guaranteed to occur in a particular order." pedig magáért beszél.
-
LordX
veterán
Iiiiigen?
Mármint mi fogyott el Core 2-re, az unaligned 16/32/64 bites műveletek atomisága? Igen, de én ezt eddig meg se említettem, mert ma már irreleváns.
De már értem mi hiányzott, nem írtam le, hogy csak 64 bitig igaz a "atomi ha nem lép át cacheline-t" kitétel. Elnézést.
-
P.H.
senior tag
8.1.1 Guaranteed Atomic Operations
The Intel486 processor (and newer processors since) guarantees that the following basic memory operations will always be carried out atomically:
• Reading or writing a byte
• Reading or writing a word aligned on a 16-bit boundary
• Reading or writing a doubleword aligned on a 32-bit boundaryThe Pentium processor (and newer processors since) guarantees that the following additional memory operations will always be carried out atomically:
• Reading or writing a quadword aligned on a 64-bit boundary
• 16-bit accesses to uncached memory locations that fit within a 32-bit data busThe P6 family processors (and newer processors since) guarantee that the following additional memory operation will always be carried out atomically:
• Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache lineCore 2-re elfogyott.
Accesses to cacheable memory that are split across cache lines and page boundaries are not guaranteed to be atomic by the Intel Core 2 Duo, Intel® Atom™, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors. The Intel Core 2 Duo, Intel Atom, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, and P6 family processors provide bus control signals that permit external memory subsystems to make split accesses atomic; however, nonaligned data accesses will seriously impact the performance of the processor and should be avoided.
An x87 instruction or an SSE instructions that accesses data larger than a quadword may be implemented using multiple memory accesses. If such an instruction stores to memory (pl. az FTS(P) tword - azaz 80 bites extended precision tárolás - ilyen) , some of the accesses may complete (writing to memory) while another causes the operation to fault for architectural reasons (e.g. due an page-table entry that is marked “not present”). In this case, the effects of the completed accesses may be visible to software even though the overall instruction caused a fault. If TLB invalidation has been delayed (see Section 4.10.4.4), such page faults may occur even if all accesses are to the same page.
Erre a fejezetre gondolsz?
-
LordX
veterán
A 8.1.2 nem tudom hogy jön ide, a 8.1.1-et akartam hivatkozni arra, hogy egy load vagy store akkor atomi, ha befér egy cache line-ba, akkor is, ha nem MOV-ból jön, hanem bármilyen utasítás memory operandussal.
Ez egy fontos pont: "A locked instruction is guaranteed to lock only the area of memory defined by the destination operand, but may be interpreted by the system as a lock for a larger memory area."
Agner azt írja, hogy a LOCK utasítások (XCHG-t beleértve) erősen függ a memória sebességétől (ugyanaz a doksi, az első oldal alján a LOCK-ról egy bekezdés), amit bemásoltál, az a "Latency", amit ő úgy definiál, hogy "This is the delay that the instruction generates in a dependency chain. The numbers are minimum values. (.. blabla cache miss, floating point, exceptions ...) The latency listed does not include the memory operand where the operand is listed as register or memory (r/m). Tehát ebben nincs benne a cache és/vagy a memória hozzáférés által generált késleltetés, csak és kizárólag azt jelenti, hogy hány órajel után jöhet egy olyan új utasítás, ami erre az utasításra dependál, attól számítva, hogy a uOP issue megtörtént. Szóval az utasítás végrehajtásának idejének ez csak egy része.
Hogy hogyan van implementálva a LOCK, azt nem tudom, de egyrészt hardverről hardverre változik, másrészt igazából mindegy; az ordering miatt nem hajthatsz végre egy csomó memóriaműveletet amíg a LOCK be nem fejeződik: 8.2.2, bocs, de most eltekintek az egész fejezet bemásolásától
Read-re van spekulatív végrehajtás (egyébként e miatt talán annyira nem dramatikus a pipeline stall), de más műveletet nem tud elkezdeni se a proci, és itt jön be az a pipeline bubble, amiről írtam. -
P.H.
senior tag
Egyszerűbb lenne, ha egyszerűen beidéznéd a vonatkozó részeket, mert én nem azt látom benne, amit leírtál, hanem ezt:
8.1.2 Bus Locking
"Intel 64 and IA-32 processors provide a LOCK# signal that is asserted automatically during certain critical memory operations to lock the system bus or equivalent link. While this output signal is asserted, requests from other processors or bus agents for control of the bus are blocked. Software can specify other occasions when the LOCK semantics are to be followed by prepending the LOCK prefix to an instruction."
8.1.2.2 Software Controlled Bus Locking
"To explicitly force the LOCK semantics, software can use the LOCK prefix with the following instructions when they are used to modify a memory location. An invalid-opcode exception (#UD) is generated when the LOCK prefix is used with any other instruction or when no write operation is made to memory (that is, when the destination operand is in a register)."
"• The bit test and modify instructions (BTS, BTR, and BTC)."
(bit test&set utasítások)"• The exchange instructions (XADD, CMPXCHG, and CMPXCHG8B)."
(compare&exchange utasítások)"• The LOCK prefix is automatically assumed for XCHG instruction."
(exchange reg<->mem)"• The following single-operand arithmetic and logical instructions: INC, DEC, NOT, and NEG."
(logikai utasítások)"• The following two-operand arithmetic and logical instructions: ADD, ADC, SUB, SBB, AND, OR, and XOR."
(logikai és +/- utasítások)Mely eset maradt ki, amikor életbe lép a 8.1.2 fejezet?
"A locked instruction is guaranteed to lock only the area of memory defined by the destination operand, but may be interpreted by the system as a lock for a larger memory area."
"Software should access semaphores (shared memory used for signalling between multiple processors) using identical addresses and operand lengths. For example, if one processor accesses a semaphore using a word access, other processors should not access the semaphore using a byte access."Alapszabály, hogy aligned cache line-ra nem teszünk egyszerre szinkronizációs változót és adatot. Ezt már ~20 éve tudják a fordítóprogramok. (Persze nyilván meg lehet kerülni; milyen keyword-del tudatod tetszőleges nyelvben, hogy az adott változó módosítása elé tegyen LOCK-ot?
És milyen eljáráshívással? SetEvent, ResetEvent, WaitForSingleObject, ...)A idézetből következik, hogy a fenti utasítások nem zárolják a teljes buszt, hanem csak adott memóriaterületet (ami nagyobb lehet, mint a ténylegesen módosított, praktikusan egy 64 byte-os teljes cache line, hiszen az Intel, az AMD vagy a VIA sem a maga ellensége). Ettől még a többi mag korlátozás nélkül végezheti az utasításvégrehajtást.
Ha másért nem is egyértelmű ez, az SSE3-ban (Prescott) bevezetett MONITOR és MWAIT utasítások létezése indokolja ilyen belső hardver létezését.De megnézhetjük, mennyi is egy-egy locked utasítás végrehajtási ideje: naprakész hardvereken ebből a táblázatból is kinézhető http://agner.org/optimize/instruction_tables.pdf, vagy akár AIDA64-ben az Instruction Latency Dump is megadja LOCK ADD és XCHG mem,reg utasítások futási idejét, amelyen lefuttatjuk.
K10: XCHG 21 órajel
Nehalem: XCHG 20 órajel
Sandy B. XCHG 25 órajel
Ivy B. XCHG 25 órajel LOCK ADD: 22 órajel
Haswell: XCHG 21 órajel LOCK ADD: 19 órajel
Bulldozer: XCHG ~50 órajel LOCK ADD: ~55 órajel
Piledriver: XCHG ~40 órajel LOCK ADD: ~40 órajel
Steamroller: XCHG ~38 órajel LOCK ADD: ~39 órajel
(Nem csak a PCLMULQDQ-ról lehet olvasni általánosan a sajtóanyagokban, hanem a locked műveletek gyorsabb és gyorsabb végrehajtásáról is.)Gyakorlatilag magszinten a LOCK-prefixes művelet végrehajtása annyit jelent manapság, hogy amikor találkozik ilyennel a dekóder, akkor addig újabb utasítást nem dekódol, amíg ez végig nem ért a végrehajtási futószalagon és ki nem írta az eredményét egy rendszerszinten látható (=snoopable cache) memóriába (ez általában az L1D, a Bulldozer-család esetében az L2, ezért a nagy időigény).
A többi mag nyugodtan hajthat végre utasításokat, azokat nem befolyásolja (egy utasítást egy mag hajt végre), mert ha ott is van ugyanerrea memóriaterületre vonatkozó locked módosítás, akkor legfejlebb az nyer...; és nem mondom tovább, tudod.
Persze ebből össze lehet hozni az adott magon több száz órajeles időidényt, ha a forrásadatot RAM-ból kell beolvasni, de erre - azaz több mag által frekventáltan módosított adatterületek tárolására - vannak kitalálva alapvetően a nagyméretű L3 cache-ek. A TSX teljesen másra való. -
#137
hugo chávez
aktív tag
LordX
#134
hugo chávez
aktív tag
Na ez az! Szerverprociknál és pláne multiprocesszoros környezetben elhiszem, hogy gond lehet az x86 memóriamodellje (elvileg pont emiatt szívás a MIC az Intelnek), de otthoni környezetben már nem annyira. Mert nincs is igény a nagyon sok "valódi procimagra", nem lehetne kihasználni őket észszerűen. És valószínűleg nem is lesz... Amdahl törvénye, "Dark Silicon", stb...
Nehéz... Ha lenne értelme (szigorúan PC környezetben, ott, ahol valószínű, hogy nem is nyernének túl sokat az általában 4-8 nagy(obb) teljesítményű magnál többet nem igénylő programok miatt) egyáltalán, akkor melyik érné meg jobban? Megpróbálni a nehézségekkel együtt, vagy bevállalni egy totális ISA váltást, annak minden hátrányával (elsősorban a kompatibilitás elvesztése)?
Nem is konkrétan a memóriamodellre gondoltam, hanem úgy általánosságban összehasonlítva a többi uarch-kal, persze skálázódási szempontból is. Nem nagyon értek ilyen mélységekben ehhez, pont ezért is kérdeztem a véleményed.
Szóval azt mondod, hogy ez végül is a VLIW-EPIC -hez hasonló, de talán továbbgondolt megközelítés? És a TRIPS-nél valamilyen szinten próbálták hardveresen megoldani azt, amit az Itanium "hiányossága" volt? -
LordX
veterán
Nem a read-modify-write, hanem "csak" a read és a write rész külön-külön atomi, ha a felhasznált adat teljesen befér egy cache line-ba (azaz nem lép át 64 byte-os címet) - ez P6 óta van, előtte csak aligned hozzáférés volt atomi. De ez igazából teljesen mindegy, mivel a főmemóriával és a többi processzorral való "kommunikáció" amúgy is cacheline szinten megy. Lásd [1], 8.1 fejezet.
A probléma az ordering: [1] 8.2.2 Van egy zsák szabály, hogy milyen memóriaművelet mivel lehet felcserélni, de ha megnézed a fejezetet, kb. az jön le, hogy semmit semmivel - kivéve pár esetet - még akkor is, ha egyébként teljesen független memóriacímmel dolgozik az érintett művelet. Ez már egyprocesszoros rendszernél is problémás: Out-of-Order működésnél komoly probléma, ha tilos átrendezned műveleteket. Többprocesszoros rendszerben meg amikor egyik utasítás egy lassú szinkronizációs művelet, a többi utasítás is blokkolva van: egy LOCK INC több, mint 100 órajel, a Haswellben 8 pipeline port van, tehát olyan 800 darab utasítást kéne kiadni, ami nem memóriaművelet, hogy ne álljon üresben a proci. (Hardver szálakról beszélünk, szóval nincs context switch se, hogy "addig futtassunk mást") Van max 4x16 db regisztered, ami elég adatot kell tartalmazzon ehhez a 800 utasításhoz, amíg a LOCK INC fogja a memóriát. Hát, sok sikert.. Egy régi statisztika szerint valós x86 programban az utasítások kb. ötöde memória-operandussal dolgozik. Ja, és nem csak a LOCK INC-et kiadó processzorban történik mindez, hanem mindegyikben, amelyik a memóriához fordulna, miközben valaki LOCKolta a buszt.
ARM esetében ilyen nincs. Ott minden OoO, ha nincs függőség az utasítások között. A program helyes működése céljából itt ki kell adni a megfelelő acquire-release vagy barrier utasításokat, de ezzel csak a szinkronizációt lassítod, a szál "egyéb" utasításait, a thread_local / stacken levő adatokhoz hozzáférést nem.
[1]: Intel 64 and IA-32 Architectures Software Developer Manuals, 3.A. kötet
-
P.H.
senior tag
Ezt meg én nem értem: "x86-ban gyakorlatilag minden utasítás load/store utasítás, ha az első operandus memóriacím", nem locked, ha nem XCHG vagy CMPXCHG. Ha el van látva LOCK prefix-szel, akkor lesz atomi, alapesetben nem az az összes többi load-op-store utasítás. Mit korlátoz ez multiprocesszoros környezetben?
-
#134
LordX
veterán
hugo chávez
#133
LordX
veterán
válasz
hugo chávez
#133
üzenetére
Nem tudom hogy vagy vele, de PC és mobil vonalon minden chipben max 8 szál (4 x86 mag HT-vel vagy 8 ARM mag) van, mellette egy akkora iGPU-val, ami már több helyet foglal a chipen, mint a 4/8 CPU mag és a cache összesen. Szóval a gyártók szerint sincs (ma) gyakorlati értelme erre a piacra. Szerverekbe meg gyártják a 36 szálas Haswell-EX-et meg a 48/64/192 magos ARM chipeket GPU nélkül
Lehet kiegészíteni x86 modellt; a TSX utasításkészlet egy ilyen próbálkozás (bár nem abban az irányban, hogy közeledjen az ARM felé), csak azért talán mutatja, hogy egy ilyen kiegészítés mennyire nehéz vállalkozás, hogy az Intel is el is cseszte a TSX első implementációját. Az se segít, hogy az x86-ban gyakorlatilag minden utasítás load/store utasítás, ha az első operandus memóriacím.
Szerintem ez a TRIPS nem próbálja megoldani ezt a problémát; Ők "csak" azt kutatják, hogy hogyan lehetne ILP növekedést elérni, és szerintük a megoldás az, hogy az OoO helyett implicite kódoljuk bele az utasításkészletbe. Hol is láttam ilyet..
-
#133
hugo chávez
aktív tag
LordX
#130
hugo chávez
aktív tag
Oké, ez világos. Na de ha szigorúan a PC és mobil vonalat nézzük, ott 8-16 magnál többnek lenne gyakorlati értelme bármilyen memóriamodellel is? Ha valahová nagyon sok szál kell, akkor nem jobb a lebutított apró CPU-származékok helyett egy külön, IGP-szerű tömb, aminek úgy is saját ISA-ja lehet-van, aztán a közös virtuális memórián keresztül meg pofáznak egymással (HSA)? Vagyis nem látom értelmét otthoni felhasználásra olyan CPU-nak, aminél korlátozó lehetne az x86 memóriamodellje azért, mert annyira tele lesz majd apró magokkal (amiknek egy szálon hurka a teljesítményük, ha meg kifejezetten "throughput optimized multicore" tömbként nézzük, arra már most ott van az IGP).
És egy láma kérdés. Nem lehet az x86 memóriamodelljét "kiegészíteni"? A visszafelé kompatibilitás megtartásával. Akár úgy, hogy a régi modell utána már csak "legacy-ben" lenne elérhető?
Még valami: [link], [link] Már régóta semmi nem történik ott, de azért úgy évente ránézek nosztalgiából, hátha... Mi a véleményed, mennyire lenne-lehetne jó ez a cucc a jelenlegiekhez (x86, ARM és társai) képest?
-
Abu85
HÁZIGAZDA
Igen, az Itanium memóriamodellje tényleg szépen ki volt gyúrva a skálázhatóságra. De az x86-tól sokat nem lehet elvárni. Amikor tervezték, akkor szó sem volt róla, hogy egynél több mag lesz a lapkákban. Ennek következtében nem is merült fel a skálázhatóság mint igény. Akármelyik ISA-val így jártunk volna.
Az ARM egy kicsit más tészta szerintem. Az új ISA-val nekik tényleg megvan a lehetőségük jól skálázható alapot csinálni a megfelelő CCI interfésszel, de ők nem úgy gondolkodnak, mint az Intel, hogy CPU kell mindenhova, mert nekik eleve nem olyan kritikus hozzáláncolni egy piacot az ARMv8 ISA-hoz. A piac hozzáláncolja magát lényegi alternatíva hiányában. Ez megadja az ARM-nak a lehetőséget, hogy modernebb konstrukciókban is gondolkodjanak, amire már gyúrják is ki a következő Mali-t.
-
#130
LordX
veterán
hugo chávez
#129
LordX
veterán
válasz
hugo chávez
#129
üzenetére
Az x86-al az elavult, nem épp multiprocesszor-barát memóriamodellje a baj. Az Itanium gyönyörűen megcsinálta jól, csak a VLIW ölte meg. A következő, aki ezt megcsinálta, az az ARMv8 (ott az acquire-release helyett SC atomics van, egyesek szerint még jobb).
-
#129
hugo chávez
aktív tag
Dr. Akula
#127
hugo chávez
aktív tag
válasz
Dr. Akula
#127
üzenetére
Mindig előjön ez téma... Nem konkrétan neked címezve, de kérdem, az x86(-64) helyett milyen meglévő ISA-t ajánlanátok általános célú procihoz, olyanhoz, ahová kellenek a szálankénti teljesítményre kigyúrt (latency optimized) magok? Az Itaniumot felejtsük el, mert az EPIC/VLIW uarch, ami pedig egy szuperskalár procihoz képest ebben nem nagyon virít. Szóval, az elterjedtek közül van a szintén "ősöreg" és azóta az x86-hoz hasonlóan reszelegetett ARM, MIPS, SPARC, meg a valamivel fiatalabb POWER (és az abból származó Power PC). Ezekre meg totál felesleges lenne a már szintén "kellően RISC-esedett" x86-ot leváltani szerintem, mert egyik uarch/ISA sem tud már igazi előnyt felmutatni vele szemben.
Mondjuk ez érdekesnek tűnik... De hogy megérné-e váltani PC-n erre és ezzel bukni a visszamenőleges natív x86 kompatibilitást, hááát...
-
lenox
veterán
válasz
#32839680
#123
üzenetére
Egy processzel többet nem címzel meg (jó esetben) 4GB-nál 32bit alatt.
En mondjuk csinaltam ilyet, szerintem jo eset volt. Address Windowing Extensions windowson, foglalsz pl. egy 512 MB-os ablakot es 16 db 512 MB-os teruletet, sorban be lehet oket mapelni, igy 8 GB-ot cimezni.
-
#120
SylverR
senior tag
SamWarrick
#119
SylverR
senior tag
válasz
SamWarrick
#119
üzenetére
Így van. Rakhatsz a gépedbe 8 giga RAM-ot, vagy akár többet is (64 bites procik)
Integrált memória vezérlő. Realtime tesszeláció. Most így fejtetőről lesöpörve ennyi jön össze. De össze lehet még szedni többet is. -
#119
SamWarrick
csendes tag
SamWarrick
csendes tag
Az AMD már megint a saját útját járja...eddig milyen sok jó kisült belőle.
-
farkas1
tag
válasz
Raysen623
#112
üzenetére
Ha elindult a gép. Mert még nincs össze rakva. Ja és az APU össz mag 12, rosszul írtam az előbb.
Sajnos nem az enyém lesz, de ha van közvetett infó, eljuttatom.
Alaplap Asus Crossblade Ranger, memó G.skill DDR3 2x8GB 2400MHz
Videókártya egy darabig nem lesz benne, úgyhogy direktben az apu fogja futtatni a játékokat. Így lesz róla tapasztalat. -
Kopi31415 & Raysen623 fejezzétek be!
-
Abu85
HÁZIGAZDA
válasz
Dr. Akula
#102
üzenetére
1. Mindenki váltani fog, hogy elérjék a legjobb bekötési szintet. Mindenképpen igazodni kell az API-k alapvető működéséhez.
2. A Fury előnye az lesz, hogy a GCN-t jobban ismerik a fejlesztők, mivel a teszteket csak ezen a hardveren tudták lefuttatni az elmúlt egy évben. Első körben egyébként nem lesz olyan játék, ami továbbmegy az alapvető DX12-es funkciókon, így async compute/DMA, executeindirect, multi-thread, multiadapter, stb. dolgok lesznek kihasználva. Ezek a legfontosabbak, és a szűkös idő miatt nyilván ezek kapják a fókuszt.(#103) Ren Hoek: Senki se mondta, hogy probléma. Azért van szegmentálva az API, hogy le legyen kezelve az egész. Lehetőség szerint úgy, hogy az a fejlesztőknek egyszerű legyen, és eközben minden hardvert elérjenek.
-
Ren Hoek
veterán
Ez végülis nem akkora egetverő probléma, mivel csak a CPU-nak jelent többletterhelést, nem? Mondjuk egy TIER2 szint esetén ez kb mekkora lehet? Mert ha mondjuk 5-10% az emuláció miatt, az nem egy nagy érvágás...
Vagy ezt hogyan kell elképzelni, játék közben/játék és DX12 kihasználtság függően dinamikusan változik a többletterhelés, mondjuk egy TIER2-es HW-n - vagy azért kalkulálható előre...?
-
-
Abu85
HÁZIGAZDA
válasz
#06658560
#99
üzenetére
Igen. Az AMD validátora így működik, és a Microsoft ezt a rendszert használja a DX12-ben. Ez a validátor nem fogja validálni azt a kódot, amelyet nem szabványosan írsz meg, vagyis nem a maximális bekötési szintre dolgozol. Maga a validátor nem tudja értelmezni a pure bindless memória hozzáférés nélküli shadereket. Ki fog lépni egy nem WARP-kompatibilis shader hibával.
Azt nem tudom, hogy a Microsoft megengedi-e a nem validált program szállítását. Valószínűleg nem, mert az veszélyes az OS-re. -
#06658560
törölt tag
-
Abu85
HÁZIGAZDA
válasz
Dr. Akula
#97
üzenetére
Nem a lehetőség adott, hanem így kell programozni a DX12-ben. Ha nem így csinálják, akkor nincs garancia arra, hogy működni fog a program.
Egyébként a legtöbb fejlesztő úgy fog dolgozni, hogy megírják az Xbox One kódot és azt áthozzák egy az egyben PC-re. Nem a legjobb modell, de olcsó(tm), és pont ezért van így megoldva a validátor, hogy az egyes effekteket a validálás alapján tiltsa a nem megfelelő hardvereken. A fejlesztőnek ez csak két kattintás, és mehet ki a PC-s port. Persze bárkinek lehetőség van alternatív eljárásokat keresni, hogy ne kelljen kikapcsolni az effekteket, szóval az is megtalálja a számítását, aki nem az olcsó(tm) jegyében portol. -
Dr. Akula
félisten
Oké hogy a lehetőség adott, de van is valami reális esély hogy ez a valóságban is megjelenjen? Eddig se sietett az Nvidia az AMD-hez igazodni, a játékfejlesztők se. Persze a fejlesztők az Nvida only technológiákra se mozdulnak rá nagyon, pl. PhysX, az is inkább csak techdemó, mint a Mantle. Jellemzően eddig is az AMD vette csont nélkül az akadályokat, az Nvidia kártyáknak készült a könnyített TIER akárhány, de a fejlesztők is csak ezt a könnyített szintet célozták meg, mert ez mindenkinél futni fog, kár olyanba ölni az energiát ami úgyse lesz kihasználva.
Szóval van most valami ami kikényszerítené a DX12 miatt az architektúra váltást az Nvidiánál? Gyengébb lesz ott a jelenlegi csúcskártyájuk (980Ti) az AMD-nél (FuryX)? Mert most épp fordított a helyzet. Nem sokkal van lemaradva, de ugyanannyi pénzért -10% teljesítmény nem nagy perspektíva, legalább ennyivel olcsóbb is lehetne.
-
Abu85
HÁZIGAZDA
válasz
Dr. Akula
#92
üzenetére
Amelyik szint meg van szabva a WARP-ban, arra kell mindent csinálni, mert onnan képes a rendszer skálázni. A bekötési modellnél ez úgy néz ki, hogy TIER_3-nak megfelelő kell írni a motor erőforrás-menedzsmentjét, és onnan az API már kezelni tudja a TIER_2 és TIER_1 bekötéseket a programkód módosítása nélkül.
Az effektekkel sincs probléma. A DX12-ben nem lehet szállítani programot validálás nélkül. Tehát ezt a végső kódon a fejlesztők lefuttatják. Az AMD validátorát a Microsoft kiegészítette egy korlátozó modullal, amely leszámolja, hogy az adott programkód mennyi erőforrást használ és képes már úgy validálni a programot, hogy az effektek egy részét automatikusan tiltja a gyengébb bekötési szinteken, amelyek ugye nem férnek bele az erőforráslimitekbe. -
#06658560
törölt tag
Nem azért nem használják ki a hardvert, mert a másikat akarják helyzetbe hozni, hanem mert nincs kapacitásuk -pénzben, emberben, időben- optimalizálni mindenre, és egy közös nevezőt keresnek, ami mindenen vállalhatóan fut. Ugyanis mennyi variáció létezik csak most csak GPU-ból? E mellé teheted a MultiGPU-t, a procik széles skáláját, memóriavariációkat, és gyakorlatilag oda jutsz, végtelen idő mindenre optimalizálni. Arról ne is beszéljünk, hogy az AMD GCN is káosz, ami a DX12 egyes funkcióinak Tier szintjeit illeti.
Az pedig nem fog működni, hogy egyetlen architektúrára optimalizálnak, a többit hagyják alapon, mert akkor a játékosok felől olyan anyázászuhanyt kapnak, hogy akár a rolót is le lehet húzni utána.
-
#94
Petykemano
veterán
Petykemano
veterán
Nem vagyok szakértője a témának, csak olvastam a S|A-en, Juanrga felhasználó véleményét, hogy ez nem lehet sem zen, sem zen+, se hbm2, se arctic islands, mert ha ilyen készül, valószínűleg inkább 2018-2020 között készül el.
Egy gondolat a csúcsteljesítményről. Megintcsak nemvagyik szakértője, de a gyorsítókártyák működését úgy tudom elképzelni, Hogy a futó program összeállít egy csomagot, átadja a gyorsítónak, az kiszámolja és visszaadja az eredményt. Azért így rendesen ki kell találni, hogy mi és mekkora legyen a csomag, amit megéri átadni.
Egy ilyen giga apu esetén az tud lenni a giga előny, hogy nem csak másolni nem kell, (márpedig biztos előfordul egy-egy nem annyira komplex, de jól párhuzamosítható , de nagy tárhelyen végzett feladat, amit nem a feladat jellege, hanem mérete miatt nem toltak ki a gyorsítóra.), de csomagokat előre összekészíteni se. Csak a vezérlést kell átadni úgymond. Vajon mekkora potenciál rejlik abban, hogy nem kell mérlegelni, hogy megéri-e kiküldeni a gyorsítóra, hanem minden programrész a legoptmilálisabb módon tud futni: párhutamosítva jól, vagy single thread magas órajelen.Engem az érdekelne, hogy a facebookkal mi van? Nekik pont egy ilyen apu kellett a MySQL és a Memcache futtatásához. Szerintem Egyébként a megszivárogtatott 200w-os apu inkább az, ami nekik készül, ha készül, mint ez az exascale monstrum
-
Raysen623
addikt
válasz
Dr. Akula
#92
üzenetére
Azt mindig elfelejtitek, hogy a Mantle egy PC oldali lökés volt az iparágban a változás irányába (mivel a DX11 egyszerűen nem volt igazán megfelelő a GCN féle architektúrának), míg a DX12 egy egységes (most nem beszélünk a Mantle féle hasonlóságokról) API amit eleve használnak, illetve annak egy mono verzióját használják a konzolok esetén. Na mármost mivel a konzol oldali játékfejlesztések fedik le a piac nagyobb részét (hiába van több PC, a bevételek nagyobb része konzolon történik), ezért a fejlesztőket nem az fogja érdekelni kinek milyen hardvere van PC oldalon, hanem az hogy mennyivel egyszerűsödik a munkája a portolásoknál és ezzel mennyi költséget tud megtakarítani. Nem kevés pénzbe kerül egy AAA kategóriás multiplatformos játék. A PC-s portok minősége eddig sem volt túl jó (eltekintve némi egyedi esettől), de attól még a költségvonzata ott van.
-
Dr. Akula
félisten
"a többiek váltanak architektúrát, hogy elkerüljék a többletterhelést, és meglegyen a pure bindless működés a hardverben"
Ez mikor fog a valóságban is megjelenni, játékoknál? A Mantle is mióta létezik, de alig van ami támogatja. A játékfejlesztők se nagyon kapkodnak olyan technológiákért amivel csak a piac 50%-át érhetik el maximum. És egyáltalán átfordíthatja ez a Fury hátrányát a 980Ti-vel szemben előnnyé? Mármint gyakorlati előnnyé. -
-
Ren Hoek
veterán
válasz
Raysen623
#88
üzenetére
Engem technológiailag lenyűgözne hogyha a GCN ekkorát gyorsulna a Nitroban. Köv kártya szerintem Fury Pro lesz... ha beesik jól az áruk. Bár amilyen ratyi a forint és amennyire nem mennek le a kártyák árai erősen kétlem, hogy a közeljövőben 120K körül lenne. Annyinál többet soha nem adnék VGA-ért.
Illetve még arra leszek nagyon kíváncsi, hogy az APU-k hogyan fognak menni DX12 alatt, főleg hogy azokon megy az IOMMU címzés. Mondjuk a legerősebb AMD APU + Fury X.
-
Raysen623
addikt
Olvastam amit írtál, csak nem voltál eléggé precíz ami a megfogalmazást illeti. Legalábbis eléggé gúnyosra sikeredett elsőre. Mivel második nekifutásra már érthetőbb lettél, ezért természetesen visszavonom a korábbiakat. Rendben vagyunk így?
Egyébként meg nekem nincs GCN Radeonom jelenleg, így én nem sokat fogok tudni profitálni az új API-ból véleményem szerint...
-
Ren Hoek
veterán
válasz
Raysen623
#83
üzenetére
Ember, olvastad mit írtam?
Szövegértés 1-es! Pont ezt mondom én is, hogy mindegyik kártyán jól fognak futni az első fecskék. Kivétel a Nitrous, mert az egy kemény dió. Elvileg a Maxwelleknek már nem fekszik annyira a 10 async pipeline, már ha a végleges annyit fog használni. Itt azon van a kérdés, hogy játszhatóság szempontjából hol lesz a "treshold". Abu szerint a 10 pipeline már negyedére is visszaveheti a tempót. Kérdés, hogy minek a negyedét vesszük."Mikor tanultok meg objektívan gondolkodni és kilépni a kivagyiság szánalmas árnyékából?!
"Már bocs, de a legnagyobb böszmeség valakit beskatulyázni zöldnek és általánosítani :
Hol vagyok én zöld? Cserélgetek piros és zöld között már ősidők óta, amelyik épp kedvemre való. Sosem mondtam ilyet, bizonyos játékokban nekem a 30 FPS konstans is teljesen oké - a 60 Hz-es szinkron a lényeg.
Itt a hangsúly azon van, hogy a legbrutálabb DX12 játékban hogy fog szerepelni, egy technológiailag nem erre épített hw. Ha a vörösök által agyonszidott buta Maxwell2-n is játszhatóan, GCN-en meg ultrabrutál jól, az win-win. Nekem jó, mert nem kell cserélni, nektek meg azért jó mert lehet vörösszegfűs tüzijátékos kampánypartit csinálni, hogy IGEN-IGEN megmondtuk zöld rüszügyíkok (Troll off)
Amúgy meg egy oldalon állunk, csak játszani szeretnénk értelmes FPS-el, szép grafikát.(#85) SylverR: Szerintem a DX12 annyira új és annyira más, hogy nem lehet hasonlítani a korábbi API váltásokhoz. Nincs is értelme. Abban igazad van viszont, hogy a nagyrészét nem fogják használni az újdonságoknak - de alapjaiban az egész újdonság nulláról van kezdve kb.
-
SylverR
senior tag
De én nem arról beszélek, hogy nem optimalizálnak rá, hanem arról, hogy nem használják ki a technológia lehetőségeit. Mármint a natív kódra gondolok. A Crysis 1 sem volt valódi DX10 alkotás, hanem egy DX7-es kódba (CryEngine 1) beleszőtt DX9-es renderer (shaderek), melyekhez hozzáadtak pár DX10-es efektet.
Szerencsére most nem fog tudni minden jött-ment új engine-t írni, mivel natívan kell majd kódolni. Van már egy csomó engine, amik már natívan támogatják majd. Aki meg nem tud, vagy nem akar új engine-t írni, az meg megveszi valamelyiket.
"Sajnos a számok nem hazudnak, én el se hittem ezt a 80%-os dolgot, azt hittem valami zöld troll duma..."
Én nem mondom, hogy nem igaz. De nem ismerek személyesen nVidia tulajt. -
Raysen623
addikt
Érdekes mód ezidáig a 200fps is kevés volt a zöldeknek, most hirtelen elegendő lenne a 60 is?
Komolyan nem tudom sírjak e vagy nevessek ezen... Mikor tanultok meg objektívan gondolkodni és kilépni a kivagyiság szánalmas árnyékából?! Egy átlag játékos 30-60 fps között játszik, ti meg azon vitáztok vajon a 150fps a jobb vagy a 170! Igazából azon a szinten már kurwára mindegy, mert mindkettő rohadt gyors egy átlagos halandónak, aki nem az fps-eket hajkurássza hanem próbál a lehető legjobb és legszebb grafikával játszani csupán a játékélményért.
Már elkezded gyártani a prekoncepcióidat szimpla önigazolásként, de én már most megmondom neked, hogy mindkét kártyán jól fog futni ugyanaz a game, és remélhetőleg 60 fps környékén stabilan egy medium config alatt. -
Ren Hoek
veterán
válasz
#32839680
#76
üzenetére
"Értelmes fejlesztő nem csinál ilyet, megírja jól kihasználva a hardvereket,"
Igen megcsinálja nv hardverekre (is), mert az A hardver. Sajnos a számok nem hazudnak, én el se hittem ezt a 80%-os dolgot, azt hittem valami zöld troll duma... és akkor vegyük ide, hogy nagyon sokaknak még amúgy is régebbi GCN van, vagy régebbi nv, ami meg még nem is async a táblázat szerint. Vajon akkor hány DX12-es gép van, amin a kódod értelmesen futna? Maxwell2 amúgy még eléggé jól fel van szerelve szerintem. Tiled resourcesből pl TIER3, a legújabb GCN meg TIER2. Ez az egész TIER2 bekötés is a fene tudja majd mennyit fog számítani... de úgy tudom minimális prociigénye lesz. Ami meg tudja fingatni a Maxwelleket az a durva async lehet. Azt viszont nehezen tudom elképzelni, hogy átlag sztoris FPS DX12 játékban ezt miért is kéne annyira erőltetni egyelőre? Agyonhypolt effektek? Nitrous-nál még abszolút megértem a sok egység és szim/fényforrások/AI miatt. Na erre nem igazán tud senki válaszolni még.
Szoftveresen persze ez egy tökre előremutató dolog, csak jelenleg nincs felkészülve rá a piac... de majd pár hét múlva kiderül az AOTS-nál. Mondjuk ha Maxwell2 is képes futtatni legalább 60 FPS-el FHD-n, akkor nagyot fogok nevetni
Ha ehhez még jön az, hogy pl egy Tonga is képes 60 FPS-re, illetve egy Hawaii meg 120-ra, ettől még a Maxwell2-t nem lesz érdemes cserélni. Ennél az összes többi DX12 csak lájtosabb lesz konzol szintű async kihasználtsággal.Egyes egyedül csak a játszhatóság lesz a lényeges DX12 alatt, akkor meg teljesen mindegy, hogy valamin 200 FPS-el megy, valamin meg 60-al.
-
csib41
aktív tag
Sajnos a szoftver fejlesztőkön fog múlni minden, hiába van hardverileg előnye az AMD-nek.
Ha ki is aknázzák az architektúrából származó többletteljesítményt, remélem nem olyan szemmel alig látható/kivehető effektekre pazarolják amivel az fps szám közel azonos lesz, ezzel elindítva egy újabb hisztirohamot.
Esélyes, hogy a programozók nem akarják majd azt, hogy az AMD-n valami kétszer gyorsabban fusson, esetleg kétszer szebb legyen, mert akkor csak kapnák a hideget-meleget, hogy AMD-pártiak, és direktbe lassítanak.
Cserébe állva tapsolunk az "zöld címekért", "a nem látható szimulációkért" vagy "a pálya legtöbb részét tartalmazó önreklámért".
-
Sinesol
veterán
válasz
#32839680
#76
üzenetére
A multiplatform játékok sima DX12-t használnak konzolon is, szóval nem fognak lemenni az igazán hardverspecifikus elemekig. A sima DX12 lényege épp az hogy mindenen jól menjen, mégis ki lenne olyan buta, hogy a piac töredékére fejleszt?
A komolyabb hardverspecifikus api, az a Dx12 mono, azzal viszont csak exkluzivok készülnek, szal Pc szempontjabol tökmind1.
Egyébként ne Maxwellben gondolkodjatok már, a Maxwell már kifut, mire lesznek rendes Dx12 játékok.
-
ukornel
aktív tag
válasz
#32839680
#58
üzenetére
Az AMD a GCN következőrevíziójánál elvileg az energiahatékonyságra megy rá; ezen a dián épp 2x-es növekedést ígérnek ezen a téren. Ebben nyilván vastagon benne van a gyártástechnológiai előrelépés (28nm -> 14nm FinFET) is, de biztosan lesznek olyan architekturális módosítások is, amiket az elavuló 28nm bulkon már nem volt érdemes véghezvinni. Gondolom, a GCN eddig meglevő előnyeit sem akarják sutba dobni; valami A-57 -> A72 jellegű fejlesztésre gondolok, mintsem Fermi/Kepler -> Maxwell szerű "specializációra".
-
Sinesol
veterán
Épp igy gondolom én is, olyan komolyabban DX12 optimalizalt játék nem mostanában jön, a dx11 alatt meg ugyanolyan jó mindkettő. Mire meg itt a Dx12 Kánaán addigra zöldeknek is meglesz a megfelelő architektura, szóval nem lesz itt semmi előny egyik oldalon se.
A GCN meg amilyen világmegváltó architektura, ahhoz képest még sose volt előnye játékok alatt a sok év alatt. A Maxwell is azért foglalkozhat a fogyasztással, mert már a Kepler is elég volt a GCN ellen.
-
Ren Hoek
veterán
Fejlesztőként én biztosan a 80%-os NV kártyarészesedésre alapoznék nagy címeknél. A fél karomat rá, hogy jön az egyedi Nitrous, szanaszét veri a Maxwelleket benne a Hawaii/Fury (Tongában már nem vagyok olyan biztos, mert annak is "szívószál" a sávszéle) - persze ez a legoptimistább AMD-s előrejelzés, mert NV-nél is gőzerővel dolgoznak a Nitrouson... és jelenleg ez lesz a legextrémebb DX12 vonulat ami GCN-re épül kb.
Ezen felül meg majd jönnek szépen a nagy címek, és Pascalig ugyan úgy fog menni Maxwell és GCN is ahogy eddig...Egyébként az is egy variáció, hogy mindkét gyártó sokat fog gyorsulni, és simán meglesznek 60 FPS-es smooth értékek, NV-n esetleg picit több CPU szotyizással a bind miatt. (de így is annyi CPU terhet vesz le a DX12, hogy belefér ez az emuláció) ..nahát GCN-en meg ugyan az 80 FPS-t megy majd. Hát gratulálok nekik
viszont én elpüttyögök 60 FPS-el VSync-el a Maxwellemen... és emiatt, vagy a spec Nitrous RTS játékok miatt nem fogok cserélni, mert még itt van 100 DX11 játék amiben meg tök jól megy kis fogyasztással. Szerintem a 80% nv user így gondolkozik. -
Raysen623
addikt
válasz
#32839680
#58
üzenetére
Az NV energiahatékonysága adott funkció beáldozásán alapszik az architektúrában (compute ha jól emlékszem), amit az AMD nem vett ki és ezért is van különbség a fogyasztásban. A kérdés az, vajon ez az áldozat mit fog hozni az új API-k eljövetelével. Aszinkron compute-ban az AMD jelenleg erősebb, márpedig erre bizony hajazni fog a DX12 is.
Én azt látom elképzelhetőnek, hogy NV ezt visszapakolja és lemegy a csíkszélességgel a pirosakkal együtt. Így kerülnek majd balanszba fogyasztás terén, onnantól kezdve pedig már az architektúra dönt majd a győztes kilétéről. Majd elválik... -
Abu85
HÁZIGAZDA
válasz
#32839680
#57
üzenetére
A architektúra leváltása most nagyon rossz lenne. Egyrészt úgy alakult minden, ahogy azt akarták. Az MS és a Khronos elfogadta azokat a reformokat, amelyekért kampányoltak. Nem csak egyet, hanem mindegyiket. Másrészt ezeknek a reformoknak egy kevésbé hangoztatott hátránya, hogy ismernie kell a hardvert a programfejlesztőnek, hogy bele tudja írni az alkalmazásba a megfelelő vezérlést. A GCN-t a konzolok miatt biztosan ismeri mindenki, ha most hoznak egy újat, akkor újra kell tanulni mindent. Ez jelentős tehet, amit sokan nem fognak megtenni. A hardverfejlesztés ilyen irány mellett lelassul, mert hátrányos lesz architektúrát váltani. Egyszerűen hiába hozod az elméletben másfélszer gyorsabb hardvert, az optimalizáció hiánya miatt nem lesz gyorsabb az elődnél.
-
Sinesol
veterán
válasz
#32839680
#66
üzenetére
Nem valószínű hogy jelentősen gyorsabb lesz, maximum cpu limites környezetben lesz nagyobb ugrás.
Amúgysem érdeke az AMD-nek sem, hogy lényegesen gyorsabb legyen.A legtöbb pénzt azzal lehet kihozni, ha épp konkurencia szintre lövik be a dolgokat, a pluszt ami van, azt meg beosztják a jövőre. Így ugy tudnak uj vga-t kiadni, hogy alig kell pént tolni fejlesztésbe.
Mindkét gyártónak az az érdeke, hogy kb ugyanazt az erőszintet lőjék be, ez megy már egy évtizede. -
#06658560
törölt tag
"Esélyes, hogy a programozók nem akarják majd azt, hogy az AMD-n valami kétszer gyorsabban fusson, esetleg kétszer szebb legyen, mert akkor csak kapnák a hideget-meleget, hogy AMD-pártiak, és direktbe lassítanak."
Inkább racionális döntést hoznak: megnézik a piac helyzetét, mire is kell terméket írniuk, felmérik mennyi energia a megcélzott architektúrákat optimalizálni kicsit, mennyi idejük van, aztán valamit majd dob a gép.
-
SylverR
senior tag
válasz
#06658560
#60
üzenetére
Így van, sem temetni, sem ódákat zengeni nem szabad. Sajnos a szoftver fejlesztőkön fog múlni minden, hiába van hardverileg előnye az AMD-nek. Esélyes, hogy a programozók nem akarják majd azt, hogy az AMD-n valami kétszer gyorsabban fusson, esetleg kétszer szebb legyen, mert akkor csak kapnák a hideget-meleget, hogy AMD-pártiak, és direktbe lassítanak.
-
#06658560
törölt tag
Pont ahova ezt az APU-t szánják, ott lenne értelme: itt megéri a szoftverfejlesztésbe is invesztálni, mert gyorsul annyit a specifikus kód.
Ami viszont korlátozhatja: a fix "RAM" mennyiség, és a fogyasztás, hőtermelés.
[TROLL] A zöldek nélkül már nem tudnak maguknak memóriát sem tervezni? [/TROLL]
-
-
#55
Szeszkazán
senior tag
leviske
#53
Szeszkazán
senior tag
Ez így van, de azért azt nem lehet figyelmen kívül hagyni , ha valaki hosszú évek óta csiszolgat és használ egy olyan archit amire épült a dx12 meg a többi jóság , vagy csinálni kell egy sajátot ami megfelel annak. NV-t ismerve sokat lop a megoldásokból, de próbál majd beletenni egyedi dolgokat , kisérletezni fog , lesz különbség azért és kiderül majd pozitív vagy negatív irányban. Papír forma szerint 1-2 évig erős amd előnyne kellene jönnie.
-
leviske
veterán
válasz
actival63
#46
üzenetére
Ilyen feleslegesen provokatív hozzászólásokat kár bedobni. Az nVidia-nál se hülyék dolgoznak, már a Maxwell utódjának számító Volta fejlesztésének kezdetén tisztában lehettek azzal, hogy mekkora hatása lesz az új API-k megalkotására a konzoloknak és a Mantle-nek. Szóval én nem volnék meglepődve, ha már 2016-ban se szorulna a cég egyik friss/akkor megjelenő GPU-ja se emulálásra.
Arról nem is beszélve, hogy még azt se láttuk, hogy a Fiji/Tonga/Wani kivételével mégis milyen minőségben fognak futni a jelenleg piacon lévő GCN kártyákon az új játékok.
Szóval ez a hergelés teljesen felesleges.
-
Abu85
HÁZIGAZDA
Biztosan továbbviszik pár évig. Eddig is ez volt a terv, most meg pláne az, így hogy átnyomták azokat az API reformokat, amelyeket memóriaalapú GPU-architektúrákra szabtak. Ezért egyébként részben bántják is az ARB-t és a GAB-et, mert csak a GCN memóriaalapú GPU-architektúra, így most csak azért fognak egy csomóan szívni, mert az AMD-nek ez az API modell a jó, de az MS és a Khronos döntése abból a szempontból érthető, hogy a jövő úgyis az efféle architektúráké, tehát ha már váltanak, akkor előrehozzák ezt a jövőt. Valószínűleg úgy voltak vele, hogy az AMD ettől nem fog monopol helyzetbe kerülni. Annyira nem nehéz ilyen hardvert tervezi, hogy 3-5 éven belül ne tudjon átváltani rá az ipar.
-
actival63
aktív tag
Arra leszek kíváncsi mit fognak a trollok majd mondani ha meglátják az első DX12 teszteket,. Most jár a szájuk de akkor nagy lesz majd a csend. Akár mennyire is fáj a zöldeknek de a DX12 két három évig az AMD saját játszótere lesz. Az nVidia csak a partvonalon fog ácsorogni hogy mikor jöhet egy kicsit ő is játszani.
-
Raysen623
addikt
válasz
#32839680
#38
üzenetére
Aha persze, csak és kizárólag a GCN az zsákutca ugye? Ennyi erővel az NV is zsákutcába futott, hiszen ugyanazt az architektúrát foltozgatja évek óta. Ami jó volt DX11 alatt lehet nem lesz olyan jó DX12 alatt, de igazából ezt még senki nem tudja, és te sem. A GCN elvileg pont az ilyen új API-ra lett kihegyezve AMD szerint, szóval legalább várnád meg a teszteket mielőtt elitéled. A teszteket ugye megint lesöpröd az asztalról szokás szerint és megy megint elölről minden.
Jó lenne végre leállni a prekoncepció gyártással, mert kissé unalmas mindenhol ugyanazt olvasni. -
Cathulhu
addikt
válasz
Kristof93
#25
üzenetére
Ha magonkent olyan gyenge, akkor tok mindegy, hogy 8 vagy 16, desktopon nem tudok olyan atlag progit mondani se jatekot, ami 8 mag folott rendesen skalazodna, raadasul a konzolok is annyival dolgoznak, szoval kb folosleges sziliciumpazarlas a 16 mag. Workstationbe mehetne, de az megint mas teszta.
-
Abu85
HÁZIGAZDA
válasz
#32839680
#38
üzenetére
Azzal, hogy a DX12 és a Vulkan átment úgy ahogy szerették volna az AMD-nek nem kell lépnie, mert a GCN eleve pure bindless. Az AMD-nek így a bekötést egyetlen lépcsőjét sem kell emulálni, vagyis ebből nem keletkezik többletterhelésük. A GCN akkor lenne csapda, ha a DX12 és a Vulkan nem olyan lenne, amilyen végül lesz. Most így inkább azt fogod látni, hogy a többiek váltanak architektúrát, hogy elkerüljék a többletterhelést, és meglegyen a pure bindless működés a hardverben. Az async compute miatt áttervezik a rendszert is stateless compute-ra, hogy elkerüljék a állapotváltásokat is.
Egyébként ez kockázatos volt az AMD-nek, de a Microsoft és a Khronos inkább választotta a fejlődést, mint a tömegpiachoz való igazodást. A jövőre gondolva ez sokkal kedvezőbb. -
leviske
veterán
válasz
#32839680
#38
üzenetére
Egy új architektúra nem feltétlen jelenti azt, hogy a Mantle/DX12/Vulcan támogatás megszűnik és JELENLEG meg sem éreznék, ha teszem azt Maxwell alapú GPU-kat kezdenének pakolni a kupakok alá.
A dokumentáltság és az architektúra fejlesztők általi ismerete meg jóval később fogja éreztetni a hatását, hiszen csak a várható futási sebesség alapján is látszik, hogy az első komolyabban optimalizált játék az Uncharted 4 lesz. Így ha bele akarod venni azt, hogy a konzolok okozta ismeretség miatt vannak "csapdában", akkor előbb érdemes az azokkal együtt járó előnyök megérkezését is bevárni. Nem?
-
válasz
#32839680
#38
üzenetére
Ezzel várjuk meg a DX12 játékokat.
Ha akkor is ez lesz a felállás, akkor igazad van, de egyelőre csak azt tudjuk, hogy DX11 alatt a hardver és a driver párosa olyan teljesítményt produkál, ami miatt a GPU órajeleit -> feszültségét olyan magasra kell állítani, ami magas fogyasztáshoz vezet. -
.mf
veterán
A 16C/32T procit és 32 GB-nyi RAM-ot még negyedelve is tisztességes speckót kapnánk (4C/8T, 8 GB RAM).
Papíron brutális, megvalósítani pedig talán annál is durvább lesz. Maga a 16 mag plusz a náluk is nagyobb területet foglaló IGP-s APU sem lesz egyszerű, de cserébe óriási (gondolom a valaha készült legnagyobb szerver-processzorokkal fog versenyezni); s a 8 modulban 32 GB-nyi RAM-ot fogadó interposer meg csak hab a tortán.
-
lenox
veterán
2 GB per magot szoktak mondani, hogy jo, a 16 cpu magra meg is van, de a gcn magokhoz is kell meg memoriaval szamolni.
@26: A hw tobb mem savszelt igenyel, kb. mindegy, hogy hogyan oldjak meg, nyilvan desktopra olyat csinalni, hogy csak fix meretu lehetne a memoria, az nem annyira jo, szoval a szokasos infrastrukturat erdemes hasznalni a bovithetoseghez (2 csatorna ddr3/4 ram), de kene melle valami gyorsitas.
-
ukornel
aktív tag
Úgy látszik, végre megteszi az AMD, amiért már többször nyígtam régebben, és összerakja végre azokat a technológiákat, amiket kifejlesztett/összevásárolt (Freedom Fabric, GCN, integráció), és nagyot gurítson a HPC szegmensben
A cikk zárómondatát viszont nem nagyon értem:
"az AMD koncepciója nem az abszolút csúcsteljesítményben, hanem inkább az energiahatékonyságban lehet jó"
Ha megfelelő interconnecttel hatékony a skálázás, akkor a csúcsteljesítménynek rendszerint a fogyasztás szab gátat, nem?#12 lenox
"Unified memory meg HSA, kozben meg lassu es gyors memoria is kell hozza? Az egyik celt, hogy egyszerubben lehessen optimalis kodot irni ez jol beszopatja"Ez nekem is beugrott, de a cikk mintha nem beszélne lassú memóriáról, csak, hogy a "rendszermemória szerepét a HBM 2 tölti be".
A 32GB memória nem túl sok ebben a szegmensben, de talán nem is túl kevés. Az IBM BlueGene/Q rendszereiben is 1 GB RAM jut egy magra. Más rendszerekben inkább 2-3 GB van magonként/szálanként. Az látszik, hogy jól jönne a HBM technológia további fejlesztésére (nagyobb sűrűség). -
Abu85
HÁZIGAZDA
Az ESRAM nem olyan jó ötlet, mert azt ki kell használni. Az Xbox One-ban azért jó, mert oda lehet trükközni, hiszen csak egyetlen gépről van szó. Olyan specifikus megoldást írnak rá a fejlesztők, amilyet akarnak. PC-n ez nem működne, mert senki sem fog rá optimalizálni.
Magából a DX12-ből is hiányoznak olyan részek, amelyekkel egy ilyen memória jól kihasználható. Bezzeg az Xbox One-only D3D12 mono konstrukcióban benne van. Ha a Microsoft sem akarja, akkor itt nehéz szembe menni ezekkel.(#12) lenox: Node-onként csak egy rendszermemória van benne. Az NVDIMM inkább adattárolás. Persze direkten azt is lehet címezni. Erre van HSA I/O felület, azzal minden speciális részegység képes adatot beolvasni az adattárolóról és kiírni az adattárolóra.
-
lenox
veterán
válasz
actival63
#21
üzenetére
Szerintem nem. Asztalra nem kene jobb, mint ami a konzolokban van, persze az hasonlit ezekhez, csak nem kell bele hbm, meg ennyi eroforras, mert megdragitja, es mezei user ugysem hasznalja ki. Inkabb a mezei ketcsatornas mem savszel problemajat lehetne javitani egy xbox one fele esram megoldassal.
-
#23
Televan74
nagyúr
Plazmacucci
#17
Televan74
nagyúr
válasz
Plazmacucci
#17
üzenetére
Tudás megvan a két említett terméknél.Csak hát az energia igény és a hatékonyság kérdéses.
-
#20
alevan
őstag
Komplikato
#18
alevan
őstag
válasz
Komplikato
#18
üzenetére
Azok csak vékonykliensként voltak használhatóak.
-
#18
Komplikato
veterán
icp1970
#4
Komplikato
veterán
-
#17
Plazmacucci
félisten
V!ck
#15
-
Este kipróbálom a 240-essel.
Egyébként lehet, hogy az az IGP kb. minimális változtatással került át a win10-be, ami nem is lehetett nehéz, mert funkciók terén valszeg XP óta nem változott.
Azt nem a MS követte el még évekkel ezelött? Gondolom, nem akartak kiszúrni X millió irodai munkással. -
#3
BangoSkank
tag
BangoSkank
tag
Tudom, hogy ez még csak egy elvi séma, a késztemék még nagyon távol van, ha lesz egyáltalán, de egy ilyen szörny 14nm-en kb mekkora szilikonterületet jelentene? 32 proceszormagot és mondjuk 4096 GCN magot feltételezve
Megoldható ez egyáltalán egy szilikonon?(az új driverekkel nekem is csak a bajom van egy régi Llanon)
-
Használj linuxot, ott van AMD által támogatott nyílt driver, amivel jobban megy az E350, mint Windows-on valaha.
Annak ellenére, hogy ott is főleg a GCN-es GPU-kra gyúrnak, és nem a VLIW5-re.Egyébként mióta szokás CPU-t IGP-hez haosnlítani VGA driver szempontból?
Gondolom azonos VGA-val a Brazos is eldöcögne...
Read-re van spekulatív végrehajtás (egyébként e miatt talán annyira nem dramatikus a pipeline stall), de más műveletet nem tud elkezdeni se a proci, és itt jön be az a pipeline bubble, amiről írtam.
Viszont VGA-ért nálam 60k a plafon. Egyszer vettem 80k-ért egyet, de 3 hónap után páros lábbal rúgtam ki a gépemből mert lassú volt és gyenge, a meleget meg ontotta magából.
"
Ha ehhez még jön az, hogy pl egy Tonga is képes 60 FPS-re, illetve egy Hawaii meg 120-ra, ettől még a Maxwell2-t nem lesz érdemes cserélni. Ennél az összes többi DX12 csak lájtosabb lesz konzol szintű async kihasználtsággal.
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Az a 16 mag sem fogja megelőzni a csúcs i7-et szerintem.
Annak ellenére, hogy ott is főleg a GCN-es GPU-kra gyúrnak, és nem a VLIW5-re.
Új hozzászólás Aktív témák
Hirdetés
- Magisk
- Napelem
- Villanyszerelés
- Norvégia átmenetileg betiltja az áramigényes kriptobányászatot
- Feketehalálra váltja a kékhalált a Microsoft
- Milyen légkondit a lakásba?
- Elektromos autók - motorok
- AMD Navi Radeon™ RX 9xxx sorozat
- Milyen egeret válasszak?
- Kerékpárosok, bringások ide!
- További aktív témák...
- Intel Core I9 14900KF - 24mag/32szál - Új, 1 év garancia - Eladó!
- Ryzen 9 7900 /// Bontatlan // Üzletből, számlával és Garanciával!
- Ryzen 7 8700G /// Bontatlan // Üzletből, számlával és Garanciával!
- Intel ES Core i5-3470 4-Core 3.2GHz LGA1155
- Ryzen 5 9600X /// Bontatlan // Üzletből, számlával és Garanciával!
- Apple iPhone 14 Pro 128GB, Kártyafüggetlen,
- Több Lenovo Thinkpad x1 carbon gen 4 / 5 / 6 / 7 X1 Yoga gen3 6-9. gen i7, i5 procik
- Apple iPhone 12 Mini 64GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! Honor 90 Lite/Honor 90/Honor Magic5 Lite/Honor Magic6 Lite/Honor Magic5 Pro
- Apple iPhone 13 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged