Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz user++ #40 üzenetére

    Szerencsére nem. A DX11 az utolsó releváns API. Innen igazából nincs tovább ezzel a futószalaggal. :N Még a tesszellálást meg lehet csinálni 100%-osan programozhatóra, de nincs értelme.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz antikomcsi #49 üzenetére

    Persze. Betör a szoftver render az új konzolokkal és megint mehetünk vásárolni. ;]

    Nekem könnyű dolgom van. DX fronton most az MS jól teljesít. :D

    SGábor: csak egy klasszikust tudok idézni: When it's done ;] ... Amúgy már mérjük az eredményeket. Egyelőre a hétfő az esélyes, de ne vegyétek készpénznek, hisz bármi közbejöhet.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz #06658560 #54 üzenetére

    Az OpenCL a szokásos. Bár az AMd a FirePro felé szeretné terelni a prof felhasználást. A Radeon csak játékra van.
    PC-re a GPGPU jó, de a HPC piacra tuti nem neveznek vele. Ott nincs sok esélyük a Larrabee, meg az új NV ellen. :)

    fordfairlane: Nem tom. Az MS még erről nem nyilatkozott, de a Windows Update-en frissül majd a rendszer DX11-re.

    rudi: fLeSs-nek ez rutinmunka. Percek alatt lezavarja. :))

    cowboy_bebop: Na az jó dolog. :D

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz max-pain #84 üzenetére

    Itt inkább az a lényeg, hogy a fejlesztők kaptak egy olyan API-t, amire megírhatják a teljes kódot szabványosan és onnantól kezdve a munka lezárva, mert mindent elintéz az API. Ezt kérték az MS-től. Az XP-t zokszó nélkül elhagynák, de a DX9 és a DX10-es fejlesztés együtt rendkívül idő és erőforrásigényes. Most sokkal kevesebb pénzből csinálják meg ugyanazt. Az XP-n is el lehet indítani minimális munkával a DX11 kódról levágott részeket. Igaz, hogy ronda és lassú lesz, de futni fog. Minden a fejlesztő döntésén múlik. :)

    Gabás: a gyakorlatiban is ... a belső tesztek alapján a régi tesszellátorok nem sebességbajnokok. A fejlesztők a High Poly és a Detail tesszellationra ugrottak rá, aminek azért van erőforrásigénye. Esetenként jobban jár a kártya Parallax Occlusion Mappinggal. A DX11-es megoldás már gyors.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz user++ #98 üzenetére

    De itt senki sem beszél anyagi kiesésről. Ugyanúgy lesz támogatva az XP, csak egy csomó effekt kimarad a renderkódból. Ha szebb játékot akarsz, akkor váltanod kell, ha meg nem, akkor maradhat az XP is. A játéktesztelők nem nagyon foglalkoznak a kérdéskörrel. Ők tartják a lépést a kórral, mert a játékot a legszebb beállításokon kell megítélniük. A grafikai butítások a gyengébb géppel rendelkezőknek szólnak. :)

    ollie: Nem kötelező XP-t sem váltani. Lehet kreálni natív DX9 kódot is a DX11-ből, csak ki kell vágni a nem kompatibilis részeket. A STALKER Call Of Pripyat is ilyen lesz. Bár a ruszki verzió nem fut XP-n a véglegesre már ez sem lesz akadály. Persze grafikában eltűnik a komplett megvilágítás, és még lehet sorolni ... cserébe 200 FPS-sel fog szaladni, persze ez a mód a DX9-es karikhoz készült. Akinek DX10+ karija van, azt feltételezik, hogy vált a szebb látványvilágért. Ha meg nem, akkor nem. Futni fog a program akkor is. :)

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz zuchy #185 üzenetére

    DX10.1-re készült eddig, de ha jól tudom most pénzelt bele az NV. Így már borulhatnak a dolgok. :D

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz DriderG #190 üzenetére

    A Vec 4 egy négykomponenses vektor utasítást tud végrehajtani, míg a Vec3+skalár párhuzamosan számol egy háromkomponenses vektort és egy független skalár utasítást. A Vec4 utasítást szét lehet bontani egy Vec3+skalárra, ami kihasználásban már jó. De ha a Vec3 és a skalár utasítás megy a Vec4 ALU-ra, akkor az két órajel lesz, mert nem lehet egyszerre végrehajtani a kettőt.
    A mátrix szorzást először le kellene bontani utasításokra és akkor kiderülne mely egységek dolgoznak. Ezt így nem lehet röptében megmondani.
    Az SFU egységek a G80 és az R600 óta tudnak mindkét rendszeren általános utasításokat a speciális mellé, de a régebbi rendszereknél ez nem volt így. Ott többnyire sin-cos fügvényekre voltak, ésatöbbi.
    A G80-G200-ban a shader processzor az skalár. A rendszer elve Stream alapú, így a TPC-k komponensfolyamokon dolgoznak. :)

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz DriderG #196 üzenetére

    Igen ... felfogható úgy, de nyilván a négy komponensen ugyanaz az utasítás fut le. A G80-G200 a vektor utasításokat szétbontja skalárra. Ezeket futtatja a skalár procikon. Gyakorlatilag az eredmény ugyanaz. Azt viszont érdemes megjegyezni, hogy streaming elven működnek. Erről a reformok korában írtam:
    Egy TPC tartalmaz egy textúrázó blokk-ot és két Streaming Shader Processzort. Fontos, hogy a Shader Processzorok nem a GPU órajelén dolgoznak, hanem az úgynevezett Shader órajelen, emellett a TPC-n belüli szálvezérlésről is ők gondoskodnak. A Shader processzoron belül 8 darab általános Stream processzort találunk, amelyek logikailag négyes csoportokra vannak osztva. Ezen csoportokhoz tartozik egy-egy Speciális Funkció Egység (SFU). Az efféle felépítés újdonság a GPU-k világában. A régebbi rendszerek főleg vektoros egységeket tartalmaztak. Az új elrendezés alapvetően módosítja a feldolgozás folyamatát is. Az adatok mostantól úgynevezett komponens folyamonként érkeznek feldolgozásra. Az elnevezés egy kicsit ijesztően hangzik, de nézzük meg a gyakorlatban, hogy miről is van szó. Példaként most elemezzünk két rendszert pixel számítás alapján (vertex esetén is hasonló a működés). Tudjuk, hogy egy pixel 4 elemből áll (piros, zöld, kék, átlátszóság), ezen elemek értékei alapján kapjuk meg a végső pixel színét. A G70, az architektúrája szerint 4 pixelt számol egy futószalagon. Ez összesen 16 elemet jelent (4 pixel és pixelenként 4 elem). A G80 ezzel szemben 16 pixelnek egy elemét számolja egyszerre egy TPC futószalagon (lehet ez akár piros, zöld, kék vagy átlátszóság). Az elméletet terjesszük ki 16 pixelre. A G70-nek ezen feladat számításához egy futószalagon 4 ciklusra lesz szüksége (minden ciklusban számolunk 4 pixelt, azaz összesen 64 elemet). A G80-nak egy TPC blokk-on szintén négy ciklusra van szüksége, mivel négyszer számolja 16 pixel egy elemét (összesen 64 elem). Első ránézésre nincs különbség a két architektúra közt, de ne kapkodjuk el a dolgokat. A valóságban igen sokszor előfordulnak olyan Pixel Shader kódok ahol nincs szükség a számításhoz mind a négy komponensre. Ilyen esetben a G70-nek mindenképp szükséges a 4 ciklus lefuttatása, mivel a Shader egység különböző komponenseket számol. Abban az esetben, amikor az átlátszóság információi nem szükségesek, a Shader egység elméleti teljesítménye kihasználatlan marad. A G80 esetében egészen más a helyzet. Például ha nincs szükség az átlátszóság információira, akkor a negyedik ciklus egyszerűen nem fut le. Eredmény szempontjából ugyanott van a két feldolgozási elv, viszont a G80 három pixel elem számításánál mintegy 25%-al hatékonyabb. Minél kevesebb pixel elemre futtatjuk a Shader kódot, annál kevesebb ciklus fut le a G80-on.

    Igazából négyes csoportban állnak és ezekhez kapcsolódik az SFU. A vektor ide nem jó szó, inkább Stream csoport, amúgy maguk az egységek skalárak. Az SFU speciális utasításokra van, plusz ideális esetben tud egy MUL-t, de annyira nem magas ennek a kihasználtsága.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz gbors #198 üzenetére

    Ezt az AMD-től kérdeztem meg, tehát tuti az infó. :K
    Igazából a rajz az csak szemléletes (vagy félrevezető ... kinek, hogy tetszik :D ). Valójában egy okosított raszteres egység van csak, aminek a scanline conversion motorja van kigyúrva, de a triangle/clock az továbbra is 1 háromszög. Az AMD szerint ez elég a hatékony tesszelláláshoz. A 2 triangle/clock azért gázos, mert konkrétan dupla Graphics Engine-t követel, és még az ütemezést is hatékonyan kell összegyúrni. Ennek 100 milliókban mérhető a tranyóigénye.

    Keldor papa: Egy valag pénzért sokan pacsiznak. ;)

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz DriderG #205 üzenetére

    Általában címfordításra használják az SFU MUL-t. Másra sajnos nem nagyon lehet. :B
    Az ütemező dönt a kérdéses esetekről. Nyilván ha skalár az utasítás, akkor jobb a skalár ALU-t használni, hiszen hátha lehet mellette egy független vektor utasítást nyomni.
    Egy utasításban lehet több operandus. Nyilván a vektor száma nem az operandusokra, hanem az utasításokra vonatkozik.
    Az SFU az butácska volt a régi rendszerben. (Bár ez az extra MUL sem nagyon volt használva, nem véletlenül került ki.)

    gbors (#206): Igazából az AMD sem tagadja, hogy képezhet szűk keresztmetszetet (mondjuk ezen nincs mit tagadni, a napnál is világosabb. :D ). Gondolom az a temérdek tranyó, ami kellett volna a két tri/clock-hoz nem fért volna bele a Sweet Spot stratégiába. Inkább a könnyebb oldalról közelítettek ... kis befektetéssel izmosítottak. :)

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz x-calibur #216 üzenetére

    Grafikailag semmi sem változik. A sebesség pedig attól lehet lassabb, hogy esetleg erősebb az új generáció paraméterszinten. Ami előny, hogy a HD 5000 már tud RGSSAA-t, így minden játékban működik az élsimítás.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz tzsolesz #219 üzenetére

    Tekintve, hogy az erőforrás igényes effekteket be sem lehet kapcsolni, így nem fog rosszul szerepelni.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz rocket #222 üzenetére

    Azokkal a játékokkal működik az SSAA, amikre a driverben van engedélyezés. Nemrég került fel a Dead Space a támogatott játékok listájára. Gondolom még nem jutottak el a Wolf-ig. :)

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz rocket #224 üzenetére

    Persze. Hiszen az RGSSAA működése speciális az új DX verziókkal. Másképp nem lehet megoldani. Eleve ez az egyetlen lehetőség az élsimításra a Deferred Rendering játékokban. DX9-en és OpenGL-en fog működni az opció, de a Deferred Rendering játékokra csak tesztelés után lesz ráengedve. Esetleg ha nem jó az eredmény, akkor külön profil is kell.
    Amelyik játék MSAA-t is tud, arra nyilván nem kell majd tesztelés, hiszen a kompatibilitás valószínűsége nagy. :)

    Ha nem így működne nem lenne eredménye a Dead Space alatt. A képek alapján pedig aktívnak látni az élsimítást.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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