Új hozzászólás Aktív témák

• #20 dezz nagyúr TomBoy1986 #17

  Új Válasz 2009-12-10 19:10:26 #20

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz TomBoy1986 #17 üzenetére

  Milyen hw-ek között volt inkompatibilitás? A GPU-k fixfunkciósak voltak, a prociknál meg max. az lehetett gond, hogy az Intel nem támogatta a 3DNow!-t, az AMD meg mindig némi késéssel az aktuális MMX-et és SSE-t. Vagy úgy érted, túl nagy különbségek voltak a procik között sebességben?

  akosf: Lehetnek valakinek jó ötletei, de egy komplett motort nem biztos, hogy össze tud hozni a "sufniban", hiszen így még nagyobb munka. Így a kis cégek még nehezebben tudnak labdába rúgni a nagyok mellett, amik matematikusok és programozók hadát alkalmazhatják. Szóval, elég felemás ez a dolog.

  orbano: Szabványnak szabvány, de hogy mennyire jó... Bonyolultabb dekódolást igényel: CISC->RISC, nem fix szélességű utasítás-szavak, stb. Bár pl. a Larrabee-n nem átlag x86-os kód futott volna többségben, hanem AVX.

  mmdms: Titkos alkú a MS és Nvidia között? (Az AMD-t azért hagyom ki, mert ők ha akarnak, tudnak csinálni egy Larrabee-re hasonlító valamit. Az Nvidia viszont meg lenne lőve ezzel is, hiszen nem rendelkeznek sem x86, sem x64, sem SSE, sem AVX licenccel.)

  [ Szerkesztve ]

• #27 dezz nagyúr TomBoy1986 #26

  Új Válasz 2009-12-10 20:17:01 #27

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz TomBoy1986 #26 üzenetére

  De az nem szoftveres rendering volt... Hanem nem-szabványos fixfunkciós hw-ek.
  Vagy nem értem, mire gondolsz.

  [ Szerkesztve ]

• #47 dezz nagyúr orbano #46

  Új Válasz 2009-12-12 15:07:25 #47

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz orbano #46 üzenetére

  Jahh, így van ez pl. a Cell procival is, összetettebb algoritmusoknál kb. 5x GPU-s flops-nak felel meg a teljesítménye.

  Viszont, nem biztos, hogy a Larrabee architektúrája lesz a befutó... Kenterbe ver egy sima procit, de egy GPU ellen kevés... Épp ezért törölték az aktuális verziót is. De ha nem változtatnak az architektúrán, minden csíkszélességi lépcsőfoknál ugyanez lesz a helyzet... Lassan rájönnek, hogy mégis csak a Cell architektúrája (vagy valami ahhoz nagyon hasonló) a legjobb út... Az ugyanis 2-3x hatékonyabb. Hogy nehezebb programozni (értsd: nem annyi, hogy egy recompile)? Hát, valamit valamiért.

• #49 dezz nagyúr Jim Tonic #48

  Új Válasz 2009-12-12 16:00:33 #49

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz Jim Tonic #48 üzenetére

  A Larrabee-nek csak az egyik baja, hogy x86-on alapul. Ez önmagában még nem olyan hatalmas probléma, mivel az x86-os (+ x64 + SIMD-ek) kód átfordításra kerül egyfajta RISC kódra, és a továbbiakban azzal dolgoznak a magok. Bár ehhez szükség van egy összetett dekóder egységre (itt magonként), ami szintén foglalja a helyet.

  A másik dolog, ami talán fontosabb, hogy itt minden mag a szokásos CPU-s felépítést követi, ami cseppet sem hatékonyabb azoknál, ha nem teljesen általános integer kódról van szó, hanem elsősorban számításokról. Hiába van 32db belőle, 32 proci sem ér fel egy kisebb GPU-val sem ebben.

  Ezen belül az egyik dolog, hogy a szokásos cache memóriával operál, ahol egy bájt hasznos adathoz több bájt kiegészítő információt is el kell tárolni. Ellenpélda: a Cell prociban sima (statikus) RAM memória van az SPU-k mellett (jelenleg 256kB/SPU). Így ugyanakkora területen többszörös tár helyezhető el.

  A másik, hogy a Larrabee-ben minden mag a CPU-knál szokásos módon címezheti és férhet hozzá a külső memóriához. Ez jót tesz a kényelemnek és a könnyű programozhatóságnak (sok kód változtatás nélkül futtatható), azonban cseppet sem erőforrás-kímélő, nem kényszeríti rá a programozókra az optimálisabb kódolást, és az előbb említett, szokásos, nem helykímélő cache mechanizmust is igényli.

  Harmadik, hogy mivel még a kisebb L1 cache (10-20 kB) is sok helyet igényel, bonyolult és ugyancsak nem helykímélő ugrás-becslő logikára van szükség a L2-höz, vagy épp külső memóriához való hozzáférések számának csökkentése érdekében. A Cell SPU-i esetén erre nincs szükség.

  Így lehet 1-1 Celles SPU a hozzátartozó srammal együtt is jóval kisebb, mint 1-1 Larrabee-s mag -> azonos területen jóval több fér el belőlük -> jóval nagyobb hatékonyság.

  [ Szerkesztve ]

• #51 dezz nagyúr berVi #50

  Új Válasz 2009-12-12 23:26:37 #51

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz berVi #50 üzenetére

  A DirectX (SDK?) (legalábbis a korábbi verziók) tartalmaz egy bizonyos referencia renderert, ami nem más, mint egy szoftveres renderer, ami tehát szoftveresen emulálja a videokártyák működését. (Így ellenőrízhető, hogy a kettő egyforma eredményt ad-e, hiba esetén a videokártya drivere-e a bűnös, stb.) Ha eljő az "új korszak", a MS bizonyára rá fogja ezt optimalizálni az új HW-ekre, hogy legalább a meglévő DX alkalmazások fussanak rajtuk.

  De bizonyára azzal is bepróbálkoznak majd (a fenti továbbfejlesztéseként), hogy a szoftveres renderelés bonyibb részeit átveszik a kevésbé "elszánt" fejlesztők válláról, amolyan köztes megoldásként.

• #53 dezz nagyúr berVi #52

  Új Válasz 2009-12-13 01:34:18 #53

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz berVi #52 üzenetére

  Hát úgy, hogy amiket leírtam, azt maga a MS fogja csinálni, hogy megtartsa a DX-, és ezzel együtt Windows-függőséget. A legtöbb fejlesztő valószínű továbbra is ezt fogja használni, csak a kísérletezőbb kedvűek és a nagyok állnak majd neki 1-1 saját, fullos szoftver-renderernek.

• #57 dezz nagyúr berVi #54

  Új Válasz 2009-12-13 17:35:16 #57

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz berVi #54 üzenetére

  És!? Attól, hogy más hőbörög, a MS-nak nincs köze a témához?

  misran: Olyan, hogy ATI, mint döntésképes entitás már nem létezik, AMD van. És miért is nincs jó kezekben az AMD-nél?

• #59 dezz nagyúr misran #58

  Új Válasz 2009-12-13 18:05:44 #59

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz misran #58 üzenetére

  Éppenséggel először (hónapokon belül) az Intel fog kiadni olyan procit, ami egy tokban tartalmaz CPU és GPU lapkát. 2011-ben mindkettőtől jön majd a kettőt egy lapkán tartalmazó megoldás.

  Az Intel a Larrabee-vel éppen most ment neki a falnak... Tényleg nagyon jó irány volt... Azt majd meglátjuk, át tudják-e úgy alakítani, hogy életképes legyen.

  Az AMD, bár kevesebbet költhet fejlesztésre, de kreatívabb... Másrészt jobban rá van kényszerítve, hogy előre meneküljön. Ugyancsak nem elhanyagolható, hogy a kezükben van a jelenlegi legjobb desktop grafikus technológia, amitől az Intel messze le van maradva. (Éppen ezért próbálkoznak más megoldásokkal, de egyelőre nem sok sikerrel.)

Új hozzászólás Aktív témák