Informatika és tudomány

Gyurkity Péter

Megjelent a Radeon HD 3800

Mától kapható az ATI-AMD új zászlóshajója, amely rögtön két inkarnációban érkezik, Radeon HD 3850 és 3870 néven. Fejlett gyártástechnológia, magas órajel és aránylag tűrhető fogyasztás jellemzi a kártyákat.

Az AMD oldalán már megtalálhatjuk az új sorozatot bemutató külön lapot. Ezen többek között közlik a grafikus chip fontosabb technikai részleteit, a támogatott technológiákat, ám számunkra természetesen az a legfontosabb, hogy melyik gyártó milyen kiszerelésben és főleg milyen áron dobja majd piacra saját változatait. Ez ugyan még nem teljesen világos, ám a technikai specifikációt megismerhetjük.

Az 55 nanométeren készülő RV670 chip tehát két változatban jelenik meg. A HD 3850 és 3870 gyakorlatilag a korábbi Pro és XT változatoknak felelnek meg, hiszen kettejük között mindössze az órajelben, a memória típusában és méretében, valamint a külsőben találunk eltérést. A 666 millió tranzisztort és összesen 320 stream processzort magába foglaló mag az első változaton 670, a másodikon pedig már 775 MHz-en fut. A HD 3850 256 MB GDDR3 memóriája 900 MH-es órajelen, a HD 3870 512 MB GDDR4 memóriája pedig 1,2 GHz-en érkezik. Mindkét változat PCI Express 2.0 csatolót kapott.


A "gyengébb" változat fogyasztása csúcsjáraton 98 watt, ez egyetlen bővítőhelyen elfér, tehát némiképp visszafogott hűtéssel szerelik fel - legalábbis a referenciapéldányokat. A 3870 azonban már dupla helyet elfoglaló monstrum hűtést kapott, fogyasztása pedig 106 watt. A két mintapéldány dual-link DVI és HDTV-Out portokkal rendelkezik, támogatják a HDCP-másolásvédelmet, vagyis egy átalakítóval akár HDMI-csatolójú készülékre is rádughatjuk őket - ebben az esetben a hang a HDTV kimeneten érkezik.

A PowerPlay energiatakarékossági technológia révén a kártyák három üzemmódban működhetnek, ezek sorrendben: general (általános), light gaming és intensive gaming. Az első esetben a fogyasztás 26 és 39 watt, a középső üzemmódban pedig 34 és 51 watt. A harmadiknál az "ami a csövön kifér" elv érvényesül.

Több forrás 150-200 dollár körüli áron várja a kártyákat, ám a hivatalos adatokra még várni kell.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • kisgabo #65
    jöhetne, mert vicc ami a 8800GT körül megy, pár tesztpéldány, meg 20 db az országba.. röhej. karácsony előtt.
  • And01 #64
    Mondjuk radeont veszek én is,de per pillanat sem a dx10-nek
    sem a 10.1-nek nem sok értelmét látom ameddig a Vista nincs
    elterjedve 5-10%.
    Ráadásul a játékfejlesztőknek nem lenne jó bolt csak
    kis piaci részesedésbe ágyazni egy játékot {a mai programozási költségeket
    figyelembe véve}
    Ameddig meg dx9-en is kijön minden nem éri meg váltani!
  • dez #63
    A DX10 is a Vistához kötött, mégis van DX10 támogatás pár új játékban. Persze a Vistán játszók a piac egy kis része, és amíg csak az ATI támogatja, a 10.1 még ennek kb. fele. Amíg így marad, nem nagyon fogják támogatni, de valószínű, hogy az Nvidia köv. GPU-ja (ami nem csak a G80 shrinkje, mint pl. a G92) is támogatni fogja.
  • And01 #62
    A dx10.1 akkor érne sokat ha kiadnák xp-re is.
    A Vista jelenlegi elterjedését figyelembe véve a játékfejlesztőknek
    gondot okozhat hogy dx10.1-el készítenek játékot,de az
    oprendszer nem elég elterjedt hogy megfelelő mennyiséget el
    tudjanak adni.Az sp1 növelheti az elterjedést,kérdés hogy ez
    elég-e?
    Csak játékra 30000ft-os opendszer drágának tűnik,minden másra meg elég az xp.
    /ez az én véleményem/

  • dez #61
    Why DX10.1 matters to you
  • duke #60
    tok bena,ki akarna ma hajszaritot epiteni a gepebe ?
  • dez #59
    Na, kicsit olvasgattam DX10 vs. DX10.1 témában, és hát az a fejlesztők véleménye (Nvidiás cenzorálás nélkül), hogy a DX10.1 az, aminek a DX10-nek kellett volna lennie eleve. Hatalmas különbség nincs, de sokmindent egyszerűbben, és valamivel gyorsabban lehet megoldani vele. Valószínű lesz a későbbiekben megjelenő játékokban DX10.1 mód, ami néhány százalékkal gyorsabb lesz, és talán itt-ott picivel szebb.

    Idézek egy véleményt:
    "For my point of view DX10.1 has lots of really useful features. Our new renderer is a fully deferred one, and DX10.1 seems to have focused on improving the shortcomings on that side.

    Subsample reading allows me to finally do proper antialiasing. Currently we need to either do a edge-detect blur filter in post process pass, or render everything in 2x1 (or 2x2) resolution and downsample the result in combine pass (or both for best quality). Subsample reading both improves the AA quality and speeds up the rendering, and it helps the shadow map rendering as well. This is the hands down biggest feature in DX10.1.

    Separate blend modes for MRT is also useful when rendering complex volumetric effects to deferred buffers (you need separate blending modes for particle normals, volume density accumulation and other parameters). But it's not that important for basic rendering. I can easily life without it (and most likely we spend resources on something else instead of it).

    It's also good that they finally properly support Gather4, instead of the current Fetch4 hack implementation. We are using Fetch4 in lots of our post process filters, so it's a good thing to have it in DX10.1 feature list. Soon all the Fetch4 optimizations will be usable on Geforces as well (or I am hoping so at least).

    For me cube maps in texture arrays is just a small and natural incremental feature addition to the texture array operation. It can be used improve ambient lighting quality, but storing huge amount of cubemaps is going to consume a lot of memory, and is not going to feasible in most real games (compared to a small one room ATI techdemo). It's a fun feature to play around with in the future, but certainly not something that resolves the whole realtime global illumination problem, like PR and marketing departments like to say :)"
  • dez #58
    VLIW
  • dez #57
    Nem a WLIV itt a lényeg, hiszen az R6xx is WLIV-s (illetve az főleg az), hanem a SIMD végrehajtás (de nem egy szálon belül, hanem mindegyik elem más-más pixelre/vertexre/stb. dolgozik), miközben az R6xx superscalar egységekből épül fel. Bár itt "SIMD Arrays"-nak nevezett tömbök épülnek fel belőlök, de ez csak annyit jelent, hogy egy ilyen tömb ugyanazt a programot hajtja végre, más-más pixelekre/vertexekre/stb., de minden superscalar egységnek van saját branch egysége.

    A 24 bites FP már az ATI/AMD-nél is a múlt, az R6xx óta. De nem tudom, hogy akár itt, akár Nvidiánál ez a filteringre is vonatkozik-e (amit leginkább a textúra-egységek csinálnak).

    "de akkor 1 orajel helyett kb. 50-100 orajelet igenyelve"
    Ez a gyakorlatban olyan, mintha nem tudná.

    "Mashol mar leirtam, de az igazan jo megoldas az altalanos processzorok bevezetese lenne."
    Mintha nem tudnád, hogy az Intel Larrabee-je pont ilyen lesz.

    "Ha a gpu magok altalanos skalar vliw processzorokkent mukodnenek (tehat 1 control unit, 1 aktiv szal alapon), akkor ki lehetne hagyni a jelenlegi texturakezelo es raster operation aramkoroket is"
    Nem egészen értem a kettő közötti összefüggést.

    "csak az alu-k szamat kellene kb. a duplajara novelni es minden szalnak sajat vezerloegyseget adni."
    Utóbbi annyival növelné meg a méretét, hogy nem hogy több, de még ennyi sem lehetne. A Larrabee-ben is csak kb. 24 mag lesz, egyenként egy SSE szerű egységgel.

    "(intel sse eseten ez csal 4)"
    Nem, az SSE egy szálon dolgozik, csak egyszerre 4 32 bites adattal (vagy 2 64 bites, vagy 8 16 bites).
  • kvp #56
    "Ennek akadálya most az, hogy a GF8xxx-es széria valamiért nagyon gyengén muzsikál ebben. Közben az ATI alaposan rágyúrt erre, de így egyelőre feleslegesen."

    Nem olyan rossz a gf8xxx-as szeria, csak a akkor lassu, ha adat vagy feltetel vezerelt a ciklusszam. Ilyenkor a 16 alus (szalas) mag csak 1 szalon folytatja a vegrehajtast, tehat 16-odara lassul. Igy mar 128 helyett csak 8 szalon tud futni. Ez minden vliw architekturanak az atka, pl. ettol nem olyan jo az itanium uzleti logikaban. Tehat dinamikus elagazasoknal, ha azok nem linearizalhatoak ki, akkor 16-odara, ha linearizalhatoak akkor egymasbaagyazott if-enkent kb. felere csokken a teljesitmeny (1/8-adig ahol feladja a fordito a linearizalast). Az ati eseteben ezek a butetesek nem ervenyesulnek annyira, mert tobb darab de kevesebb alu-t iranyito mag van. Igy viszont az ati-k a nyers erovel vegezeheto vektorfeladatokban gyengek. (tehat shader model 1-2 hasznalata eseten)

    Egyebkent a 32 bites lebegopontos teljesitmeny eddig is megvolt nvidia eseten is, csak az ati hasznalt 24 bitet, meg a dx9c idejeben. A szabvanyositasban mar rosszabbul allnak, ugyanis az nvidia fele negyzetgyok hiresen pontatlan, kb. 14 bites, a tobbi bit csak linearisan interpolalt. Ha tenyleg teljes lebegopontos precizitas kell, akkor az alu-kat ujra kell tervezniuk, de a fuggvenykezelo aramkoroket mindenkeppen.

    A cube map array-k pedig kezelhetoek geometry partitioning-el, mar a voodoo2-re is voltak ilyen demok. Az egyetlen kulonbseg, hogy akkor meg a processzor vegezte el ezt a vertex valogatasi muveletet, mig most a shader kepes ra. Egyebkent a gf8800-as sorozat is tudja kezelni oket, csak lassabban es array elemenkent egy texture slot-ot fogyasztva, vagy shader-bol, de akkor 1 orajel helyett kb. 50-100 orajelet igenyelve. (ilyenkor shader-bol emulalja a texturazo egyseg szuroit) Ugyanez vonatkozik az uj szurokre, amiket kepes kezelni egy gf8800-as is, csak eppen sokkal lassabban. Viszont a bloom-ot eddig is ezzel a szoftveres trukkel rendereltek es cuda alatt lehetoseg van a teljesen szoftveres textura kezelesre is, linearis adattombokkent kezelve a memoriat. (mint a voodoo vagy wildcat kartyakon)

    Mashol mar leirtam, de az igazan jo megoldas az altalanos processzorok bevezetese lenne. Ha a gpu magok altalanos skalar vliw processzorokkent mukodnenek (tehat 1 control unit, 1 aktiv szal alapon), akkor ki lehetne hagyni a jelenlegi texturakezelo es raster operation aramkoroket is, csak az alu-k szamat kellene kb. a duplajara novelni es minden szalnak sajat vezerloegyseget adni. Most egy gf8800-asban 8 vezerloegyseg van (8 magos), de 16 szalu a parhuzamositas (intel sse eseten ez csal 4). Mindez a jelenleg is meglevo altalanos linearis memoriainterface-el, eleg szep eredmenyeket adna es akar c++ kod is futhatna a gpu-kon kulonosebb optimalizacio nelkul. Az egyetlen problema a memoria elerese lenne, de ezt egy osztott L2 cache-el kezelni lehetne, mivel most kb. 1KB a lokalis memoria szalankent es 16KB magonkent. Ez kb. a regiszterternek felel meg. A cache hianya pedig a beepitett smt rendszerrel lett kikerulve, tehat amig a fo memoriat olvassa vagy irja egy szalcsoport addig egy masik fut. (dinamikus elagazasnal pl. a memoriamuveletek sem parhuzamosithatoak, tehat ilyenkor csak 1 szal kepes egyszerre memoria i/o-t vegezni, ami lassu) Az nvidia ezt a full crossbar memoriavezerlovel korrigalja, ami sokkal gyorsabb mint a ringbusz, viszont a jovoben nem igazan skalazhato.
További bejegyzések a fórumban...