ATI Hemlock že novembra?

@Senitel:

Pri tistem algotu za risanje krogov, gre, če prav razumem:

- za zmanjševanje "zla"- ki ga prinaša "triangle fan-out" način. Še vedno je problematičen izris maljona trikotnikov, čeprav je žrtev manjša, ker jij je večina majhnih.

- še vedno je treba vsa oglišča ročno zračunati, če se ne motim.


Tu bi s CUDA IMHO pridobil kar nekaj. Izračun meje kroga ni tako drag, pa ne bi rabil za to matrat glavni proc...

No, bo treba probat...

Brane2:
-Stencil si predtavljaš narobe. Ne moreš tega bufferja shiftat sem ter tja. Če narišeš v stencil buffer krog na 10, 10 z radijem 5 ti to čisto nič ne pomaga pri risanju kroga z istim radijem v color buffer na 130, 99.

-Memory tiling ne pride več v poštev pri GeForce 8 in gor (za Radeone ne vem kako imajo), vse je "generally linear". Pri starejših čipih pa so bile teksture tilane (read only data), render targeti (read/write) pa linearni. Teksture so bile tilana v celoti (pač oni cik cak vzorec). Glede razporeditve po page-ih ti ni treba skrbet. Glede poravnav in tega je pa v programming guide sekcija 5.1.2.1.

-Kako hitro misliš da lahko narediš krog direkt v CUDA/pixel shaderjih? Renderiraš kvadrat, ki vsebuje cel krog. Vsak pixel znotraj bo moral naredit test ali je znotraj kroga ali zunaj. Optimalen primer bi bil pixel shader in daš UV koordinate, ki gredo od -1 do 1 (torej center kvadrata/kroga ravno 0, 0). Sedaj rabiš 2D skalarni produkt in branch če je rezultat večji ali manjši od 1. Težava sedaj je ker moraš krog ali blendat s tistim kar je že v color bufferju (read write color bufferja) ali pa clipat pixle (kar ubije early z). CUDA bo počasnejša, ker tega hecka ne moreš naredit, ker nimaš dostopa do interpolatorjev.

Če narediš isto zadevo z geometrijo, generiraš vertex buffer 1x s CPU-jem (polarne koordinate, narediš toliko vertexov kot ti paše) in generiraš index buffer, ki zveže vertexe v trikotnike tako kot kaže slikca za "max area" na prejšnjem linku. Sedaj vsakič ko hočeš narisat krog v vertex shaderju samo prišteješ koordinato kje ga hočeš imet, pixel shader pa je trivialen. Ker boš verjetno imel več različnih velikosti si pač narediš malo več krogov. Recimo z 16, 256, 1024,... vertexi in potem to skaliraš glede nato kako velika bo stvar dejansko na zaslonu.

-Fora onega algoritma za risanje krogov je v tem, da se izogiba trikotnikom, ki so v eni dimenziji ogromni, v drugi pa minimalni. Če recimo rišeš trikotnik (1,1), (800,1), (800,3) je to slabo. Radeon bo šel čez to v 8x8 blokih, torej 100 blokov in 6400 pixlov, čeprav je trikotnik velik samo 1200 pixlov. GeForce bo šel čez v 16x2 blokih, torej 67 blokov in 2144 pixlov... Skratka potrata shader in ROP ciklov. Če narediš krog s pahljačo, ali pa stripom boš pa sproduciral en kup ravno takih trikotnikov.

Ok time out. Ti bi torej risal krog znotraj 16x16 polja z enim samim threadom, oziroma tvoji threadi iz CUDA kernela ne bi tekli na pixlih ampak na krogih?

Kaj točno misliš pod "narisal krog samo enkrat". Zrenderiral enkrat in potem memcopy okrog?

Ne, ne,... Tole ne bo dobra ideja. Branch granularity bo problem, praktično random output iz kernela bo problem. RAW/WAR problemi. Sicer bi imel teh primitivov ogromno ampak se mi zdi, da se bo zadeva preveč časa ukvarjala z IO.
GPU-ji potegnejo 600+M tritkonikov/s, zakaj nebi tega izrabil?

Ampak drugo vprašanje pa še vedno ostane- namesto prikazanega filanja kroga s trikotniki a ne bi bilo pametneje uporabit kvadrate/pravokotnike če ne do konca pa vsaj v prvih nekaj iteracijah ?

Hmm. Moja 8800GT ima 14 multiprocesorjev. Vsak laufa 32threadov v Warpu in do 24 Warpov v bloku.

Tako na uč ne bi smel biti problem napisati rutino, po kateri bi vsak krog risal z enim Warpom precej učinkovito.
S tem bi rešil precej problemov, tudi lokalnost dostopa do RAM-a, sploh če bi imel tabelo objektov, ki jih je treba narisati zgenerirano tako, da laufajo vsi multiprocesorjih na podatkih v istem pageu, če se da...

2010 menda?

čez 2 tedna ;)