Moderátoři: flanker, Eddward, Baneshee
Já bych to také viděl jako pozitivum. Sice se mi původně ten modulární návrh líbil, ale AMD se evidentně s modulem coby náhradou klasického jádra nepovedlo dosáhnout vytýčených cílů.webwalker píše:....v případě zrušení SR osobně vidím jen pozitiva, ale třeba se pletu
Ne nebude. Jako kdyby IBM dodávalo PowerPc čipy do současnejch konzolí. Nebo jako kdyby RSX a R500 dnes dodávala AMD a NV. EE, oni jen udělaj návrh a Sony si samo udělá smlouvy s Globalfounders nebo UMC nebo koho bude chtít. AMd udělá návrh, dostane za něj zaplaceno a je to. Nebude dostávat dýška za každej prodanej kus, to by se konzolistům těžce nevyplácelo, to by zůstali u PowerPc, atd. Pokud do AMd půjdou tak jen kvůli nízké ceně.webwalker píše:Pokud alespoň některá nextgen konzole bude postavena na cpu x86 (APU AMD), pak AMD bude muset tato cpu také dodávat! Co se týká vlastních konzolí AMD, tak je to imho těžko uvěřitelný scénář. Stejně tak nVidia, která s výkonem Tegry začíná být na chvostu a vzhledem k tomu jak byla Tegra3 "spatlána", vyhlídky také nevypadají nijak růžové. Stejně tak, povede-li se Haswell, nejvíce na tom budou tratit mgpu nVidie.
Pokud vím, AMD hlásí opětovné snížení tržeb o 10%, což je sice špatné, nikoliv však zoufalé.
No možná jsem optimista, ale v případě zrušení SR osobně vidím jen pozitiva, ale třeba se pletu
Jak může být nějaký čip x86 a zároveň jím nebýt ??? Nemusí být full x86 compatible (podobně jako Larrabee) ale furt je to x86 čip na který se vztahují licenční podmínky.DOC_ZENITH píše:Proč? V konzolích se píše na železo. Tam nepoběžej na x86 x87 SSE, AVX, atd. Takže tyto instrukce zde vůbec nemusej bejt přítomný. Toť ihmo můj názor.
Kód: Vybrat vše
(define_insn_reservation "bdver3_call" 2
(and (eq_attr "cpu" "bdver3")
(eq_attr "type" "call,callv"))
"bdver3-double,(bdver3-agu | bdver3-ieu),nothing")Kód: Vybrat vše
(define_insn_reservation "bdver3_idirect" 1
(and (eq_attr "cpu" "bdver3")
(and (eq_attr "bdver1_decode" "direct")
(and (eq_attr "unit" "integer,unknown")
(eq_attr "memory" "none,unknown"))))
"bdver3-direct,(bdver3-ieu | bdver3-agu)")moc zajímavé Yuri, díky za info. Snad ho AMD ještě stihne uvést....yuri.cs píše:Pro pripad ze by to nekoho zajimalo. bdver3 z GCC patche je zrejme opravdu bajny model 20h-2Fh - ma jeho featuru v podobe provadeni int instrukci na ALU i AGU.
vlákno o ALU/AGU je zde :http://pctforum.tyden.cz/viewtopic.php? ... 5#p8265005Gregi píše:Nerozumiem. Skus to vysvetlit po lopate. Akoze podpora SteamRollera? Co je AGU ("adress generation unit")? Na co sluzi?
Inak v 3ke je vraj podpora len FMA3 (Piledirver) namiesto 1ky s FMA4 (Bulldozer). Co je na tom pravdy? Vo verzii 2 je zas len FMA. Ako to mam chapat, ze cim vyssie, tym ma spatnu kompatibilitu?
August 2007: AMD announces the SSE5 instruction set, which includes 3-operand FMA instructions. A new coding scheme (DREX) is introduced for allowing instructions to have three operands.[5]
April 2008: Intel announces their AVX and FMA instruction sets, including 4-operand FMA instructions. The coding of these instructions uses the new VEX coding scheme which is more flexible than AMD's DREX scheme.[6]
December 2008: Intel changes the specification for their FMA instructions from 4-operand to 3-operand instructions. The VEX coding scheme is still used.[7]
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.[8]
January 2012: AMD announces FMA3 support in future processors codenamed Trinity and Vishera; they are based on the Piledriver architecture. [9]
The Piledriver core adds AVX, AVX1.1, FMA3, AES (aka AES-NI in Intel-speak), and F16C. Bulldozer added FMA4 to the instruction set, that means Fused Multiply Add with 4 operands. Intel then added a far less efficient FMA3 to Haswell rather than supporting FMA4. Luckily, FMA3 in Piledriver is in addition to FMA4, not a replacement for it, and the XOP instructions are still unique to AMD. Like any new ISA, if you use them a lot, they will be a benefit, but older code doesn’t even know they are there. Whether or not this is a gain is viewer dependent.
3164 {"bdver2", PROCESSOR_BDVER2, CPU_BDVER2,
3165 PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
3166 | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
3167 | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_FMA4
3168 | PTA_XOP | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
3169 | PTA_FMA | PTA_PRFCHW},
Teoreticky vzato by mělo být FMA4 lepším řešením (nedestruktivní operand), ale na implementaci je zřejmě snadnější použití FM3.+ {"bdver3", PROCESSOR_BDVER3, CPU_BDVER3,
+ PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
+ | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
+ | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX
+ | PTA_XOP | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
+ | PTA_FMA | PTA_PRFCHW},
To ne, FMA instrukce jsou odesílány na fpu (FMAC).Ak som to dobre pochopil, tak to AGU vie okrem primarneho vypoctu adresy v pamati, este i FMA4, FMA3
to o čem tu mluvíte není náhodou směr AMD k tomu, že připravuje CPU část na to, aby byl co možná ve vyhledavaní a lehkému zpracování dat nejrychlejší jak to jen jde a GPU v APUčku bude mít naservírované předžvýkané data, které pak dopracuje. 