Az AMD szerint a DirectX "mondjon le!"
2011-03-22T11:22:36+01:00
2011-04-10T08:15:15+02:00
2022-07-24T16:46:22+02:00
  • Majd ha lesz kedve, akkor valaszol ra :) .

    Compute shader... Jatekok ala jo lehet, bar most hirtelen nem tudom mivel butabb, mint az opencl (a legtobb lenyeges feature bennevan). A legnagyobb elonye, hogy kozvetlenul kepes a dx11-es resourceket, texturakat stb-t hasznalni, nem kell mindenfele faramuci modon regisztralgatni a cuda / opencl context-el.

    Legnagyobb hatranya, hogy legalabb egy vista kell hozza...

    ui.: CUDA-nal nyilvan sokkalta butabb, de attol meg az opencl is fenyevekre van.
    Mutasd a teljes hozzászólást!
  • Szerintem 500 ezerre gondolt, bár kinek mi a gördülékeny. Egyébként, ha már cuda, meg opencl szóbakerült a compute shader az nem játszik?
    Mutasd a teljes hozzászólást!
  • 500 háromszög gördülékeny raytracingre? Tesztelsz is, vagy csak hasraütsz? (bőven efölé lehet menni, tapasztalatból mondom...)
    Mutasd a teljes hozzászólást!
  • A bank conflict tényleng szívás.
    Mutasd a teljes hozzászólást!
  • Elnézést fáradt vagyok.
    Természetesen OpenCL(és bármilyen GPU-n végzendő feladatnál) a lehető legtöbb mindent átviszünk a videokártya "global" memóriájába. Ez az a nagyméretű memoriája a videokártyának(1-2-3 GB) De ezenkívül van még "cache" memoriája, ami OpenCL-ben "local memory"-nak hívnak(cuda-ban shared) Ebből is szűkösség van.
    És gördülésmentesen menjen természetesen egy raytracing program, nagyjából erről volt szó.
    "párhuzamos ugyanarra a memóriarészre való hozzáférés"=a work itemek ugyanrról a memóriacímről olvasnának(bank conflict)
    Mutasd a teljes hozzászólást!
  • "párhuzamos ugyanarra a memóriarészre való hozzáférés"
    Itt most az átvitelről beszélsz vagy az osztott erőforrásokról?

    "GTX 460-nal 500 háromszöggel lehet sima gödülésmentesen elérni."
    mit?
    Mutasd a teljes hozzászólást!
  • Nem az a probléma. A párhuzamos ugyanarra a memóriarészre való hozzáférés, meg a szűkös memória is gond.
    Óriási csalódás a GPU-k mint párhuzamos processzorok teljesítménye. GTX 460-nal 500 háromszöggel lehet sima gödülésmentesen elérni.
    Ja és ne felejtsem el NAGYON érzékeny az elágazásokra, minélél több if-et, vagy ciklust tartalmaz a kód, drasztikusan csökken a teljesítmény.
    Hogy jobb sebességet csikarj ki, fel kell szaggasd a kódkernelt több részre, és el kell rugaszkodni az átláthatóságtól is.
    Mutasd a teljes hozzászólást!
  • Ööö, mondjuk igen. De ha jól rémlik (legalábbis mantraban), per vertex shading történik csak, minden köztes automatikusan interpolálódik. Nagy előnye, hogy nagyon jól lehet geometriát streamelni, és relatíve kevés memóriás rendszerek is tudják használni. (klasszikus prman használat, 8 magos gép 8-16 giga rammal, és futtat 8 rendert párhuzamosan)

    Hátránya, hogy lassú a raytrace (javítgatják a pixarosok, de még mindig lassú), és nagyon nagy terhelést ró a pipeline-ra (sok előgenerált ptc, shadow map stb).

    Ami érdekes, hogy bárki aki teheti raytracert használni (arnold v v-ray, mental ray elvétve de kezd háttérbe szorulni lassan), de a pixar valahogy ezt nem veszi észre...

    A mostani videókártyák a tesszaláció miatt lehetnek egyre jobb REYES renderelők. (ptc visszaolvasás már mehet simán, a többi meg 1:1 mappelhető, talán a deep shadow mapek kissé nehézkesebben ;) , bár ott is inkább a layeres generálással van para, nem a visszaolvasással)
    Mutasd a teljes hozzászólást!
  • OpenCL-el is pont az a para szerintem h. a gpu-s végrehajtáshoz át kell tenni az adatokat videókártya memóriájába.
    Mutasd a teljes hozzászólást!
  • Értem, így világos.
    Mutasd a teljes hozzászólást!
  • Ehhez kb. annyira értek, hogy hallottam róla 4-5 mondatot .:)
    Úgy tudom, hogy a primitívek azok paraméteres görbe felületekként vannak a modelben tárolva, és van olyan művelet, hogy tesszelláció, ami gyorsan on-the fly icipici poligonokat gyárt le belőlük (framenként?). Nyilván a kamera pozíciójától függő méretűeket, így biztosítani tudja, hogy egyik pici poligon se legyen nagyobb mint egy pixel. De sirpalee pl. biztos ezerszer jobban tudja.
    Mutasd a teljes hozzászólást!
  • amikor a minden poligon pixel méret alatti


    Ez pontosan mit akar jelenteni? Ha a kamera a (0,0,0) pozícióban van, a poligon pedig az (1,1,1)-ben, akkor más méretűnek látszik, mint ha a kamera a (0.99,0.99,0.99)-ben van. Nem?
    Mutasd a teljes hozzászólást!
  • A REYES az a mikropoligonos cucc, ugye, (amikor a minden poligon pixel méret alatti.)? Ehhez mennyire passzol a DirectX?
    Mutasd a teljes hozzászólást!
  • Igen, azt én sem értettem az interjúban, hogy akkor miért nem jó a CUDA meg az OpenCL.
    Mutasd a teljes hozzászólást!
  • Itt az általános programozhatóságról beszél:

    and I guess it was actually the primary appeal of Larrabee to developers – not the hardware, which was hot and slow and unimpressive, but the software – being able to have total control over the machine, which is what the very best games developers want. By giving you access to the hardware at the very low level, you give games developers a chance to innovate, and that's going to put pressure on Microsoft – no doubt at all.'


    Erről nekem az jutott eszembe, amikor Tim Sweeny beszélt arról, hogy szerinte a jelenlegi pipeline még a programozható shaderekkel együtt is szűk architekturális keretszmetszeteket mutat, és hogy a jövő GPU-ja általános masszív parallel számítógép, szerinte a renderelés a távoli jövőbe nlegalábbis teljesen szoftveres lesz.

    Itt a Link:
    http://www.ubergizmo.com/2009/08/tim-sweeney-the-end-of-the-gpu-road..

    Onnan vezet link egy PDF slide-ra, ott konkrétan írja a jelenlegi pipeline szűk keresztmetszeteit, de nekem ez már túl szakmai, én ebben ennyire nem vagyok benne.

    Viszont nem egészen értem, mert ok, hogy nem kell a DircctX, de a Cuda sőt az OpenCL az sem jó? Miért nem használják azt? Szal' lehet, hogy inkább arról van szó, amit te mondasz.
    Mutasd a teljes hozzászólást!
  • Aki nem a hagyományos renderelési technikákban dolgozik úgyis cuda-t vagy opencl-t használ, az meg kellően alacsonyszintű. Szenvednek is vele rendesen a fejlesztők...

    A game enginek nagy része még mindig rasteres engine, bár egyre jobban kezdenek REYES szerűvé válni, amivel ellesznek még pár évig azért... De más területen meg látszódik durván, hogy az fejlesztők / felhasználók menekülnek a REYES-től.
    Mutasd a teljes hozzászólást!
  • Amikor már a felparaméterezett shader fut már nincs gond, én arra tippelek, hogy a 'HAL Device - DDI' kommunikációja okozza a teljesítmény csökkenést. Viszont ha ez a helyzet, akkor az eszközmeghajtó program direkt programozása önmagában nem fog gyorsulást okozni.
    Mutasd a teljes hozzászólást!
  • Nem az az egy két órajel az érdekes, nem mikrooptimalizálásról van szó, hanem általános programozhatóságról, az engined architektúrájáról, a választott renderelési technikáról. Most nagyon leegyszerűsítve a GPU-k szinte szuperszámítógépek, amiket egy nagyon speciális módon tudsz elérni a DirectX-en keresztül, mintha speciális háromszögraszterizáló szörnyetegek lennének. Ha közvetlenül éred el a GPU-t, akkor nem hagyományos technikákban is gondolkodhatsz, másképp építed fel az engine architektúráját, stb... Szvsz. inkább erről van szó.
    Mutasd a teljes hozzászólást!
  • Carmack speciel OpenGL-ben nyomja.

    Banderas:
    "Szerintem nem is mondott butaságot..."
    Véleményem szerint az általa leírt esetben valbóban lehet komoly overhead, csakhogy nem tudom megéri -e beáldozni az általánosságot.
    Mutasd a teljes hozzászólást!
  • Ez a klasszikus szabvány vs. innovativitás dilemma.
    Ismert dolog, hogy a túl korán túl bürokratikusan kialakított szabványok durva kerékkötői a fejlődésnek.
    Jó szabványokat kialakítani művészet. Együtt kell dolgozni az innovátor cégekkel, nem túl korán, de nem is túl későn kell a szabványt kialakítani. (Ha túl későn jön, akkor már senki nem használja.)
    A szabványokra sok esetben szükség van: ha nincs hivatalos, akkor az ipar valamit önkéntelenül is kváziszabvánnyá emel.

    Kérdés, hogy a DircetX mennyire jó szabvány, a Microsoft menyire jól és gyorsan működik együtt az innovátorokkal (NVidia, AMD), mennyire kerékkötő a visszafelé kompatibilitás. Ezek nehéz kérdések, szvsz. csak az tud erre rálátni, aki napi szinten benne van ebben (én nem). Ebben a témában senki nem pártatlan de talán a nagy enginefejlesztők véleménye a leginkább mérvadó. (Kérdezzük meg John Carmackot. :))

    Amúgy az AMD azt nyilatkozta, hogy a fejlesztők mondják nekik gyakran, hogy meg kéne szabadulni a DirectX-től, hogy jobban lehessen innoválni.

    Pl. amikor az Intel fejlesztette a Larrabee-t, akkor sok neves fejlesztő szeme felcsillant, hogy végre kipróbálhatnak nem hagyományos renderelési technikákat is. (Voxelesdi, Ray tracing, meg még más még egzotikusabb dolgok.) (Már most is sok renderelési technikánál erősen abuse-olva va na DirectX amúgy.) Aztán persze a Larrabee bénán sikerült, behalt, de ez más kérdés.

    Szal mégegyszer ne arra gondoljatok, hogy Kovács113 Jánosnak lenne ez jó, ez a hardcore enginefjelesztőknek érdekes. Kovács113 János meg szerintem használhat 3rd party engine-t.
    Mutasd a teljes hozzászólást!
  • atx, ez nem programozási nyelv kérdése.

    Ha van egy függvényed, de annak csak egy részhalmazára kell, hogy működjön a programod, akkor ez a programfüggvény megengedőbb, tehát lesznek olyan feltételek, ciklusok, amiket nem kell kiértékelnie a programnak, hiszen azok mindig ugyan azok lesznek (konstansok), vagy kevesebb számítási igénnyel lehet kiértékelni (egy probléma speciális esetére létezhet jobb algoritmus). Ha ezeket a speciális függvényeket jól meg tudod határozni, akkor a teljesítmény nő, viszont ezzel együtt természetesen több memóriára lesz szüksége a programnak.
    Mutasd a teljes hozzászólást!
  • Na ja. Csakhogy, a gyártók azonnal elkezdenének saját extra API-kat belepakolni a cuccba a saját vasuk specialitásainak érdekében - és persze szokás szerint visszafelé kompatibilitás nélkül. Ami záros határidőn belül oda vezetne, hogy 2 éves videokártyával el sem indulnának a legújabb játékok. És persze jönnének a kompatibilitási problémák. Persze, a nagy videokártya gyártók imádnák ezt: állandó piac, amire ráadásul újak be se nagyon tudnának lépni, pláne ha a kiterjesztéseket jó szokás szerint szoftverszabadalmakkal védenék.
    Mutasd a teljes hozzászólást!
  • Igen, de pont az lenne a lényege, hogy a DirectX "leülne" a driver szintjére, csak az API hívásokat meghagyná, azaz nem a driver hívogatásával oldaná meg, mivel maga volna a driver is egyben. Végülis így egy komplett réteg ki lenne lőve, pont az, ami miatt panaszkodott a lassúságra az AMD-s arc. Szerintem nem is mondott butaságot...
    Mutasd a teljes hozzászólást!
  • aki nagy dx, c++, asm optimalizálási varázsló, az írhatna pár szót arról, hogy a lenti kommentemben vázolt gyorsítási ötletem hozna-e pár fps-t
    Mutasd a teljes hozzászólást!
  • Szerintem a DX a driver és az engine réteg közt van. Az EFI meg legfeljebb a drivert foglalja magába.
    Mutasd a teljes hozzászólást!
  • De. Csak az ő képzelt világában nem létezik nVidia, meg Intel meg semelyik másik grafikus chip gyártó sem.
    Nem lenne szükség DX-re, ha
    - csak egyetlen gyártó lenne, vagy
    - szabványosítanák tevékenységüket és együtt terveznének (még mindig maradhat a verseny, hogy kinek sikerült jobban megoldani a szabványos függvényeket)
    Mutasd a teljes hozzászólást!
  • Van valami, amire nem gondoltok... Nemrég itt a Prog.Hu-n is megjelent egy cikk arról, hogy az EFI rövidesen teljesen le fogja váltani a jó öreg BIOS-t. Ez azért érdekes, mert az EFI nem csak a BIOS kiváltására szolgáló funkciókat tartalmazza, hanem lehetőséget nyújt a hardver gyártóknak, hogy a hardvereikhez EFI bájtkódban adják ki a driver-eiket. Ezt a bájtkódot az operációs rendszer az adott hardverkörülményekhez mérten a lehető legoptimálisabb gyorsaságúra fordíthatja le natív kóddá. Eddig gondolom érthető.

    És itt jön a csavar: Ha már egyszer az EFI önmagában is fordítható kód, akkor miért is ne tartalmazhatná a hardveréhez passzított kvázi DirectX API-t? Mert ugye ebben az esetben egy DX hívás közvetlenül a videokártyához (hardverhez) optimalizált driveren vagy magán a kártyán futna le, amellyel egyáltalán nem túlzás, hogy sokkal gyorsabb, és ezáltal bátrabban részletgazdagítottabb (azaz szebb) játékokat lehet gyártani (további overhead nélkül). És így nem veszne el a kompatibilitás kényelme sem a különböző videokártyák/hardverek között...

    Szóval a fenti írásom egy az egyben csupán feltevés, de a lényeg benne van: az az AMD-s srác a kijelentése hátterében tud valami olyasmiről, amiről mi földi halandók még nem. és én ez esetben az EFI-re tippelek.
    Mutasd a teljes hozzászólást!
  • Na ja. Emlékszem a régi "szép" DOS-os időkre amikor megvolt hogy egy-egy játék milyen videókártyákat támogat. Ha épp olyanod volt amit az adott game támogatott, akkor szerencséd volt. Ha nem, akkor szívtál. Ugyanez hangkártyára, stb.
    Az AMD mondjon le.
    Mutasd a teljes hozzászólást!
  • Talán nem azt ért a legjobban ehhez, aki tervezi és legyártja?
    Mutasd a teljes hozzászólást!
  • Az API csak annyiban korlátoz, hogy a sok függvény hívás nagy overheadet jelent, mert meghívok egy API függvényt, szöszöl, aztán meghívja a drivert, az is szöszöl, aztán az meghívja a VGA-t, az is szöszöl, majd fordított irányban ugyanez.
    Ha átadsz a GPU memóriájának egy 1 millió vertexes modellt, egy komplex shaderrel, akkor a fenti overhead nem számít, mert a VGA nagyságrendileg többet fog szöszölni, mint a többiek.

    Ha részecskerendszert akarsz kirajzolni ilyen technikával, részecskénként, akkor ne csodálkozz, ha 100 ezernél többet nem fogsz tudni értelmes framerate-tel.

    Tehát azzal van a probléma, ha egy frame-en belül mondjuk több mint 10000 rajzolás hívás van, mert akkor már előjön a fenti rétegek miatti overhead. Éppen ezért, például részecske rendszerekre kitalálták az instancing technikát (DX9 körül), amit továbbfejlesztettek, és már nem csak részecske rendszerekre lehet felhasználni értelmesen (DX10), hanem animált karakterek tömeges kirajzolására is, de könnyen lehet, hogy ezt még csak a legfejlettebb engine-ek támogatják, pedig ezzel egy nagyságrenddel több egyszerű objektumot (pár vertex) ki lehet rajzolni egy rajzolási hívással, jó esetben az engine fejlesztők gondolom nagyon jól tudják, hogy az egyes kártyákon hány darab objektumtól felfelé, és hány vertex alatt érdemes ilyesmivel foglalkozni.

    Persze nem lehet mindent egyszerre, batchelve instancinggel kirajzolni, nem is csak ez a baj.

    Sztem az lenne a járható út, ha a VGA driver a játék indulása során hozzá tudná linkelni a DX függvények saját implementációját a játékbeli DX függvényhívásokhoz, megkerülve ezzel a DX réteget. Ezzel a megoldással a DX csak az interfészt adná, a driver pedig GPU-nként külön implementálná a függvényeket. Legjobb lenne, ha mindjárt a megfelelő helyre inline linkelné be a driver fordítója a játék binárisába.

    Még egy gyorsítási lehetőség, hogy mivel a DX függvényeket (túl) sokféleképpen lehet paraméterezni, amiből az egyes játékok csak egy szűk részhalmazt használnak, ezért ezeket a függvényeket is lehetne úgy fordítani, hogy csak ezt a részhalmazt implementáják (talán valami hasonló a template metaprogramming, de nem értek hozzá), vagy minden paraméterezésre külön függvényt használni (minden órajel számít jeligével). Azért a sok if() elég rendesen meg tudja akasztani a pipeline-t; ha előre tudjuk, hogy egyes variációk nem fognak előjönni, akkor felesleges rá felkészíteni az alkalmazást. Ugyanezzel lehetne gyorsítani még számos dolgot, operációs rendszereket, webszervereket, stb..
    Mutasd a teljes hozzászólást!
abcd