Gyurkity Péter

AMD: PCI Express 2.0 kártya már májusban

A csúcskategóriás R600 után a processzorgyártó a középkategóriát szeretné kitölteni, mégpedig egyszerre három fejlesztéssel, RV630 kódnéven. Ezek közül kettő már támogatja a PCI Express második generációját.

A kínai HKEPC saját forrásokra hivatkozva számolt be a három változat áprilisi, illetve májusi érkezéséről. Az RV630 kódnévvel illetett grafikus chipek a középkategóriát hivatottak meghódítani, DirectX 10 és Shader Model 4.0 támogatással, méretes memóriával és tűrhető fogyasztással. Két példány már a PCI Express 2.0-val is megbirkózik, ám ezek sorozatgyártásáról még nincs hír, kizárólag a referenciapéldányok jelennek meg a tavasz végén.

Ez utóbbi két változat "Kohinoor" és "Orloff" kódnéven mutatkozik be a nagyközönség előtt. Az első 512 MB GDDR4 memóriával, 128 bites interfésszel, valamint CrossFire csatlakozóval érkezik, várhatóan ez lesz a kategória legerősebb példánya. Az Orloff 256 MB GDDR3 memóriát és szintén 128 bites memóriavezérlőt kínál, ez tehát már némileg gyengébb és olcsóbb ajánlat lesz. E két kártya sorozatgyártása azonban csak később indul be, a forrás szerint májusban mindössze a referenciapéldányok mutatkoznak be.



A PCI Express csatoló jelenlegi verzióját támogató változat ezzel szemben "Sefadu" néven érkezik, mégpedig 512 MB GDDR2 memóriával. Ezen kártyákról már hiányozni fog a CrossFire csatlakozó, viszont mindhárom fejlesztésen megtalálható lesz a dual-HDCP támogatás több nagy felbontású kijelző egyidejű használata érdekében, a Kohinoor pedig emellett videóbemenetet is kap. A fogyasztást a következő számokkal jellemzik: 128 watt (Kohinoor), 93 watt (Orloff) és 75 watt (Sefadu).

A processzorgyártó a napokban első alkalommal mutatta be az idei évben megjelenő legfontosabb fejlesztéseit, a Barcelona kódnevű négymagos rendszert és az ATI által megtervezett R600 grafikus chipet. A két 200 wattos erőgépre támaszkodó rendszer mintegy 1 teraflopos rekorderedményt ért el, a megjelenés júniusban várható.

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)
  • dez #123
    "(Pontosabban a szabványosan megadott alapérték két ilyen átállítás összege, mégpedig full on-ból full off-ba, és fordítva, mert típustól függően az egyik lényegesen hosszabb lehet, mint a másik.)" --> több értelme lett volna úgy megalkotni erre a szabványt, hogy a kettő közül mindig a nagyobbat adják meg, hiszen az lesz a "szűk keresztmetszet", vagy a kettő átlagát. De ez az összegzés egy hülyeség, hiszen egy szubpixelben egy frissítésnél csak egy változás történik. Na mimdegy. (Egyébként újabban megadják a g2g, azaz "gray-to-gray" értéket is [mert TN, és főleg a VA-sok itt lassabbak, mint fullos váltásoknál], ami már csak egy változás ideje. Ezzel már csak az a bajom, hogy egy szubpixel, amire vonatkozik a dolog, nem szürke. :) Értelmesebb cégek ezt m2m-nek hívják, azaz midtone-to-midtone.)
  • dez #122
    Erről itt megfeledkeztem.

    "A kisebb válaszidejű TFT-k sem mennek nagyobb Hz-n? Csak mert olvastam valahol hogy a 4 ms moncsik több száz Hz-nek felelnének meg vagy ez csak elmélet és nem úgy gyártanak mert minek?"

    A válaszidő ugyebár a folyadékkristály reagálási ideje, azaz amíg egy helyzetből (x intenzitás, azaz itt fényátengedés) átáll egy másikba (y intenzitás). (Pontosabban a szabványosan megadott alapérték két ilyen átállítás összege, mégpedig full on-ból full off-ba, és fordítva, mert típustól függően az egyik lényegesen hosszabb lehet, mint a másik.)

    De az elektronikus frissítésnek is van egy bizonyos sebessége, amikor a szubpixelekhez tartozó kis kapcsolásokat (ezek teszik ki a TFT réteget) beállítják a megfelelő értékekre, hogy utána azok az kellő pozicióba állítsák az oda tartozó folyadékkristályt.

    "Mert akkor 16 ms-moncsinál jobbat nem érdemes venni ha azt is csak 75-re tudod rakni. Mert van nekem is egy 16ms, és egy 8ms moncsim. Mindkettő 75 Hz.... Így nincs értelme nagyon a gyorsabb válaszidőnek:D"

    Van, mert az sem mindegy, hogy az elektronikus frissítés után még mennyi időbe kerül, amíg a pixelek valóban beállnak a kellő színre, intenzitásra. De olyan 1ms alá már tényleg nem nagyon érdemes menni. Egyébként van 85Hz-en hajtható LCD monitor is.
  • lee56 #121
    Ha ez igaz akkor a dx10 az agp végét jelentheti...
  • dez #120
    Egyik ok lehet (amit pár hsz-szel ezelőtt írtam is), hogy a DX10 része az a bizonyos gfx-mem virtualizáció, ehhez meg szükséges a kétirányú nagy sávszél. Persze ettől még elmennének a kártyák AGP-n, de nem lennének full kompatibilisek a DX10 szabvánnyal. Más így hirtelen nem jut az eszembe, de lehet, hogy van egyéb ok is.
  • lee56 #119
    oh hogy azok csak pletykák voltak, akkor rosszul emlékeztem sorry (ettől persze még kiváncsi lennék miért olyan lehetetlen megcsinálni agp-re)
  • lee56 #118
    nVidia is érdekes dolgokat müvel mostanában, miaz hogy egyszer azt mondja lesz, utánna meg meggondolja magát...
  • lee56 #117
    Ez igy van ;)
  • dez #116
    Egyébként a korábbi pletykákra reagálva, miszerint a 8600-asból lesz AGP-s, az Nvidia azt állítja, nem lehetséges, mert a DX10-esek egyszerűen működésképtelenek AGP-n... Mondjuk erre többen felvetették, hogy ez elég érdekes, tekintve, hogy ugye állítólag lábkompatibilis a 6-os és 7-es szériájú megfelelőjével. Szal majd meglátjuk. De tegyük fel, igaz, amit állítanak. Gondoljunk bele, mi lenne, ha most a PCI-E csak egy kisebb piaci részt fedne le (mivel ugye nem lennének az emberek túl motiváltak átállni - ugyanemiatt az itteni lehetőségek kihasználása sem kapna túl nagy prioritást, táhát x év múlva lenne belőle bármi is)! Akkor a DX10 sem jönne ki még x évig, ha egyátalán kijönne valamikor, mert egyszerűen nem érné meg! A DX9-et gyorsítgathatnák, ki tudja, meddig. Az emberek meg közben más érdekesebb elfoglaltság után néznének. :)
  • dez #115
    Nos,
    1. Ha AGP-re ugyanolyan választék lenne, 10 évre húzodna az átállás. Ez tűrhetetlen lenne a gyártók számára, mert kétfélére fejleszteni-gyártani túl drága lenne. Akkor inkább bele sem kezdenének az egészbe, és egy idő után megakadna a fejlesztés.
    2. Régebben eleve nem is volt programozható a GPU (mint ma a programozható shaderekkel, illetve a DX10-esek még inkább), azaz nem is lehetett másra használni. :)
    3. Az Mpeg2 gyorsítás viszont még az AGP idején (persze csak az utóbbi években) jelent meg, mivel az megoldható úgy, hogy ne legyen szükség vissz-irányú adatáramlásra.
  • arty #114
    nem vártam, h megtáltosodik a gép, tudtam h az egész uj szabvány semmit nem ér - de csak pci-e re volt vga választék :( és ez az én főú problémám ... nem zavarna ez az egész, ha mindig lenne alternativa :) (most nem a pci-e2-ről beszélek, ami a kompatibilitása miatt nem gond)

    ha az agp lett volna eddig az akadály gondolod, h kezdetleges gpu használó megoldások nem lettek volna ?? talán lassu processzorra nem irtak még programot? nevicceljünk már ... :) annyi történt volna, h az akkori programok a pcie váltás után jonagyot gyorsulnak. ehelyett semmi nem tötrént, hiszen NEM voltak gpu alkalmazások :)