Shaderek

Shaderek
2008-01-08T23:01:54+01:00
2008-06-05T15:13:02+02:00
2022-10-29T15:05:37+02:00
  • Üdv Luyo bá :)

    Hát még élsz??
    Eddig nem volt neted,vagy csak nem volt időd?
    Én is szivesen néznék videot az uj fejlesztésedről.

    Gábor

    Mutasd a teljes hozzászólást!
  • :)...Üdv. Dani Mathematicks Master.. :)

    sajnos a gyönyörköd-tetönél még mindig nem tartok..de lényegesen több vann már az engin-böl...külön vann szedve részegységekre, mint audio, graphics, math(külön csak sse-s classok..), editor, saját mfc féle win32-es komponensek stb... a scene z szerinti rendezését szuperul megoldotam (reagálva Pali bácsi elözö irására)...
    ma a deferred shading-et tömöm belé...:)...

    a multkori sample-be már egy quake pályán rohangáltam amin postprocess is volt persze normal map meg ami kell..de sajnos még mindig nem mentek semmit mint régen...pedig kéne...:(...
    Mutasd a teljes hozzászólást!
  • Igen, kissé átalakulva, és átszerveződve :)

    Az engine írást átvettem én (DX10.1-re optimizálok és az ATI-s architektúrára), de elsőkörben most engine írás és fejlesztés lesz, és próbáljuk megfelelő emberekkel bővíteni a technikai csapatot :) .

    Szívesen néznénk valamit abból, hogy mire jutottál :) .
    Mutasd a teljes hozzászólást!
  • :)..Hello!

    Jelentem már 8 projectet irok szinkronba...haladok szép lassan.. opengl-t is elövetem és progálgatok linux-ra is koncentrálni (persze DX10 szinten)...:).
    ..és ti rajtavagytok még a projecten?
    Mutasd a teljes hozzászólást!
  • Szervusz Luyo Mester!:)

    Rég hallottunk felőled. Hogy halad az engine, mi van meg belőle?
    Esetleg van valami, amin már lehet gyönyörködni?:) Mert arra mi is kiváncsiak lennénk:)
    Mutasd a teljes hozzászólást!
  • Tiszteletem Luyo mester!

    Mi jót ügyködsz mostanában? Hogy haladsz?
    Mutasd a teljes hozzászólást!
  • Ez teljesen igaz, én is azt írtam hogy egy 3870-en leesett a predicated rendering. Jelentősen, vagy 20-30 fps-t vesztünk.

    Az igaz hogy az occlusion culling csak cpu szinten használja a resource-ket és lehet egy halom state állítást és draw callingot spórolni. Csak ahhoz elég optimálisra kell megírni, hogy tényleg nagyon gyors legyen a lekérdezés. Bár ezt egy páhuzamos magra jópár optimizációval együtt ki lehet dobni, ha frame swapping alapon renderel az ember. De még egy nagyon gyors occlusion culling lekérdezés is bőven 1000 órajel nagyságrendű, ha nem több, és cpu-n csak nagyon egyszerű occlusion testeket lehet gyorsan kezelni, ami nem mindig adja meg a legoptimálisabb megoldást.

    Egy hatékony közepes megoldás, ha tudunk csinálni egy elég elnagyolt z sortingot (layerek használata, tudjuk mik vannak elöl és hátul stb...) azzal az early z test nagyon sokat tud spórolni.
    Mutasd a teljes hozzászólást!
  • Üdv. Pali bácsi...:)

    A predicated, és a occlusion culling használata előtt.. nem árt mérlegelni valamit...

    mig occlusion culling nál a cpu oldalán tudod hogy rajzolni kel e vagy sem igy a state-ket sem változtatod és rajzolni sem fogsz...

    addig a predicated renderingnél megváltoztatod a state-ket (shaderek, paraméterek, texturák, ect)
    és a draw hivásod megbukik a testen...

    a statekel elvesztetél több 1000 órajelet...

    mig occlusion culling test lekérdezésel lehet hogy nem vesztesz ennyit....

    hoppá...:)
    Mutasd a teljes hozzászólást!
  • Hello!

    Pofon egyszerű..:)...
    rendereld le elöre a depth-et.. (depth write enable, depth test enable, color write disable), majd mégegyszer az egészet (depth write disable, depth test enable, color write enable....) igy garantált hogy csak anyi pixelshader code fut le amenyi a képernyön vann... ogl dx9 dx10-en is garantált.. a dupla renderelés véget meg ne agodj.. csak akor probléma ha sok vertexel dolgozol...(ezt a modszert a relif-nél és a parallax-nál szokták alkalmazni...).. jó munkát..:)
    Mutasd a teljes hozzászólást!
  • Ahogy néztem a dx10 az valóban frankó. sajna nem építhetek dx10-re, a proginak el kell futnia a mai "alapkártyákon" is.
    Sikerült kölcsönbe szereznem egy 7600 GT-t. Drivert azt feltettem neki valami újat. Kiderült az, hogyha a tesztprogiban nem-alpha-s textúrát használok, akkor kb. jó a speednövekedés (bár %-ban nincs akkora speedup mint x800 gto2-n, de ok, mondjuk hogy órajel alatt nem tud annyi pixelt eldobni). Ha viszont alpha-s textúrát használok, minél több a lyuk a textúrában, annál kevesebb a speedup, a végén már szinte nulla (az x800-omon nem számított, mennyire lukas a tex, speedup állandó volt). (Megjegyzem, a második pass-ban természetesen már nem használok alpha-test-et, a második passban semmi stencilezés, depth_write, meg egyéb bűvészkedés nincs, a második pass csak arról híres, hogy glDepthTest(GL_EQUAL) ).
    Arra gyanakszom, igazad lehet, ati-ra, és nvidia-ra máshogy kell optimalizálni. Méghozzá, amiket írtál azokból ő a gyanús számomra : High-frequency information in depth buffer ( a sok luk miatt a textúrában ). De még ebben sem vagyok biztos :), még tesztelgetem a dolgot.
    Köszi a helpet, az infókat, ha rájövök a megoldásra szólok :).
    Mutasd a teljes hozzászólást!
  • Olvasgattam a GDC2008-as prezentációkat, és találtam valamit ami érdekes lehet a Z Cullingnál, főleg az újabb nvidia karikon.

    Coarse Z culling is transparent, but it may
    underperform if:
    􀀡 If shader writes depth
    􀀡 High-frequency information in depth buffer
    􀀡 If you don’t clear the depth buffer using a “clear"
    (avoid clearing using fullscreen quads)

    􀀡 Fine-grained Z culling is not always active
    􀀡 Disabled on current hardware if:
    􀀡 PS writes depth (SV_Depth)
    􀀡 Z or Stencil writes combined with:
    􀀡 Alpha test is enabled (DX9 only)
    􀀡 discard / texkill in shaders
    􀀡 AlphaToCoverageEnable = true

    de főleg ez :

    Disabled on current NVIDIA HW if:
    􀀡 PS reads depth (.z) from SV_Position input
    􀀡 Use .w (view-space depth) if possible
    􀀡 Z or Stencil writes combined with:
    􀀡 Samplemask != 0xffffffff

    ill a végén volt egy NVidiás szöveg, lehet valami többször volt, dobd el ami nem megy át az olvasás cullingon

    􀀡 Coarse Z culling is transparent,
    but it may underperform if:
    􀀡 If depth test changes direction while writing
    depth (== no Z culling!)
    􀀡 Depth buffer was written using different depth
    test direction than the one used for testing
    (testing is less efficient)
    􀀡 If stencil writes are enabled while testing (it
    avoids stencil clear, but may kill performance)
    􀀡 If DepthStencilView has Texture2D[MS]Array
    dimension (on GeForce 8 series)
    􀀡 Using MSAA (less efficient)
    􀀡 Allocating too many large depth buffers
    (it’s harder for the driver to manage)

    Egy dolog jött le az egész doksiból, ATInál és NVidiánál tök másképp kell optimizálni még DX10-et is... Pl Atinál 4 5D-s vector utasítás jut egy textúrára míg nvidiánál 10 skaláris.
    Pl NVidia szereti ha egyszerre van törölve az egész depth map, és nem részlegesen, Ati pedig szereti ha minnél kevesebb van törölve egyszerre stb...
    Mutasd a teljes hozzászólást!
  • Most jut eszembe hogy hülyeséget irtam, nem az occlusion culling lassul be dx10 alatt, hanem a predicated rendering :) .

    Elvileg azokon a karikon mennie kéne a cuccoknak, bár a 7300 GT tipikusan laptopkari, ott ne számits sokra, viszont a 7600 GS és a 8600 GTS-nek tudnia kéne, az az NV elég jó ogl-ben. Drivert frissitettél?

    Jamm, dx10 marha sok dolgot tud, főleg azért mert újrairtak az egész rendszer, de megérte a sok újdonságért. Persze ha valaki csak arra akar fejleszteni, akkor el kell dobni a régieket, mert sok dolog csak nagyon körülményesen oldható meg DX9-en, főleg iszonyatos lassulásokkal. A lényeg az, hogy mit jelölsz be elsődleges platformnak, ha DX9 akkor a DX10-es verziónál alig tapasztalsz gyosulást, sőt inkább lassulást (lásd Crysis), ha meg DX10 az elsődleges cél, és nagyon vissza akarod nyomni dx9-re kegyetlen nehéz lesz, vagy irtózatosan belassul (nem nézve azt hogy a dx9-es karik alapban gyengébbek...).
    Mutasd a teljes hozzászólást!
  • Proof88, az occlusion culling az egy jó dolog, sok alkalmazásban hasznos, nálam sajna nem lehet optimalizálni vele ( kis polyszámú, de nagy fillezésűek az objektek ), azért köszi a választ.
    Jeffrey, igazad lehet, nem valószínű, hogy a képszintézis lépéseinek sorrendjét meg lehetne változtatni, csak tippeltem egyet . Amúgy a két pass között semmi swappelést vagy egyéb kontárkodó műveletet nem hajtok végre.
    a 3. dolog -ha jól tévedek- amiröl beszélsz az a Predicated Rendering, itt pedig egész objektumokat rajzolunk ki a Z-be, és ennek az eredménye alapján döntünk róla hogy teljes szinnel meg pixelhsaderrel kell-e végigmenni az obj-on. Ez egy még elörébb levö szürés elvileg.
    Asszem majdnem ugyanarról beszélünk, csak azzal a különbséggel, hogy nálam mindenképp végigmegyünk második lépésben teljes szinnel meg pixelhsaderrel az objekten, de csak ott fog a shader számolgatni (na ez a lényege az egésznek és hw-ból megy automatikusan, csak a z-testet be kell kapcsolni), ahol a z-buffer alapján tudjuk, hogy valóban látszik a pixel a képernyőn. Amúgy most tudtam meg sirpalee legújabb válaszából, hogy az "early z test"-nek köszönhető az egész dolog (így már googlezhattam is az "early z"-vel).
    Igen, valóban az "early z" az még a fragment shader előtt csinálja a z-test-et, és ha az sikertelen volt, akkor a shader nem fut le (feleslegesen). Végülis az derült ki, hogy nem minden kártyán megy az early z, pedig mennie kéne ezeken a jó kártyákon. Utánnanéztem a neten, több helyen is írogatták, hogy milyen feltételei vannak az early z-nek, egyik oldalon például :

    Early Z doesn’t work in three cases
    • When shader outputs depth
    • When alpha-test or texkill is used
    • When alpha to coverage is used

    sirpalee :

    Ami még fontos az early z testnél hogy shaderrel ne írj depth-et, különben nem tud lefutni, és egy ati 2000/3000 kategóriájú kari órajelenként 256 pixelt tud eldobálni... Ami azért elég jelentős :) .

    Igen ez is egy lényeges feltétel. 256 pixelt el tud dobni egy órajel alatt ? Az tényleg nem semmi .

    Persze ez nem az összes feltétel, de más oldalakat is néztem.
    Az alpha-testet csak nemrég kapcsoltam ki, utánna már egyel több kártyán is ment a dolog :), de még sajna mindig nem mindegyiken. Úgy látszik, most már minden feltételt betartok, mégsem megy minden kártyán.
    Ezeken megy :
    x800GTO2, 8800GTS
    Ezeken nem megy :
    7300GT, 7600GS, 8600GTS

    Asszem innentől békénhagylak benneteket ( legalábbis egyenlőre ), a kulcsszó az "early z" volt, köszönöm szépen, és köszi mindenkinek a segítséget.

    Aha, rajzolási sorrend DX10-ben, ez érdekes lehet, ahogy írtál róla. Néztem, DX10-ben elég sok frankó dolog van, de kár, hogy csak a DX10ben.
    Mutasd a teljes hozzászólást!
  • Igen, szóval tudni kéne milyen típusú a videókarid, de mivel elég kemény shadereket használsz így gondolom legalább egy sm2.0-s kari és az már bőven viszi az ún. Early Z testet.

    Elvileg az automatikus ha be van állítva, próbálj drivereket frissíteni (elképzelhető hogy az adott karikon régi v. bugos driver van).

    Ami még fontos az early z testnél hogy shaderrel ne írj depth-et, különben nem tud lefutni, és egy ati 2000/3000 kategóriájú kari órajelenként 256 pixelt tud eldobálni... Ami azért elég jelentős :) .

    Végső megoldásként próbálkozz azzal, hogy eléred a z mélységet (valahogy bepakood textúrába, esetleg másolgatsz a videókarin stb ha régebbi), és a shaderedben manuálisan végzel egy z testet és ha elbukik, akkor megölöd a pixel shadert és leáll... Ez biztosan működik, viszont lassabb lesz az olyan karikon amik viszik rendesen az early z-t.

    AZ occlusion culling jópofa dolog... De dx10 generáció előtt elég sok extra hívás kell, tehát nem mindig éri meg. És néztem a dx10-es sdk-s példát, ami occlusion culling nélkül 280 fps volt azzal 255... Szóval nem tudom... Bár lehet rossz volt a scene, de nem mindig nyersz vele. És azt a cullingot teljesen a videókari végezte, nem kellett adatokat lekérdezni.

    A videókártya rajzolási sorrendje. Ugye régi kártyákon úgy van (megint dx-ről beszélek), meghívsz egy parancsot és az lefut, majd megint visszakapod stb. DX10-től és x360-tól (ha jól tudom ogl-ben van valami hasonló megoldás régebbóta, de az nemtom mennyire hardveres...), ha hívsz bármit is, gyak egy command bufferbe rakódik be, és csak meghívod, amit a gpu lefuttat ahogy lesz rá ideje (bár egy flush-al kényszerítheted, és megvárhatod míg a command buffer kiürül). Elvileg itt a sorrende nem szabad változtatnia, elvileg. De még nem kerültem szembe olyan helyzettel ahogy a sorrend összekavarása nagyon megjelent.
    Mutasd a teljes hozzászólást!
  • Ahoi

    Tudomásom szerint a képszintézis lépéseinek sorrendjét nem tudod a vidkariban változtatni, cska azt, hogya z egyes lépéseket végrehajtsa-e illetve hogyan. Nekem azaz érzésem, hogy olyan módszert akarsz használni, amit a GPU nem támogat. Lehet hogy konkrétabbat tudnánk mondani, ha a Vidkarik tipusát leirod amiken próbáltad futtatni.

    Egy másik érzés... ugye véletlenül semirsz bele vagy swappels vagy bármi hasonló a kér pass között? mert akkor elveszik az elsö render adata.

    Proof:
    A Z culling az más dolog. a Hátsólap eldobás a poligonokra vonatkozik: azokat amelyek nekünk háttal vannak (a normál vektor alapján) abszolut nem rendereljük. Az amiröl itt szó van az az, hogy meghatározzuk azokat a pixeleket, amelyek látszani fogank és cska ezekre futtassuk a pixelshadert.

    a 3. dolog -ha jól tévedek- amiröl beszélsz az a Predicated Rendering, itt pedig egész objektumokat rajzolunk ki a Z-be, és ennek az eredménye alapján döntünk róla hogy teljes szinnel meg pixelhsaderrel kell-e végigmenni az obj-on. Ez egy még elörébb levö szürés elvileg.
    Mutasd a teljes hozzászólást!
  • Nem tudom, hogy egyről beszélünk-e, de Fast-Z Culling Geforce3-tól van, ATi oldalról nem tudom, talán 8500-ös Radeon... Szerintem integrált kártyáknál meg nem viszik túlzásba ezeket a dolgokat.
    Takarással tudsz spórolni occlusion cullinggal is, ki kell rajzolni az objektumok befoglaló testét anélkül, hogy írnál a color bufferbe, és visszakérdezheted, hogy történt-e változás a z-bufferben. Ha nem, akkor jöhet a következő objektum. Ha igen, akkor kirajzolod rendesen. Ajánlott extension-ök: GL_ARB_occlusion_query, GL_NV_occlusion_query (ezzel azt is megtudod, hogy hány pixel változott, értelemszerűen ha 0 akkor nem látszik az objektum), GL_HP_occlusion_test. Utóbbit néhány integrált cucc is támogatja.
    Mutasd a teljes hozzászólást!
  • Hello!

    Először is köszönöm, hogy válaszoltál ! Bocs, hogy nem írtam le részletesen a problémámat, de a program, amit írtam, az valójában ezt az általad említett "pre-z" technológiát alkalmazza, és pontosan úgy, ahogy te azt leírtad. A problémám az, hogy a második passban, ahol a "valódi renderelés" történik, bizonyos gépeken úgy viselkedik a videókártya, hogy első lépésben nem a z-test-et hajtja végre, hanem kiszámítja a pixel színét, és csak aztán jön a z-test, ezért azokon a gépeken "nem használ a pre-z". Amúgy a progi direkt sok takarásra megy rá, és gombnyomásra bekapcsol a "pre-z", és ha működik a trükk, akkor 5-szörös lesz az fps. Bizonoyos gépeken sajnos nem változik az fps.
    Azt még néztem, hogy ha a második passban alpha-testet bekapcsolom ( bár felesleges, mert a pre-z miatt úgyis tudjuk, hol látszanak a pixelek ), akkor haver gépén már nem hatásos a "pre-z", de az én gépemen még mindig hatásos. Ezek amolyan érdekes dolgok, szerintem a driver/videókártya okoskodik, és tudja változtatni a műveletek sorrendjét ( pixelszín kiszámítás, fragment pozíció kiszámítás, alpha-test, depth-test... ). Arra lennék kiváncsi, hogy rá lehet-e bírni valahogy a videokártyát, hogy először mindenképp a depth-test-et hajtsa végre, és csak ha az sikeres volt, akkor számítsa ki a pixel-színét. Ha erre tudsz megoldást, vagy valaki tud valamit, annak nagyon örülnék.

    Köszi
    Mutasd a teljes hozzászólást!
  • Hello!

    Nos mivel OGL-ről van szó nem tudok 100%-ot mondani, de gondolom hasonlók a state beállítások mind d3d9-nél...

    Egyrészt, mivel gondolom valami 3d sceneről van szó, az összes modellen, semmi textúrával menj végig, a következő state beállításokkal extraként (vagy ezekre figyelj mindeképpen):

    D3DRS_ZWRITEENABLE TRUE
    D3DRS_ZFUNC D3DCMP_LESSEQUAL
    D3DRS_ZENABLE D3DZB_TRUE
    D3DRS_COLORWRITEENABLE 0 (ez kilövi hogy írj színt, tehát gyorsabb lesz a renderelés)

    És ebben a passban pixel shadert sem kell meghívn, ha jól írod meg a vertex shadert.

    És ezután hívd meg a rendes shaderedet és lesz egy pre z scene-d, ami nagyon fontos ha elég durva pixel shader kódot használsz (pl übershaderek).

    Itt meg lődd ki a z írást, mivel azt felesleges írni, csak nézni kell, és nyersz sokat a raster egységeknél.

    EDIT:

    megnéztem OGL-ben is...

    ott a megfelelők a GL_DepthFunction és a GL_DepthFunc, a színírásra pedig a GL_WriteMaskColor

    És ha nem használsz stencil-t azt is lődd ki mindkét passnál GL_WriteMaskStencil, a depth-et pedig a második passban a GL_WriteMaskDepth-el tudod kilőni. Figyelni kell a raster egységekre mert eléggé vissza tudják fogni a renderelést.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Egy kis segítséget szeretnék kérni. Írtam egy programot, ami egy igen számításigényes GLSL shadert használ. A problémám az, hogy néhány gépen úgy viselkedik a shader, hogy először számítja ki a pixel színét, és csak azután csinálja a depth-testet, ezért ezeken a kártyákon lassú ( ugyanis sok felesleges helyen is kiszámítja a pixel színét, méghozzá ott, ahol amúgy z-testen nem megy át ). Többi gépen, ahol először csinál depth-test, és csak ha azon átment, akkor számítja ki a pixel színét, ott gyors a progi. Nem tudja valaki, hogy hogyan lehetne rábírni a gépet ( vidkártyát, drivert, tudomisén minek a hatásköre ez ), hogy először mindenképpen a depth-testet hajtsa végre, és csak ha azon átment, akkor számolgasson tovább a shader ?

    Előre is köszi minden segítséget !
    Konrad
    Mutasd a teljes hozzászólást!
  • Lehet nem 25szörös, hanem csak 21-22 szeres teljesítmény :) .

    Az NVidia stream processzorai 3 flopsra képesek 1.35 ghz-n (egy MUL és egy MADD), és ebből van 128, míg ati-n 320 darab 2 flopsos 775 mhz körüli sebességen. Viszont az ati processzorjai 64 pipelinebe vannak rendezve elég érdekes felépítéssel, ha jól van megírva a hlsl kód nagyon képesek párhuzamosítani... Ami egy régi videókártyán 41 órajel, az egy 2900xt/3870-en 7.75-8.25 .

    Viszont az is hozzátartozik, hogy az 5 egy pipelinebe pakolt shader egységből az 5-ik kitüntetett és a bonyolultabb utasítások csakis ezen futnak, gyorsabban mint a többin (sin, cos stb...). Viszont ha nagyon épít valaki ezekre az utasításokra és nem képes párhuzamosan sima skaláris/vektoriális számításokat végezni, 3-4 shader proci csak ül az 5-ből. Erre nagyon kell figyelni az új ATI-knál.

    Például a e = a + b + c + d 3 órajel, míg az e = (a + b) + ( c + d ) 2 órajel.

    A fő gond az NVidiával, hogy a textúrázó egységek csak a magfrekvencián futnak (ami 650mhz körül mozog), míg atinál ugyanazon a sebességen mint a shader procik. Viszont az NVidia 8800 gtx architektúra doksiban megemlítik, ha samplezes nélkül olvasol textúrából (ami gyakori stream processingnél), akkor nem a textúrázó egységgel kérdezik le, hanem közvetlenül a shader procival, ami jópofa dolog és feltehetőleg az R600-as architektúrán is így megy. Mivel régi kártyákon van egy aranyszabály, akárcsak a mostanikon, míg egy textúrát lekérdezel átlagban 4 shader utasítást tudsz futtatni (bár a Gather4 megoldja ezeket a gondokat).
    Mutasd a teljes hozzászólást!
  • Nem is olyan régi a hír.
    Arra lennék kíváncsi, hogy mennyivel gyorsabban lehet ezt csinálni annál a Geforce-nál egy 320 stream processzoros radeonnal...
    Mutasd a teljes hozzászólást!
  • Hahó :)

    Vindóz és egyéb jelszó bruteforcra is tök yo a videókari, főleg az olyam mint ami Jeffreynek és sirpalinak van
    Amugy a videókari számolási teljesítményének kihasználása néha tényleg jól jön :)
    Mutasd a teljes hozzászólást!
  • Ép most látok egy tök jó cikket!
    scene.hu
    Mutasd a teljes hozzászólást!
  • Idézet a DX10 SDK-ból...

    Shader Model 4 is a superset of the capabilites in shader model 3 with the exception that shader model 4 does not support the features in shader model 1. It has been designed using a common-shader core which provides a common set of features to all programmable shaders, which are only programmable using HLSL.


    Oké hogy tudsz disassemblyzni, de alapvetően hlsl használható a programozására, illet PIX-ben (MS teljesítményelemző program), tudsz váltogatni hlsl és asm kiírása között egy shadernek. És ha dx-el foglalkozol érdemes HLSL-ben programozni, a legújabb drivereknek a fordítói nagyon jók... Szinte 0 a különbség .

    Szóval első körben mindenképpen HLSL, ha valaki nagyon akar asm-ezni, előbb ismerje meg az elveket hlsl-ben majd utána shader asm.
    Mutasd a teljes hozzászólást!
  • Megj.: a RM-hez szükségetek lehet a DirectX sdk-ra is, ami letölthetö a microsofttól. Ez azért előnyös, mert ha ez fennt van, akkor ki lehet próbálni azokat a shader funkciókat, amit a hardweretek nem támogat. Ilyenkor minden CPU-n számitódik ki (Software Reference Rasterizer) tetü lassan (lehet érzékelni a teljesitmény különbséget) de vizuálisan teljes értékü.
    Mutasd a teljes hozzászólást!
  • A doksi amit belinkeltél, az csak vs 1.1 és ps 1.4, anno 8.1 és 8.0 alatt csak asm volt az egyetlen megoldás.

    Nos ha már kezdeni kell valahol...

    ATI shader analyzer

    Nagyon egyszerű kis program, elemez 2.0 - 4.1-es shadereket, kírja az adott gépi kódot különböző generációs ati kártyákon, megadja hány órajel stb... Semmi grafika, de kiírja a hibákat.

    RenderMonkey 1.80

    Nagyon jó és egyszerűen használható shader IDe 1.1-3.0-ig, flexibilis, sok nagyon szép és használható példával, mind ati mind nvidia kártyákra. Ezzel kéne kezdeni, letölteni, feltelepíteni.

    Van még NVidiának egy fx composer-je de elsőnek az nagyon bonyolult, és átláthatatlan a rendermonkey nagyságrendekkel kényelmesebb, és nem sok dolog hiányzik belőle . DX9.0c + OGL 2.0 + OGL ES 2.0 shaderek tesztelése (ha valaki konzolra akar shadereket írni .
    Mutasd a teljes hozzászólást!
  • Hello,
    (DX 10 asm)
    Nem tudom végigolvastad-e a linket amit az MSDN oladlról linkeltél be, az ugyanis egy HLSL-ből forditott kód disassemblert változata volt.

    Tehát az állitás pontosabban úgy hangzik, hogy létezik a fogalom h shader asm, de azt te közvetlenül már nem tudod hasnzálni DX 10-től kezdve, másszóval nicns támogatva az asm nyelvü shaderirás és forditás. Megnézni megtudod, hogy a HLSL forditó milyen asm utasitásokat forditott, és az alapján változtathatsz a kódodon.
    Mutasd a teljes hozzászólást!
  • Hi!

    Miért ne lenne DirectX10 asm ???

    CsHeül
    Hrvatsky
    Germ any
    English

    A net tele van shader programozási példákkal.

    Okés, kezdjük az elején.
    Mutasd a teljes hozzászólást!
  • Egen, közben kiderült, hogy ati specifikus kiegészítést használ DX9 alá. Az általános mindene futó példák meg dx10-esek azt azért nem akartam posztolni . Sajnos a dx9 tudásom korlátozott, csak shaderek semmi extension, inkább 10-ben vagyok otthon API szinten is
    Mutasd a teljes hozzászólást!
  • remek :) megszünt az erdeti probléma, és átadta helyét egy másiknak: no r2vb support. bár ez inkább a topicnyitó hatásköre lesz, úgy érzem :)
    :paw:
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd