Keresés

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

  • Abu85

    HÁZIGAZDA

    válasz lenox #77 üzenetére

    A CUDA-t az NV biztos megtartja, mert az asztali piacon túl más a követelmény a HPC szerverek piacán. Ott a CUDA tényleges előny. Csak így lehet ott érvényesülni, mert az OpenCL nem fog olyan ütemben fejlődni, amilyen ütemben az NV építi be a technológiákat a lapkákba. Egy csomó olyan dolog van a Fermiben, ami csak a CUDA-n keresztül érhető el.

    A CUDA a kiskereskedelmi termékeknél fog eltűnni, mert túl sok a konkurens gyártó, és a szoftverfejlesztő nem maradhat egyetlen cég mellett, már csak az anyagiak miatt sem. Most volt a negyedéves jelentés a piacról. A gépek negyedében van CUDA kompatibilis GPU. Ez kevés.

  • Abu85

    HÁZIGAZDA

    válasz lenox #75 üzenetére

    Aki nem veszi meg a CUDA licenszét. A DirectX támogatása nem licenszköteles. Nem mellesleg gyártófüggetlen az API, tehát egy olyan cég felügyeli a fejlesztést, aki nem készít hardvereket a piacra.
    Az nagyon veszélyes, hogy ha egy olyan platform támogatása kerül elő, ami egy a piacon érdekelt cég kezében van. Láthatod a Mafia 2 esetét. A GPU-s PhysX legmegterhelőbb modulja, egy GeForce-szal a CPU-n fut, mert az a jó az NV-nek, ha magas a gépigény. Ezt egy gyártófüggetlen felületen nem lehet megcsinálni, mert eleve versenyhelyzet van.
    Ettől olyat kapott a PhysX a fejlesztők fórumán, hogy a Two Worlds 2-ből és a Breach-ból is kivették a megjelenésre a GPU-s gyorsítást. Most pihen a dolog, mert a PhysX jelenleg antireklám, hiszen az emberek a magas gépigényt kötik hozzá. Az elmúlt év címei alapján egyébként teljes joggal. Onnantól kezdve, hogy GTX 480 kell hozzá, hogy a legalacsonyabb fokozaton eldöcögjön nem nyerő a technológia a tömegpiac számára.

  • Abu85

    HÁZIGAZDA

    válasz lenox #69 üzenetére

    Az AVP egy MLAA-MSAA mixelt megoldást használ. A fejlesztőknek sokkal könnyebb a dolguk egy AA implementálásánál, mert képesek a renderhez igazítani az egészet, és ez jó minőséget ad.
    Amit az AMD rakott a driverbe, az egy teljesen post-process megoldás. A végső kép adja az információt és az alapján dolgozik az egész algoritmus. Ilyet egy játékban sosem fogunk látni, mert a jó eredményhez ennél több információ kell. Ez a megvalósítás csak a driverben jó, mert biztos, hogy ki lesz számolva egy képkocka, és a renderhez az MLAA implementáció nem nyúl, vagyis biztos, hogy nem léphet fel kompatibilitási probléma. Persze ezt lehet továbbfejleszteni, extra információkat szerezni a depth és a normal bufferből, csak ahhoz már profilozni kell a technikát. Az már rosszabb, mert alkalmazásonként alakítani kell rajta. Ezért lenne az a jó, hogy a fejlesztő építené az AA-t a játékba, mert a motorhoz lehet szabni. Minden más megoldás csak tűzoltás, se a képminőség, sem pedig a sebesség nem lesz a legjobb.

    A platform úgy jött ide, hogy az üzleti trendek nem teszik életképessé a PC-s VGA-piacot. Még csak 2011 van, és máris ott tartunk, hogy az idén bejelentett teljes gyártói konfigurációk 65-70%-ban nincs lehetőség a VGA beépítésére. Ez világos, hogy üzleti megfontolás, de ha a mutató tovább romlik, akkor a piac a jelenlegi árazás mellett képtelen megélni.
    Van benne OpenCL is, de a fejlesztőkörnyezet egy dolog, a másik a platform támogatása. Az NV-nek már WHQL OpenCL 1.1-es drivert kellene adni, erre ilyenből még mindig csak béta vagy developer verzió van. A nem szereti, egyet jelent azzal, hogy lassan dolgoznak rá. Az OpenCL nagyon rontja a CUDA pozícióját, és az nem jó.

    A cikk első fele a problémáról szól, amire az AMD talált megoldást az MLAA személyében és le van írva, hogy az hogyan működik. Az NV most szintén keresi a megoldást. Ha csak leírom, hogy az SRAA jön, akkor senki sem tudja, hogy miért. Most többen is értik, hogy baj van az MSAA-val. Megjegyzem nem az MLAA és az SRAA erre a megoldás, hanem a fejlesztőknek kellene gondoskodni egy motorra szabott AA-ról. Képminőségben és sebességben annál nincs jobb.

  • Abu85

    HÁZIGAZDA

    válasz lenox #59 üzenetére

    Az AVP egyik fejlesztőjétől kérdeztem meg. Gyakorlatilag egy dolog számít, hogy hány TFLOPS-os a GPU. Ők dolgoztak MLAA-val, csak tudják. Gondolom ismerik is az AMD megoldását is, hiszen tőlük kapták az AVP-ben használt shaderes AA-t, ami részben MLAA alapú, részben pedig MSAA. A jelenlegi driveres implementáció annyiban különbözik, hogy a végső képen kell dolgoznod, vagyis a renderbe nem nyúlsz bele. A back buffer tárolt képén megkeresed azokat a pontokat, ahol szükség van az AA-ra, ez nagyon számításigényes, majd ezeket az algoritmusnak megfelelően leszűröd. Szintén durván számolni kell. Mivel SM5-ös a kód, így használhatod a LDS-t is, ami valamit gyorsít rajta.

    Üldözési mániád van. :) Mondtam már, hogy nem az én hibám, hogy az NVIDIÁ-nak nincs platformja.
    A CUDA egy zárt rendszer. Szerinted meddig tartható fenn? Írj a PC történelméből egy olyan gyártófüggő felületet, ami levert egy gyártófüggetlen megoldást.
    Egyébként írtam az Intel OpenCL SDK-járól is. Nem csak az AMD fejlesztőkörnyezete van bemutatva. :) Azt meg mind a ketten tudjuk, hogy az NVIDIA mennyire szeretne OpenCL-t.

    Hol van leírva a cikkben, hogy az MLAA jobb? Mutasd meg azt a mondatot. Ha nem bízol benne, hogy az NV jobbat csinál, az nem az én hibám.
    Az AMD egyébként nem csinál jobbat. Nekik arra az alapproblémára, amire az NV keresi a megoldást már van egy fejlesztésük. Ez az MLAA. Benne van a driverekben. Le van írva, hogy hogyan működik, és hogy mi a kontra, ami nem mellette szól.
    Az NV most bejelentette, hogy a fejlesztői dolgoznak egy SRAA algoritmuson. Nyilván látják a problémát, amit az AMD másfél éve észrevett. Nevezetesen az MSAA már nem jó megoldás. Most tesznek ellene valamit. Szintén le van írva a hírben, hogy mi lenne az elképzelésük.

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

Hirdetés