praegune kellaaeg 17.06.2025 23:10:23 |
|
Hinnavaatlus
:: Foorum
:: Uudised
:: Ärifoorumid
:: HV F1 ennustusvõistlus
:: Pangalink
:: Telekavad
:: HV toote otsing
|
|
| autor |
|
v2hja
HV Guru
liitunud: 14.03.2003
|
|
| Kommentaarid: 74 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
3 :: |
60 |
|
| tagasi üles |
|
 |
tanel_76
HV vaatleja
liitunud: 16.02.2005
|
16.02.2005 18:12:49
|
|
|
ei usu et see reaalaja raytracing midagi muudaks hetkel,
enamus auru läheks selle pildi tootmiseks. võib-olla ka kui
hakatakse seda cell'i tootma, siis küll - lisaks raytracingule
on realistliku pildi jaoks vaja ka sügavusteravust (tavaliselt 12 pass'i),
motion-blurri, ka global illuminationi mingit varianti, kas siis
ambient occlusion passi kaudu feikides või kuidagi teisiti.
ehk siis pakuks, et reaalaegse vähegi talutava antialiaisitud
pildi tootmisest moodustab see raytrace 1/10. 
olen ise töötanud reaalaegse 3D'ga kasutades SGI Onyx2'htesid,
reaalselt üle 12 000 polygoni ei jõudnud need masinad venitada
opengl'is. seal on omad restriktsioonid ka, optimiseeritud objektid jms.
bugisid oli ka kõvasti.
kel huvi reaalaegse 3D vastu hetkel, andke teada, võin sellest rohkem ka kirjutada.
tanel v
_________________
Davinci Resolve
Quadro FX3700 / FX5800 |
|
| Kommentaarid: 6 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
6 |
|
| tagasi üles |
|
|
486
HV Guru
liitunud: 19.04.2004
|
|
16.02.2005 18:19:03
|
|
|
Selles videos, kus näidatakse maastiku eiffeli torniga öeldi et no detail level, mis see tähendab?
_________________
zero |
|
| Kommentaarid: 46 loe/lisa |
Kasutajad arvavad: |
|
:: |
3 :: |
2 :: |
39 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
16.02.2005 18:30:29
|
|
|
| 486 kirjutas: |
| Selles videos, kus näidatakse maastiku eiffeli torniga öeldi et no detail level, mis see tähendab? |
See tähendab seda et kõigil modelitel kasutati ainult üht versiooni. Näiteks puud millest on näha ainult üks piksel ning see mis täidab terve ekraani kasutavad ilma igasugu optimeeringuteta täpselt sama modelit.
| tsitaat: |
| kel huvi reaalaegse 3D vastu hetkel, andke teada, võin sellest rohkem ka kirjutada. |
Huvi on alati.
|
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
Piipz
HV veteran
liitunud: 15.11.2001
|
|
16.02.2005 18:32:13
|
|
|
pealkirjas võiks gossip asemel olla kuulujutt 
|
|
| Kommentaarid: 37 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
34 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
16.02.2005 18:45:44
|
|
|
| Miks kuulujutt? Räägitud kiip on ju räiesti reaalselt eksisteeriv kuid hetkel kahjuks ainult laboris. Gossip'i all pidasin pigem silmas heietamist.
|
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
tanel_76
HV vaatleja
liitunud: 16.02.2005
|
|
16.02.2005 19:04:09
|
|
|
mis huvi pakub?
näiteks minu teada kasutatakse hetkel eranditult opengl'i baasil töötavaid
render-mootoreid, mina olen kasutanud wildcatte selle jooksutamiseks
ning SGI onyx2'htesid. onyxi suutsin poole tunni sees 2x kokku jooksutada mis
peaks olema kehtiv mitteametlik maailmarekord 
Onyx2 Reality oli 4 MIPS R10000 CPU'd
ning kas mingi 8 infinite reality engini nimelist VPU'd
http://www.google.com/url?sa=U&start=8&q=http://www.silicon-impact.de/gallery/view_album.php%3Fset_albumName%3DSGI-Onyx2&e=9833 igastahes irixi peal jooksis doom2, seda sai taotud 2'he onyxi peal võrgus. FPS'i ei oska ütelda.
igastahes peaks olema üks kallimatest doom2'hte jooksutavatest variantidest, kokku 9milli eest rauda.
opengl jooksis täisantialiaisinguga, kuni hdtv resoni (1980x1020) max 12 000 polygoni.
kui 1gb texture ram täis sai, oli tulemuseks crash.
ühesõnaga, jooksutasin reaalajas 3D stuudioid,
teles. päris-stuudio koosnes ainult sinisest kuubikust, kus siis laud, ankur vms, valgus ning onyx'ist tuli siis nö sünteetiline stuudio. kaamera oli varustatud anduritega mis söötsid pan ning zoom informatsiooni onyxisse ning see arvutas on the fly välja optilised nihked jms ning söötis pildi siis pulti, kust ta läbi ultimatte söödeti stuudiost tuleva pildi taustaks. oli ka võimalik paigutada objekt nö aknrust ettepoole, nt klaassein, kõik sellised objektid olid varustatud alpha kanaliga läbipaistvuse jaoks.
õnnestus ka onyx sisse kärsatada, vähemalt 1 cpu blokk põles sisse. egas muud kui tagant kruvid lahti ja uus blokk sisse.
väga robustne oli see aparaat. nagu sõjaveäetehnika.
_________________
Davinci Resolve
Quadro FX3700 / FX5800 |
|
| Kommentaarid: 6 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
6 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
16.02.2005 19:44:54
|
|
|
Huvi pakuks et mis efekte nendel 12k polügonil kasutatakse et selline süsteem neid rohkem ei suuda jooksutada. Igasugu tehnilised detailid pakuks ka huvi(keskmised tekstuurisuurused, programmeeritavus võrreldes GL'i shaderitega jne). Kui saladus pole siis võiks ka avaldada milleks sellist süsteemi kasutatakse meil siin Eestis (kui on Eestis)
Kui õieti olen aru saanud siis see SGI masin on oma ehituselt hoopis midagi muud kui tavaline graafikat joonistav videokaart, rääkimata siis veel raytracing-kiibist. Seal peaks olema rõhk hoopis muudel asjadel kui polügonide välja pritsimisel. Siin räägitud kiibi tööpõhimõte on fundamentaalselt erinev võrreldes mistahes praegu saada oleva riistvaralise graafika kiirendiga.
Kui raytracing kiibile taha monteerida miski ekstravõimas vektorprose(Cell  ) mis tegeleks sellega mida teevad praegu pixel/vertex shader unitid siis poleks nagu rohkem tarviski
|
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
tanel_76
HV vaatleja
liitunud: 16.02.2005
|
|
18.02.2005 12:56:55
|
|
|
| Ho Ho kirjutas: |
| Huvi pakuks et mis efekte nendel 12k polügonil kasutatakse et selline süsteem neid rohkem ei suuda jooksutada. Igasugu tehnilised detailid pakuks ka huvi(keskmised tekstuurisuurused, programmeeritavus võrreldes GL'i shaderitega jne). Kui saladus pole siis võiks ka avaldada milleks sellist süsteemi kasutatakse meil siin Eestis (kui on Eestis) |
hmm.. mina jooksutasin VizRT nimelist softi mida kasutatakse BBc's, turner networkis jm suurtes telefirmades.
Viz Artist oli stseenide ehitamise jaoks ning seal oli veel rida muid softe millega sai objektidele ligi, näiteks
eelnevalt animeeritud objekte käima lasta mujalt jne. efektid.. noh, kuidas ütelda... varju sai tekitada.. peegeldusi.. aga need olid tekstuuripõhised asjad. üldiselt näeb see asi välja selline, et 3dmax'is ehitan stuudio valmis, tekstuurin ära ning expordin optimiseeritud geomeetria Viz'i 3DS failina. siis renderdan (bake) tektuurid tif failideks ning katan geomeetria siis nende bake'itud tekstuuridega. seal on juba max'is genereerunud varjud jms. lihtne protsess, täpselt nagu mängutööstuses. selle vahega siis ainult, et jooksutatakse seda stseeni full antialiaisinguga reaalajas teleresolutioonis 768x576 (square pix) või kuni HDTV 1920x1080px.
tekstuuride suurus oli max 1024x1024, keskmiselt oli kasutusel 512x512. programm suutis interpoleerida piksleid ka hästi, opengl objektidel muidugi specular highlight arvutati välja reaalajas. eestis sellist asja ei näe, mina töötasin nende süsteemidega eelmisel aastal dubais ja kuveidis. sama tehnoloogia on kasutusel olümpiamängudel.. eurovisioonil jne. onyx2'hte tulid sisse ka videofeedid väljast, just need tõmbasid ressursi kinni. kujuta nüüd ise ette kaht videofeedi virtuaalstuudios mis jooksevad animeeritud geomeetria peal.. suht karm arvutus. uuemad, reality2'ed suuavad jooksutada kuni 25 000 polügoni reaalajas koos videofeedide ja muu jamaga. eks see asi ole veel true-realtime pildist väga kaugel, pakuks 4-5 aastat veel kui midagi sellist näeb.
_________________
Davinci Resolve
Quadro FX3700 / FX5800 |
|
| Kommentaarid: 6 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
6 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
12.04.2006 21:17:06
|
|
|
Tõstan veidi vana teemat.
Kolasin netis ning kogemata sattusin selle kiibi tegijate lehele kust leidsin uudise:
| http://www.saarcor.de/ kirjutas: |
[ March 10th-16th 2005 ]
Visit us at CeBIT 2005 in Hannover, Germany. In Hall 9, booth A40 we are going to present the new version of our Realtime Ray Tracing Hardware Solution featuring fully programmable shading and geometry on our FPGA based prototype. |
Et siis jääme ootama uut infot ja videosid uuest kiibist.
[edit]
Jälle mina siin pajatamas Ray Tracingust
Nüüd kus siggraph 2005 läbi on saanud on siginenud OpenRT lehele hunnik presentatsioone mida seal esitleti. Hetkel alles alustasin lugemist. Kõiki keda antud teema huvitab varuge kõvasti aega, slaide on ~58MiB jagu 
OpenRT:
http://www.openrt.de/
Siggraph 2005 slaidid:
http://www.openrt.de/Siggraph05/UpdatedCourseNotes/course.php
Slaidide pealkirjad:
PART I: FUNDAMENTALS
Introduction to Ray Tracing
The Basic Algorithms
PART II: ACHIEVING REAL-TIME
Optimization Techniques
Parallelization & Distributed Processing
- Cluster-based Distributed Ray Tracing
- Ray Tracing on Shared-Memory Architectures
Supporting Dynamic Scenes with Animation or Interaction
PART III: ADVANCED FEATURES
Volume Rendering with Ray Tracing
Rendering of Massive Models
Hardware Support for Ray Tracing I
- GPU-based Ray Tracing and Remaining Challenges
Hardware Support for Ray Tracing II
- Special Purpose Hardware
PART IV: USING REAL-TIME RAY TRACING
Programming with OpenRT
Writing and Using Real-time Shaders
Using the OpenRT System
Final Discussion
[edit2]
Kolasin veel veidi nende lehel ringi ja leidsin sellise teate:
As of SIGGRAPH 2005, a noncommercial version of OpenRT will be released to the public. The version release will - for the moment - be a slightly limited, PC/Linux-only version of OpenRT. If you are interested in getting a copy, please subscribe to the "noncommercial" mailing list at
https://scihparg.cs.uni-sb.de/cgi-bin/mailman/listinfo/noncommercial .
http://www.openrt.de/getting_OpenRT.php
Wow, mind ootavad ees päris mitu huvitavat ööd 
[edit3]
Kahjuks läheb asi tõeliselt huvitavaks alles millagil järgmise nädala jooksul:
Programming with OpenRT
Writing and Using Real-time Shaders
Today: Public (noncommercial) release
Only for noncommercial use !
Only available for PC/Linux (for now)
Slightly restricted (Scene size, no cluster-mode,
)
Reason: Limit potential sources of problems/questions/
Actual download
Available shortly after SIGGRAPH (next week
)
For infos, see http://www.openrt.de
DONT SEND email to noncommercial@openrt.de |
On tore olla Linuxi kasutaja 
[edit4]
Kuidagi väga ära on see teema unustatud
Täna tuli OpenRT maililisti üks huvitav kiri mille siia pasten. Ehk pakub kellelegi peale minu huvi. Seal räägitakse veidi üldist juttu OpenRT olemusest ning tulevikust. Samuti mainitakse et ka GPU tootjatel on olnud plaane RT integreerimiseks oma raudvarasse:
| Philipp Slusallek kirjutas: |
Hi Dmitry,
WizDum wrote:
> While I was writing my coursework on RTRT I have noticed the site of
> ART VPS company: http://www.artvps.com/
> I am sure that the majority of ones interested in ray tracing heard
> about the result of this company's project: PURE PCI or PCI-X rendering
> card, created for hardware ray tracing acceleration in offline
> non-interactive rendering software (3dmax, maya..). It has the following
> tech specs: 16  350Mhz chips on one card, 512Mb SDRAM and it's said
> that its peak productivity is round about 1.1 Billion of Triangle/Ray
> intersections per second. On site they also have following benchamark
> statistics: the PURE accelerator can render the scene up to 25 times
> faster, then the configuration with only software acceleration. I would
> want to ask if somebody from the Saarland University of CG or inTrace
> had some thoughts of writing drivers for support of this device in
> OpenRT. Or is there some architectural troubles?
Please take my following comments as a well informed guess, as I have no
internal knowledge or up-to-date information about ARTVPS and their
hardware. However, I do know the ARTVPS people, their hardware design,
and we have had several discussions over the years with them. The
important message is that the goals are very different between ARTVPS on
the one side and OpenRT software or the RPU hardware on the other side.
The goals of ARTVPS have been to accelerate photorealistic *off-line
rendering* based mostly on RenderMan. They claim great speedups but
these are based on the speed of the very slow *off-line* software
solutions. The hardware design of the ARTVPS solution has never targeted
realtime performance and (as far as I can tell) will never be able to
reach it.
The hardware essentially stream polygons across the PCI bus to the ART
chips which perform intersection computations and shading. However, a
few hundred MB per second bandwidth are way to little for realtime
performance (do the calculation yourself: 1.1 Gops x typically 36 Bytes
per triangle). So the bottleneck is not the intersection computation but
the bandwidth to the RT-processors. Actually, you do not want to do many
intersections in the first place because they are so expensive in terms
of bandwidth. Instead you want to use coherence between rays and
computations in general to avoid accessing data at all.
The key goal of OpenRT and RPU have been to provide realtime performance
for ray tracing. To this respect we have optimized the software and now
achieve up to 10 fps at 1k x 1k resolution with a single off-the-shelf
processor. This scales well with multi-core and multi-chip setups. With
a simplified setup we already showed 30-50 fps full screen on the Cell
Processor at last Siggraph.
Now, the SaarCOR and RPU hardware projects show that it is indeed
possible to build appropriate hardware for *realtime performance* that
is way more efficient (for a suitable definition thereof) than today's
CPUs. For good reasons this hardware looks very different than the
ARTVPS design.
I definitely expect to see some hardware support for ray tracing in the
coming years but it is not clear yet, exactly what that will be. Even
the GPU vendors are talking about future support for efficient ray tracing.
At the end it does not really matter whether ray tracing runs on
multi-core CPUs, the Cell processor, an RPU, a future GPU, or whatever.
What is important, though, is that we find the right software interface
to it and develop applications that take advantage of ray tracing. I can
definitely imagine that increasingly larger parts of graphics will
migrate towards ray tracing as cheaper and more powerful ray tracing
engines become available and we solve some of the remaining issues.
Expect to see many, if not most, issues being solved this year by
Siggraph ... |
Tundub et ma siiski pole ainuke kes käib ringi ja kuulutab et RT on tulevik
[edit5]
Järjekordne teema upitamine
Seekord leidsin siis WIP doktoritöö uue RT riistvaralise kiirendi tegemise kohta: http://graphics.cs.uni-sb.de/~jofis/ -> "SaarCOR - A Hardware-Architecture for Realtime Ray Tracing"
Kui päris täpne olla siis tegelikult on see lihtsalt üks umbes 3a tagasi alustatud töö vaheetapp. Siin varem räägitud RPU on üks vanem versioon järgnevalt kirjeldatud riistvarast.
Tegu on ~200 lk pika kirjutisega kus pikalt-laialt riistvara disainimisest ja ehitusest räägitakse. Toon siin välja paar huvitavamat lõiku.
| tsitaat: |
Our design also compares well to high end rasterization hardware of 2004. For instance,
Nvidias GeForce FX-5900 contains 125 million transistors [Nvi04] (3-times more than
Intels Pentium-4 at that time). Its 400 FP-units running at a frequency of 500 MHz
yield 200 billion FLOPs, which is 50-times the performance of the SaarCOR prototype.
In fact the SaarCOR prototype has roughly the same floating-point performance as
Nvidias Riva 128 [Ber02] built in 1998! The next chapter will shown that the memory
bandwidth of the prototype including un-cached shading is mostly far less than 300 MB/s
plus additional 135 MB/s to display the image in 1024×768 at 60 Hz. As graphics boards
already in 2004 offer more than 30 GB/s external memory bandwidth, this would support
more than 100 independent ray tracing pipelines.
Thus despite that a direct comparison is not really possible, the resources available
on current graphics cards would allow for quite a large number of parallel ray tracing
pipelines. This indicates that this prototype could be scaled by one to two orders of
magnitude going from the current FPGA technology to one used by rasterization engines
in 2004.
Furthermore Section 8.5 compares the performance of the prototype with the highly
optimized SSE-variant of the OpenRT software raytracer on a Pentium-4 and shows that
although the CPU is clocked 30 times faster than the SaarCOR prototype, the hardware
is still 3 to 5 times faster. Thus, the 90 MHz prototype is theoretically equivalent to an
8 to 12 GHz CPU and uses its floating-point resources 7 to 8 times more efficiently. |
| tsitaat: |
The prototype (see Section 7.3) fully implements a whole dynamic ray tracing pipeline
including fixed function shading on a single FPGA and supports both ray tracing of static
and dynamic scenes. It is build using a commercial prototyping board (see Section 7.3)
containing a FPGA running at 90 MHz and SRAM memory, which delivers 1 GB/s for
geometry data and 340 MB/s for shading. |
| tsitaat: |
Even in complex scenes the external bandwidth in total is small (mostly well below
300 MB/s, ignoring the fixed 135 MB/s required for frame buffer readout due to image
display at a resolution of 1024 × 768 with 60 Hz). The bandwidth of the DynRTC is very
efficiently reduced already by tiny caches of only 12 KB total.
The bandwidth requirements for shading are constant per frame as ray tracing shades
every pixel exactly once and no caches are used. Only a single texture with bilinear
filtering is used in the examples because the need for complex multi-texturing is greatly
reduced in ray tracing as light, reflection, and environment maps are replaced by tracing
the necessary rays. Bandwidth is further reduced by not having to generate these maps
in the first place.
We only provide measurement data for primary rays as the performance measured in rays
per second for secondary rays is identical, as it only depends on the specific arrangement
of geometry in particular scenes, e.g. the placement of light sources and complexity of
the scene visible through reflections. This means that switching on secondary rays can
even improve the overall performance measured in rays per second.
These results confirm the results of Section 8.1 and are obvious since the number of
operations required to trace a ray and the amount of memory transfered only depends
on the location of the ray in a specific scene and not on its type. The same holds for
the memory bandwidth as ray coherence is mostly preserved when generating some type
of secondary rays. Secondary rays do influence the cache depending on the amount of
additional data that is accessed, which again depends on the specific scene. |
| tsitaat: |
These results clearly show the many advantages of ray tracing with its high scalability,
low bandwidth to memory, and very efficient implementation that allows for a good and
output-sensitive performance. However, even these very good results leave room for im-
provements since many extensions allowing for higher frame-rates and even more efficient
designs have not yet been implemented in the SaarCOR architecture.
Nevertheless the SaarCOR prototype verified the simulations and showed that the hard-
ware requirements of ray tracing are not higher than those of rasterization based graph-
ics. Therefore it is technically feasible to build a ray tracing system capable of rendering
complex sceneries in full screen resolution at real time performance. |
| tsitaat: |
The results of these evaluations have been used to implement what we believe to be
the first prototype for realtime ray tracing hardware. With the prototype hardware we
demonstrate that ray tracing is at least as well suited for hardware implementation as the
ubiquitous rasterization approach. Even the rather simple prototype implementation of
ray tracing (using technology of 2003) already achieves realtime performance for a wide
variety of scenes and is several times faster than any CPU of 2004, although these CPUs
are clocked more than 30-times faster. |
| tsitaat: |
There are two main limitations of current rasterization hardware that ray tracing allows
for overcoming: The external memory bandwidth requirements of ray tracing are only a
fraction compared to rasterization, where bandwidth has been a major limiting factor.
Furthermore ray tracing offers efficient scalability over a wide range by simply adding
multiple pipelines per chip, multiple chips per board, and/or multiple boards per PC.
Scalability is mainly limited by the bandwidth to the scene data. However, exactly this
bandwidth can easily be reduced using packets of rays, caching, or (cached) replication
of the read-only data. Ray tracing greatly benefits from its demand-driven and output-
sensitive type of processing that minimizes the work performed to only the relevant parts
of the data.
We have shown that this key feature of ray tracing allows for an fully automatic and
highly efficient memory and scene management. Using these techniques scenes many
times larger than the available on-board memory can be rendered at hardly any impact
on the performance. These results invalidate the common assumption that ray tracing is
impractical because it would need to store the entire scene in local memory. |
| tsitaat: |
The Future is Ray Tracing
It remains to be seen what will be the preferred platform for realtime ray tracing in
the future. Available are high-performance general purpose CPUs, large parallel pro-
grammable processing engines such as GPUs or arrays of RISC-like CPUs, or finally
custom hardware.
Custom hardware seems to offer the most benefits for the core ray tracing pipeline es-
pecially since it uses its floating-point resources most effiiently, while other parts of ray
tracing, such as shading, seem better suited for or even require general purpose-like en-
gines. As a consequence a combination of custom hardware and more flexible engines
seems like a promising approach.
In summary, it seems that the old dream of real-time ray tracing is finally realizable
at hardware costs similar to existing graphics systems. This would enable the display
of highly realistic, physically correct, and accurately lit interactive 3D environments.
Because ray tracing is at the core of any algorithm computing light transport, fast ray
tracing is likely to also enable real-time global illumination computations and other ad-
vanced optical effects. |
Kel huvi on tirige see endale alla ja lugege. Lõpus on hunnik tabeleid mis näitavad mitmete eri stseenide juures kiiruseid. Näiteks Q3a jooksis simulaatoris nelja 533MHz RPU peal umbkaudu 110FPS@1024@768. FP jõudlust oli sel kooslusel umbes pool GF3'st, peak-mälu läbilaset oli nelja peale kokku 1GB/s ehk ~7.8x vähem kui GF3'l.
Nüüd tuletage meelde kui kiiresti suutis GF3 q3a'd sellise reso juures jooksutada. Seejärel jagage see kahega et võrrelda RPU vs GF3 FPU võimsust ning jagage neljaga et võrrelda mälu läbilaske kasutamise efektiivsust
GF3'ga võrdse FP võimsuse juures renderdavad RPU'd q3a'd ~230FPS
Kas viga on minus või ongi nii et hetkel rasterdamise suurim probleem, mälu läbilase, on praktiliselt olematu ray tracemise puhul?
Kui nii siis mulle tundub et on ainult aja küsimus millal turule ilmuvad GPU ja PPU kõrvale RPU'd
Umbes 5a pärast R600/G80 transihulga, mälu läbilaske ja taktiga RPU peaks päris asjalik riistapuu olema, ~100-150 700MHz RPU'd 64GiB/s mälu küljes peaks üsna kenasi pildikesi renderdama.
Nagu varem räägitud saaks RT küll GPU'sse integreerida kuid üpris tõenäoliselt kaotaks sellega väga suure osa efektiivsusest võrreldes eriotstarbelise riistvaraga.
| stepzter kirjutas: |
Praegu on kell natukene palju ja mõned  ka juba võetud, aga ma loodetavasti homme jõuan natukene pikemalt sellel teemal kommenteerida. |
Kui küsida võib siis kas vahepeal ~16 kuu jooksul oled ehk kaineks saanud
Mind huvitaks väga kuidas sa selle uurimustöö tulemusi kommenteeriksid.
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity"
viimati muutis Ho Ho 12.04.2006 21:56:49, muudetud 1 kord |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
londiste
HV Guru
liitunud: 23.04.2003
|
|
12.04.2006 21:24:15
|
|
|
| Ho Ho kirjutas: |
Kel huvi on tirige see endale alla ja lugege. Lõpus on hunnik tabeleid mis näitavad mitmete eri stseenide juures kiiruseid. Näiteks Q3a jooksis simulaatoris nelja 533MHz RPU peal umbkaudu 110FPS@1024@768. FP jõudlust oli sel kooslusel umbes pool GF3'st, peak-mälu läbilaset oli nelja peale kokku 1GB/s ehk ~4x rohkem kui GF3'l.
Nüüd tuletage meelde kui kiiresti suutis GF3 q3a'd sellise reso juures jooksutada. Seejärel jagage see kahega et võrrelda RPU vs GF3 FPU võimsust ning jagage neljaga et võrrelda mälu läbilaske kasutamise efektiivsust
GF3'ga võrdse FP võimsuse juures renderdavad RPU'd q3a'd ~230FPS |
kas mitte gf3 ei olnud ka juba mälu otsast vähe piiratud?
q3a on muidugi pisut halb näide imo, ikkagi juba ajast ja arust mootoriga tegu
peaks selle läbilugemise ikka tõsiselt ette võtma 
_________________
- londiste
...aga mina ei saa kunagi suureks! |
|
| Kommentaarid: 241 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
215 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
12.04.2006 21:59:56
|
|
|
Esiteks pean vabandama. Seal kus kirjutasin 4x rohkem oleks pidanud olema ~8x vähem. GF3'e mälu läbilase on ~7.8GiB/s. Kohe parandan ära.
Segadus tekkis sellest et ma mõtlesin et neil oli igal RPU "torul" oma eraldi 2G mälukanal kuid hiljem sain aru et siiski jagati ühtainust ning too oli hoopis 1G.
| londiste kirjutas: |
| kas mitte gf3 ei olnud ka juba mälu otsast vähe piiratud? |
q3a's tõenäoliselt oli jah. See näitab seda paremini et ray tracing suudab olemasolevat mälu läbilaset märksa efektiivsemalt ära kasutada
Paraku pole ma siiani veel näinud võrdlusi vähe uuemate mängumootorite portimise kohta kuid olen üsna kindel et sama tendents jätkub.
Tegelikult küll RT'd päris 1:1'le ei saa rasterdamisega võrrelda.
Kui ühe NV GPU disainer-arhitektiga vestlesin RT üle ütles ta mulle et rasterdajad skaleeruvad max(num_triangles, num_pixels) ning ray tracerid log(num_triangles)*num_pixels. Konkreetse oluokorra jaoks sobivam meetod on RT juhul kui (num_triangles/num_pixels) > log(num_triangles). Ehk siis kui iga piksli kohta on umbkaudu log(num_triangles) kolmnurka.
See tähendab et q3a ei näita kaugeltki mitte RT tugevaimat külge ehk kõrge detailsusega stseeni renderdamise võimekust.
Vaadates et viimasel ajal on enamus efekte lahendatud GPU'de peal multipass-algoritmidega tähendab see et keerukamates stseenides kus on tarvis samu kolmnurki mitmeid kordi löbi hekseldada muutub RT üsna kiiresti efektiivsemaks lahenduseks.
Kõigele sellele lisanduvad loomulikult väga palju lihtsamalt implementeeritavad algoritmid ja efektid ning kõvasti väiksem mälu läbilaske vajadus
[edit]
Hetkel paraku eriti palju lisainfot selle kohta pole. Mõen kuu jooksul peaks pinnale ujuma terve hunnik uusi doktori-, magistri- ja lihtsalt uurimustöid. Siggraphiks peaks suht paljud saadaval olema, peale seda juba pea kõik koos piltide ja videotega.
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
stepzter
HV veteran
liitunud: 11.11.2001
|
|
12.04.2006 23:02:27
|
|
|
HoHo, huvipärast küsiks, kas sa oled üritanud analüüsida kaadri arvutamise erinevate komponendite osakaale? See, mida raytracing teeb on ju tegelikult ainult üks osa - nähtavuse arvutamine. Võib vabalt olla, et tuleviku perspektiivis muutub see osa väga tühiseks või teiselt poolt sügavuspuhvriga meetodite suurem koherentsus ja elementaartehete lihtsus kaalub otstarbekate adnmemahtude juures ülesse raytracingu asümptootilise keerukuse eelise.
Aga siggraphi ootan minagi pikkisilmi
|
|
| Kommentaarid: 26 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
26 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
13.04.2006 01:35:11
|
|
|
| stepzter kirjutas: |
| HoHo, huvipärast küsiks, kas sa oled üritanud analüüsida kaadri arvutamise erinevate komponendite osakaale? |
Rasterdajate koha pealt eriti põhjalikult ei ole uurinud. Ehk viitsid veidi valgustada sellel teemal?
| stepzter kirjutas: |
| See, mida raytracing teeb on ju tegelikult ainult üks osa - nähtavuse arvutamine. |
Otsene nähtavus pole ainuke asi millega RT tegeleb. Kui tehtaks ainult esmaste kiirte castimine siis tõesti. Samas suudab RT ka valguse peegeldumist-murdumist ning varjude arvutamist teha kasutades toda sama üsna arvutus- ja mäluefektiivset viisi. Ehk siis rekursiivne RT koos kõigi oma rõõmude ja muredega. Minu arvates just see rekursiivsus ongi üks RT trumpidest.
| stepzter kirjutas: |
| Võib vabalt olla, et tuleviku perspektiivis muutub see osa väga tühiseks või teiselt poolt sügavuspuhvriga meetodite suurem koherentsus ja elementaartehete lihtsus kaalub otstarbekate adnmemahtude juures ülesse raytracingu asümptootilise keerukuse eelise. |
Umbes sama väitis ka too NV tüüp kuid paraku ta pikemalt sellest ei rääkinud.
Näiteks viimasel ajal on GPU'de peal üsna tugevasti kasvanud vertex unitite läbilase. Tema väitis et enamasti kasutatakse see mitte rohkemate kolmnurkade läbi hekseldamiseks vaid lihtsalt lisatakse veel üks pass või render-to-texture mõne efekti arvutamiseks, näiteks valgusallika varju leidmine. Ehk siis samu andmeid tuleb läbi GPU mitmeid kordi streamida. RT ja varjude puhul on küll sama lugu et samu andmeid läheb mitu korda vaja kuid seal annavad isegi väiksed cached üsna suure cache hit tõenäosuse seega ei tohiks olukord nii hull olla. Kui uurimustööst õieti välja lugesin siis ka RPU's kasutatav multithreadimine on riistvara koha pealt tunduvalt efektiivsem ja kokkuhoidlikum kui näiteks R500 seerias kasutatav.
Põhjus miks eelistatakse rohkemate kolmnurkade asemel mitmekordset renderdamist* tuleneb minu arvates just rasterdamise üldpõhimõttest kus suurte kolmnurkade kasutamine on märksa efektiivsem kui väiksemate oma. Ühe kolmnurga peal keerukate shaderite jooksutamine on efektiivsem kui väiksemate peal lihtsamate oma kuna granulaarsus on suurem. Keerukate shaderite kohta suht hea näide on parallax mapping kus kolmnurkade arvu pealt hoitakse kokku lisa tekstuuride (==mälu läbilaske) kasutamisega. RT's pole sellist suurte kolmnurkade ja keerukate shaderite eelistamist tarvis, kuid tahtmise korral saab seda siiski kasutada. Iga kolmnurga mitmekordne tükeldamine võib olla mälu läbilaske koha pealt efektiivsem kui ühe lisa tekstuuri kasutamine. Loomulikult eks suured kolmnurgad oleks ka RT's efektiivsemad kuid vähemalt ei ole väiksed niivõrd ebaefektiivsed kui rasterdamisel.
*) see on siis lisaks põhjusele et nii mõndagi algoritmi ei saa ilma multipassita teha.
Sa ise siin teemas väitsid varem
"Mälupöördus on teatavasti aeglane ja arvutamine kiire ja praeguste trendide järgi läheb asi ainult hullemaks.".
Kas see ei näita et uue passi lisamine on üsna ebaefektiivne kuna sellega tarbitakse üsna palju mälu läbilaset? Ehk siis nagu sa seal veel ütlesid:
"Praeguseks niipalju, et rasteriseerimisel ja raytracingul (eesti keelne termin kuluks tõesti marjaks ära) on omad head ja vead ning natuke tulevikku vaadates on näen ma potentsiaali pigem sellel mis suudab mälupöördust rohkem lokaliseerida selle juures võibolla kaotades arvutusvõimsust."
Ehk siis kui RT tõesti vajab nii vähe mälu läbilaset ning on ülimalt tolerantne viidetele(threadid) nagu seal uurimustöös kirjeldatud siis kas mitte just tollel poleks suurem tuleviku potentsiaal?
Lokaalsus ei tohiks RT puhul eriti suureks probleemiks olla. Tekstuure loetakse suhteliselt harva ning valdavalt ühe kiirtepaketi puhul sama tekstuuri lähedastest punktidest ning latentsus on üsna ebaoluline. KDTree on aga niigi üsna lihtsalt ja efektiivselt prefetchitav ning suhteliselt vähe mälu tarbiv asi (8 baiti per node/leaf kui tühje lehti eraldi ei käsitle).
Üks väike asi mis vahepeal veel meelde tuli sügauspuhvril baseeruvate algoritmide õudusunenäo kohta on poolläbipaistvad objektid, eriti kui neid on mitu tükki üksteise otsas.
Näiteks üks stseen:
Oled õues ja vaatad läbi värvilise mustriga klaasiga akna majja. Seespool on aknast eemalduvas järjekorras akvaarium, klaasist laud millel suur klaasist vaas. Laua taga on seljaga akna poole inimene kes hoiab käes tõrvikut. Laes on teine lamp. Kõigi nende tekkivate varjude, valguse murdumiste ning eri värvide ülekandumisi on rasterdades pehmelt öeldes keerukas korralikult joonistamine on pehmelt öelda keerukas. RT puhul on iga kiire ja poolläbipaistva objekti lõikumisel tarvis välja saata uued kiired. Kõik efektid tulevad automaatselt RT rekursiivsuse tõttu.
Btw, ega sa ei oska oletada umbes kus võiks olla piir kus näiteks 1600x1200 reso juures muutub kõigi GPU arvutusüksuste koormamine problemaatiliseks? Kui korraga mitut passi või RTT'd teha ei saa siis mingi hetk tekib ju olukord kus mõned üksused lõpetavad töö kuid uut pole veel kusagilt võtta. muutub lugu kurvaks siis kui kõik need üksused tahavad korraga mälust midagi lugeda. Umbes sarnane lugu peaks olema ka lightmappide renderdamisel kus suhteliselt suur osa ALU'de eri arvutusüksusteks peaks suurema osa ajast idles olema. Mida ma selle all silmas pean on umbes sarnane olukord kus CPU jooksutab küll täiskoormusega mingit ülesannet kuid kõik SIMD üksused on idles.
Kui ma eksin ning siiski on võimalik paralleelselt mitut RTT'd teha on olukord loomulikult teine, vähemalt arvutusüksuste efektiivse ära kasutamise koha pealt. Piisav cachede täitmine ja tekstuurisämplite saamine nendesse arvutusüksustesse on aga hoopis omaette ooper
Posti lõpetuseks ka väike tabel ühe RPU "toru" jaoks vajalike arvutusüksuste ja cachede kohta:
Unit Add Mul Div Cmp Mem
Traversal 4 4 13 44.5 KB
Mailboxed List 0.8 KB
Transformation 9 9 9.3 KB
Intersection 3 2 1
RTC-Cache 15.6 KB
Shader 4.8 KB
Total 16 11 5 13 75.0 KB
Table 7.3: Complexity of one ray tracing pipeline measured in floating-point units for
addition, multiplication, division, and comparison, respectively. The rightmost
column also lists the internal memory requirements including any meta-data
and global state, such as parameters for 8 light-sources. Each pipeline uses 32
threads and contains caches that store 512 data-items each.
|
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
piimaPAKK
HV kasutaja
liitunud: 06.12.2005
|
|
13.04.2006 08:23:32
|
|
|
Ei viitsi teemat läbi lugeda aga kui veel mainitud pole, siis on olemas kaardid mis ray-tracingut rauas teevad mingi Pure seeria oli vist.
Samas reaalajas kiire-jälitusel ei näe veel küll hetkel mõtet, tegu ju ikkagi brute force tüüpi renderdamisega.
|
|
| Kommentaarid: 3 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
3 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
07.10.2007 12:54:29
|
|
|
| piimaPAKK kirjutas: |
| Ei viitsi teemat läbi lugeda aga kui veel mainitud pole, siis on olemas kaardid mis ray-tracingut rauas teevad mingi Pure seeria oli vist. |
Jah, sellised asjad on olemas kuid need ei kõlba reaalaja rakenduste jaoks kuna kiirendavad ainult suht väikest osa RT'st.
| piimaPAKK kirjutas: |
| Samas reaalajas kiire-jälitusel ei näe veel küll hetkel mõtet, tegu ju ikkagi brute force tüüpi renderdamisega. |
Arvad väga valesti
Loe siiski eelnevat teemat. Näitels üks huvitav fakt:
"Furthermore Section 8.5 compares the performance of the prototype with the highly
optimized SSE-variant of the OpenRT software raytracer on a Pentium-4 and shows that
although the CPU is clocked 30 times faster than the SaarCOR prototype, the hardware
is still 3 to 5 times faster. Thus, the 90 MHz prototype is theoretically equivalent to an
8 to 12 GHz CPU and uses its floating-point resources 7 to 8 times more efficiently."
Samas isegi tarkvaras annab prose peal nii mõndagi ära teha. Näiteks ~13M kolmnurgast koosnev elektrijaam minu 3.2G P4 peal:
Too 90MHz ühe "toruga" prototüüp jooksutaks sama asja kusagil 4-5FPS.
Veel pilte on aadressil http://hoho.bafsoft.net/intrace/unc/intraceXXX.png kus XX läheb 1-20.
Pilte teistest implementatsioonidest:
http://ompf.org/forum/viewtopic.php?t=39 <- riistvaraks peaks olema 2.6GHz opteron
Veel hunnik pilte on siin: http://ompf.org/spgm/index.php?spgmGal=wip
Praegustes tipp-mängudes näeb ekraanil üliharva > 1M kolmnurga. Kui õieti mäletan siis Stalkeris oli näiteks kusagil 350-500M kanti keskmiselt kaadri kohta.
Minu arvates pole RT sugugi rohkem brute force kui GPU'del kasutatav rasterdamine. Kui üldse siis just viimane on seda
[edit]
Täna päeval potsatas mu postkasti üks väike google'i uudis kus tüüp NV'st ja teine tüüp OpenRT arendumeeskonnast väitlevad kelle lahendus on parem. Artikkel on umbes 2a vana kuid ideed on enam-vähem samad.
Ray tracing or rasterization?
http://www.gamestar.de/magazin/specials/hardware/17734/
Paraku tundub et NV esindaja, Kirk, ei ole kursis viimase paari-kolme aasta tegemistega RT's ning tänu sellele teeb üsna palju valesid oletusi mille Susalek ümber lükkab
Mina jagan arvamust Susalekiga:
I sometime have the feeling that with the dominance of rasterization hardware today, too many of us are simply not aware any more of the many limitations that rasterization actually has.
Riistvarast, minu poolne rõhutus:
| Kirk kirjutas: |
| Researchers have already demonstrated ray tracers running on GPUs that are far faster than CPUs or special purpose hardware. A modern GPU such as the GeForce 6800 has about 40x the floating point processing power of a 3 GHz Pentium 4 processor, and a general programming model with looping and branching, as well. Anyone who believe that GPUs are not yet good at ray tracing is a few years behind the times. |
| Susalek kirjutas: |
While it is possible to implement ray tracing on the today's programmable GPUs, they are not well suited to the task. Even though they offer much higher raw processing power, the final ray tracing performance we and others see is well below even that of current CPUs. GPUs are optimized for simple linear code while good ray tracing algorithms need to execute complex control flow and even recursive computations. These are hard to map to the GPU at all and then do not perform too well.
In contrast we have recently implemented a prototype of a custom ray tracing based graphics card using a single Xilinx FPGA chip. The first results show that this really simple hardware running at 90 MHz and containing only a small fraction of the floating point units of a rasterization chip already performs like a 8-12 GHz Pentium 4. In addition, it uses only a tiny fraction of the external memory bandwidth of a rasterization chip (often as low as 100-200 MB/s) and therefore can be scaled simply by using many parallel ray tracing pipelines both on-chip and/or via multiple chips. |
Ehk siis 6800u@400MHz omab ~40x rohkem FP jõudlust kui 3GHz P4 ehk siis on võrdeline 75GHz P4'ga. Samas 90MHz FPGA prototüüp on umbes sama kiire kui 8-12GHz P4. Kui tolle prototüübi takt tõsta 400MHz peale muutub too umbes sama võimsaks kui 35.6-53GHz P4. Samas aga omab esimene 16 FP32 "toru" ning teine murdosa ühest taolisest 6800 torust. Ehk siis kui kasutaks RT raua tegemiseks sama palju transse kui GPU jaoks saaks oluliselt efektiivsemalt oma ujukoma võimsust tarbiva riistapuu
Märkida võiks ka seda et GPU puhul peaks tegu olema teoreetilise arvutusvõimsuse ja RT raua puhul reaalselt mõõdetud tulemusega. Päris elus võimsus kipub üldjuhul olema praktiliselt kasutatav võimsus teoreetilisest maksimumist madalam.
Veel üks tsitaat:
| Susalek kirjutas: |
| While there is certainly much work still to be done, I think it is fair to say that the conventional wisdom that ray tracing is more complex, slower, not practical for interactive use, etc. is finally proven wrong. |
[edit2]
Veel uudiseid ray tracingu maailmast. Just praegu (~20 minutit tagasi) riputati avalikult netti üles paber pealkirjaga "Instant ray tracing". Päris momentaalse ray tracinguga tegu pole kuid üsna suure edasiminekuga siiski. Sissejuhatav lõik paberisse:
| tsitaat: |
Abstract
We introduce a new ray tracing algorithm that exploits the best of previous methods: Similar to bounding volume
hierarchies the memory of the acceleration data structure is linear in the number of objects to be ray traced and
can be predicted prior to construction, while the traversal of the hierarchy is as efficient as the one of kd-trees.
The construction algorithm can be considered a variant of quicksort and for the first time is based on a global
space partitioning heuristic, which is much cheaper to evaluate than the classic surface area heuristic. Compared
to spatial partitioning schemes only a fraction of the memory is used and a higher numerical precision is intrinsic.
The new method is simple to implement and its high performance is demonstrated by extensive measurements
including massive as well as dynamic scenes, where we focus on the total time to image including the construction
cost rather than on only frames per second.
|
Lühikokkuvõte paberist on et tüübid mõtlesid välja uue ruumi jaotava andmestruktuuri mis on segu bounding voulume hierarchy'st (BVH) ja KD-treest ning pärib mõlema parimad küljed: BVH kiire ehitamine ning hea tugi dünaamilistele muutustele ning KDTree kiire traversimine.
Näiteks:
| tsitaat: |
Using this simple extension we are able to render the Boe-
ing 777 mesh at 1280 × 1024 resolution in 3-9 minutes (de-
pending on camera position) from scratch on a single core of
an Opteron 875 2.2 GHz machine with 32GB RAM. Com-
pared to previous approaches we only use a fraction of mem-
ory (see figure 8). The total rendering time of one view thus
matches the time that InTrace's InView/OpenRT 1.4 uses to
just build the acceleration data structure of the more than 350
times smaller conference room. |
Ehk siis nende algoritme kasutades renderdasid nad 350M eraldi kolmnurgast koosneva lennuki sama kiirelt kui üks teine programm arvutas 1M kolmnurgast koosneva stseeni KD-tree. Nende algoritm on väga lihtsalt mappitav ka nende SaarCor'i tüüpide poolt arendatavale RT riistvarale. Kusjuures riistvara muutub isegi pisut lihtsamaks.
Mõned pildikesed huvitavamatest tabelitest tolles paberis:
Huvitav kas nüüd võiks öelda et dünaamiliste stseenide ray tracemise probleemid on suuremas osas lahendatud? Kui nii siis võiks öelda et puudu on ainult lõplik versioon riistvarast. Huvitav kas järgmise aasta Siggraphil on juba midagi näha ...
Kui veab siis mõne aja pärast saab juba ka paari-kolme inimese ray tracerit proovida mida hetkel on juba umbes nädal aega arendatud. Hetkel nende omad veel päris KD-treega samu kiirusi ei saavuta kuid suund on neil juba õige.
[edit3]
Veel veidi huvitavaid uudiseid laiast maailmast
Ray Tracing on the CELL Processor
Paraku kasutatakse seal võrdlustes praeguseks juba aegunud algoritmidel põhinevaid programme kuid ma usun et üldpilt ei tohiks eriti muutuda.
Lühikokkuvõte on Cell kõlbab RT jaoks üsna hästi saavutades ühe SPE'ga samal taktil töötavate K8 prosedega sarnast võimsust.
Veidi pikemalt rääkides võib öelda et Cellil ei skaleeru keerukamad shaderid nii hästi kui x86 peal kuid siiski üsna hästi. Dual-Cell (16x SPE) on ~12.2x kiirem kui samal taktil töötav ühe tuumaga Operon kui renderdatakse VW põrnikat koos lihtsamat sorti shaderite ja varjudega.
Infoks veel nii palju et VW stseeni puhul vajatakse mälu läbilaset ~13MiB per frame (4.7M kolmnurkade inffi), koos kaadripuhvrisse kopeerimisega lisandub veel 4MiB.
Paberi lõpus oli neil üks üsna huvitav idee:
| tsitaat: |
As a CELL will be used as the CPU for the PlayStation 3, a
direct high-bandwidth connection to the PS3’s GPU will exist. If
a sufficiently high ray traversal performance could be achieved and
the shading could entirely be done on the GPU, ray traced effects
could finally be delivered to commodity game consoles. |
Kui leidub julgeid pealehakkajaid võib PS3 peal tulevikus kõiksugu imeasju näha
Üritan ka paari tabelit kopeerida, loodetavasti ei keerata vormindust väga nässu. Keda asjad huvitavad vaadaku asju parema kvaliteediga originaalaallikast.
Scene ERW6 Conference VW Beetle
ray casting, no shading
2.4GHz x86 28.1 8.7 7.7
30.1 (+7%) 7.8 (-12%) 7.0 (-10%)
2.4GHz SPE
Single-CELL 231.4 (8.2x) 57.2 (6.5x) 51.2 (6.6x)
430.1 (15.3x) 108.9 (12.5x) 91.4 (11.8x)
Dual-CELL
270.0 (9.6x) 66.7 (7.6x) 59.7 (7.7x)
PS3-CELL
ray casting, simple shading
15.3 6.7 6.6
2.4GHz x86
2.4GHz SPE 14.9 (-3%) 5.1 (-23%) 3.5 (-47%)
Single-CELL 116.3 (7.6x) 38.7 (5.7x) 27.1 (4.1x)
222.4 (14.5x) 73.7 (11x) 47.1 (7.1x)
Dual-CELL
PS3-CELL 135.6 (8.9x) 45.2 (6.7x) 31.6 (4.8x)
ray casting, shading&shadows
2.4GHz x86 7.2 3.0 2.5
7.4 (+3%) 2.6 (-13%) 1.9 (-24%)
2.4GHz SPE
Single-CELL 58.1 (8x) 20 (6.6x) 16.2 (6.4x)
110.9 (15.4x) 37.3 (12.4x) 30.6 (12.2x)
Dual-CELL
PS3-CELL 67.8 (9.4x) 23.2 (7.7x) 18.9 (7.5x)
Table 5: Performance in frames/sec on a 2.4 GHz SPE, a single respectively
dual 2.4 GHz CELL processor system, and a 2.4 GHz x86 AMD Opteron
CPU using pure ray casting, shading, and shading with shadows (at 10242
pixels). Opteron data and 2.4GHz-CELL data are measured, data for the
7-SPE 3.2 GHz processor (as used in the Playstation 3) has been extrapo-
lated from that data. For pure ray casting, our implementation on a single
2.4 GHz SPE is almost roughly on par with a similarly clocked Opteron CPU.
In addition, a CELL has 7–8 such SPEs, and can be clocked at a higher rate.
|
Scene ERW6 Conference VW Beetle
BVH node data 24 1,113 3,724
43 2,797 4,766
Triangle accel data
Vertex data 130 1,278 4,303
Shader data 0.03 87 1.53
202 5,275 12,794
∑
Table 6: Required bandwidth to system memory for loading different types of
scene data (in KB per frame). All scenes are rendered at 10242 pixels using
simple shading, and with 256 entries for both BVH cache and triangle cache.
Due to our caching framework, even the complex VW Beetle requires a mere
12 MB of memory bandwidth per frame.
|
[edit4]
Leidsin veel midagi
Exploring the Use of Ray Tracing for Future Games
Seal räägitakse igasugu huvitavat juttu RT eelistest tavapärase rasterdamise ees, kirjeldatakse juba tehtud mänge ning spekuleeritakse tulevikusuundade üle.
Riistvara koha pealt üks huvitav jupp:
| tsitaat: |
Current research investigates the
performance expected when implementing the RPU architecture in
ASIC technology. Preliminary results show that a completely un-
optimized ASIC with twelve RPU engines should already be able
to achieve between 62 and 250 million rays per second at a clock
rate of 266 MHz and at a resolution of 1024 × 1024 pixels.
Note that these estimates are for an initial prototype of the RPU
architecture in an ASIC process. There is still a significant gap
between the these performance numbers and those from current
GPUs. However, we believe that they are very encouraging given
that the we are looking at first prototypes and compare them to chips
that have been refined over many years. |
Kui õieti mäletan siis stepzter oletas kunagi et GPU'ga võrreldava kiiruse-pildiilu jaoks oli vaja ~1G kiirt sekundis. 32RPU'd@800MHz ja peakski see olemas olema eeldades mõningast optimisatsiooni ning veidi üle worst-case scenario stseene
Peale nende kahe leidsin veel mõned paberid ja ühe doktoritöö mustandi:
Interactive Ray Tracing of Skinned Animations
Realtime Ray Tracing on current CPU Architectures (DRAFT)
Interactive Distribution Ray Tracing
Noid kolme pole ma veel lähemalt uurida jõudnud kuid vaevalt sealt midagi üdsusele väga huvitavat leida võin, need on pigem mõeldud asja pisut jagavale rahvale
[edit5]
Vahepeal on üks tegelane oma raytracerit pisut edasi arendanud.
Tõmmata saab selle siit. Nagu ikka siis miinimumnõue on SSE2 toega prose (AMD k8, P4/PM või uuem).
Tekstuurikoordinaadid on kohati suts sassis, see on data viga. Samuti võib tekstuurimine kohati suts saasta kvaliteediga tunduda, põhjuseks on et prose peal eriti midagi bilinear filtreerimisest ei tahaks teha
Huvitav kui palju see asjandus kiireneks kui kasutada SSE4 ühe tsükli dotproduct funktsioone
Natuke pilte, animeeritult on see muidugi palju efektsem
Quake1 model siiberdab taskulambiga ringi:
  
Natuke udust koridori:
Peegeldused sinistelt pöörlevatelt kuupidelt:
 
Q1 tegelane lähivaates:
   
Võimalik et natives oleks asi sutsu kiirem. Võibolla aitaks ka 64bit prose pisut kaasa oma poole suurema SSE registrite arvuga. Paraku hetkel too vidnin veel 64bit tuge ei oma.
Kellatud quadcore peal saaks sellest üsna talutavalt mängitava mängu teha
[edtit 6]
Taas uuendan teemat
Mäletate et mõnda aega tagasi eelmise aasta lõpus räägiti Quake4 ray tracitud variandist? Too jooksis ~15FPS'iga Q6700 peal resoga 256x256. Nad on vahepeal asja "pisut" paremaks teinud ning täna leiab nende kodukalt benchmarkide alt väikse uuenduse: Update 2007-09-27: Warning! These benchmarks are outdated by more then a factor of 10! . Kiirusekasv pole mitte ainult kiirema prose (2xquadcore Penryn tundmatu taktiga) vaid ka paranenud algoritmidega. Põhilise jõudluskasvu andis just OpenRT pealt Inteli enda MLRTA traceri peale portimine. Too uus demo jookseb 768x768 reso peal ~90FPS'i juures.
Samuti saab downloadide alt tirida näidisvideo kus on asja ka töötamas näha. Paraku on video kvaliteet viletsa võitu kuid mingi ettekujutuse peaks ikka saama.
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
Ganja
HV kasutaja
liitunud: 27.09.2007
|
|
07.10.2007 16:53:03
|
|
|
Tundub vist nii olevat, et taoline asi muutub tulevikus/mõndade aastate pärast kõigile kättesaadavaks
Varsti ongi käes aeg kus ei ole reaalsusel ja arvutimaailmal mitte kui mingisugust vahet
|
|
| Kommentaarid: 1 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
1 |
|
| tagasi üles |
|
|
sakinaga
HV Guru
liitunud: 30.08.2006
|
|
07.10.2007 17:09:15
|
|
|
Kui nii edasi läheb, siis varsti on arvutimaailm "reaalsem"
_________________
Tsensuur HinnaVaatluse foorumis |
|
| Kommentaarid: 159 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
151 |
|
| tagasi üles |
|
|
rene p
HV veteran
liitunud: 05.11.2002
|
|
| Kommentaarid: 70 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
67 |
|
| tagasi üles |
|
|
CnZ
HV veteran
liitunud: 05.11.2003
|
|
18.08.2009 15:41:13
|
|
|
üks suht vana interjvuu Carmackiga, kus ta räägib ray tracingust
http://www.pcper.com/article.php?aid=532
| tsitaat: |
| I think that ray tracing in the classical sense, of analytically intersecting rays with conventionally defined geometry, whether they be triangle meshes or higher order primitives, I’m not really bullish on that taking over for primary rendering tasks which is essentially what Intel is pushing. There are large advantages to rasterization from a performance standpoint and many of the things that they argue as far as using efficient culling technologies to be able to avoid referencing a lot of geometry, those are really bogus arguments because you could do similar things with occlusion queries and conditional renders with rasterization. Head to head rasterization is just a vastly more efficient use of whatever transistors you have available. |
põhimõtteliselt ta räägib, et videokaardid vajaksid siis ~3-4x paremat clock speedi inteli Larrabee arhitektuuriga, et ray tracingus eelist näha.
| tsitaat: |
| that means a GPU speed of 3.0 GHz or higher when we use today's AMD and NVIDIA GPUs as a reference. |
küll aga näeb ta ray tracingus eelist tema enda nn sparse voxel octrees mudelis. tegu visiooniga, kus geomeetria tuuakse mängumootorisse asendades polygonid voxelitega (volumetrix pixel). tema sõnul peaks see asi osa olema id Tech 6'st. küll aga ei näe ta conventional renderdamisel eelist rasterduse ees.
huvitav intervjuu igatahes. kes pole veel lugenud.
|
|
| Kommentaarid: 14 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
13 |
|
| tagasi üles |
|
|
Ho Ho
HV Guru
liitunud: 16.02.2002
|
|
03.10.2011 13:41:39
|
|
|
Kerge nekro
http://www.4gamer.net/games/017/G001762/20110920023/
 Spoiler
Pöörake tähelepanu pildi vasakul alanurgas kirjas olevale asjale. Kõlab huvitavalt
_________________
Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
|
|
| lisa lemmikuks |
|
 |
sa ei või postitada uusi teemasid siia foorumisse
sa ei või vastata selle foorumi teemadele
sa ei või muuta oma postitusi selles foorumis
sa ei või kustutada oma postitusi selles foorumis
sa ei või vastata küsitlustele selles foorumis
sa ei saa lisada manuseid selles foorumis
sa võid manuseid alla laadida selles foorumis
|
|
Hinnavaatlus ei vastuta foorumis tehtud postituste eest.
|
:: KKK
:: otsing 
:: statistika
:: kasutajate nimekiri
:: kasutajate grupid
:: registreeri
teata moderaatorile
