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

• #9278 HSM félisten daveoff #9271

  Új Válasz 2015-02-10 19:04:34 #9278

  Ú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

  

  HSM

  félisten

  válasz daveoff #9271 üzenetére

  Én egy fórumtárs kérdésére válaszoltam, Te kötöttél bele.

  Szerinted a High beállítással nem adtam elég előnyt a DX módnak? Nem is értem, mi van veled... Nyilván Ultra-n a DX-nek esélye se lett volna a Mantle-s 70-90FPS-el szemben 50-70-el.

  (#9272) stratova: Szerintem nem ehhez van köze. Amúgy csináltam még DX-el ilyeneket, és rendben volt teljesen. Komplett meccseket értékeltem ki többféle pályán is utólag LOG-okból. A Mantle előnye másban volt szerintem.

  (#9273) NetTom: Van bizony ilyen téren előny az Nv részére. PL. BF4-ben Nv-vel jó az FPS Ultrán is multiban DX alatt, míg AMD-n nekem már procilimitem volt több helyen is, ezért kellett vissza vegyem High-ra. A procilimit annak ellenére volt, hogy egy 4,4Ghz-re húzott i5 4690K volt a gépemben, 4*4GB 2133MHz-es rammal.
  Ugyanakkor nem hiszem, hogy ez jelentős hatással lenne más paraméterekre, mint pl. a DX-mód input lagjára. Sőt, egyes források szerint az Nv 5 képkockával dolgozik előre, míg az AMD DX alatt csak 3-al, Mantle alatt 1-el, de ezt se megerősítő, se cáfoló bizonyítékot nem sikerült még hoznia senkinek.

  (#9274) gbors: Pedig a nagyobb tranzisztorsűrűség amellett, hogy valóban nehezebben hűthető csipet eredményez, rövidíti a vezetékhosszakat, aminek kapcsán csökken azok parazita-kapaciása, ami direkten csökkenti a csip fogyasztását. Ez tény.
  A 285 szalmabáb érvelés, ugyanis én a Tonga GPU-t említettem, NEM a 285-öt, amire a selejtesebb csipek kerültek, atom túlfeszelve. Nézd inkább az R9 M295X-et.

  Már bocsánat, de pl. az ütemező compilerbe költöztetése pl. nem erős butítás? Dolgozzon a proci inkább többet az ütemezéssel? Vagy a belső erős ringbus helyett egy sokkal "korlátozottab" crossbar felépítés, ahol csak meghatározott utakon járhat az adat?

  "az volt az alapvető felvetésem, hogy az architektúrás innovációt az AMD nem tudja kézzelfogható előnyre váltani. ezek szerint egyetértünk? "
  Alapvetően igen. De én úgy gondolom, nem az AMD "nem tudja" előnyre váltani, hanem a piaci viszonyok nem teszik számára lehetővé, hogy megtegye.

  (#9275) namaste: Ha már tévedések...
  " A Hawaii hiába rendelkezik több DP számolóval, ha nem használjuk nem fogyaszt,"
  De fogyaszt. Mivel ott van a csipben a képesség, növeli a vezetékhosszakat, bonyolítja a logikát, ezenkívül kérdés, mennyire lehet/nem lehet kikapuzni a hozzájuk tartozó részeket, ha egyáltalán lehet.

  A memóriacsipes dolog valós. Legjobb tudomásom szerint a csipek száma és az órajel számít. Kérdés, melyik mennyire. Szerintem a Maxwell ebben is hoz jópár wattot.

  A Maxwell-re sem írhatod, hogy "többet tud", mint a Kepler (feltételezem, a 780-akra gondoltál Kepler alatt) bizonyos szempontból többet, de más szempontból jóval kevesebbet. Pl. egyáltalán nem tud értékelhető duplapontosságot, mivel kihagyták az egységeket. Az sem véletlen, hogy HPC piacra nem Maxwell-t hoztak ki, hanem kicsit feltuningolt Keplert, a GK210-et. [link]

  A priorizált adatutakban én is látok buktatókat, bár eddig a számok szerint jól teljesít.

  (#9277) Abu85: Igen, pont itt látom a nehézségeket. Most DX11-ben tök jó ez a priorizált adatbusz móka, de mi van akkor, ha valami fejlesztő kitalál valami eljárást, amihez egy szokatlan egység részeredményére van szüksége egy másiknak? AMD-n látszólag ez nem okozhat gondot, hogy egymás adatait elérjék, míg Nv-n a megoldhatatlan kategóriát is súrolhatja.

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