Keresés

Hirdetés

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

  • rudi

    nagyúr

    válasz Raymond #12 üzenetére

    Még van majdnem két teljes év az évtized végéig, szerintem annyi idő alatt összejöhet.

    Resistance Is Futile. You will be assimilated!

  • ddekany

    veterán

    válasz Raymond #18 üzenetére

    "A mult evi raytracing suketeles utan mar az Intel is abbahagyta"

    Soha nem is értettem, miért hülyítik olyan dolgokkal a népet, amiről a mérnökök tudják előre, hogy beégés lesz belőle. De tényleg, minek? (Netán tényleg megcsinálják??? :F Áhhh, inkább én is beállok a 19"-os TFT evők közé. :) )

  • dezz

    nagyúr

    válasz Raymond #18 üzenetére

    Intel pushes Raytracing again
    GDC 08: Daniel Pohl talks it up

    Izé, ebben sem fogunk egyetérteni, mert szerintem is sokkal jobb dolog a ray-tracing. ;) Nem kell mindenféle idétlen, irreális trükközés ahhoz, hogy "automatikusan" élethű legyen a kép, árnyékokkal, stb. (Pár éve én is írtam egy ray-tracert [asm-ben :DDD ], és tervezem továbbfejleszteni. Az akkori gépek még túl lassúak voltak, de most már ott van a PS3, jön majd a Larrabee - kimondottan erre optimizálva, és nem raszterezésre, stb.)

    [ Szerkesztve ]

  • Genialis

    aktív tag

    válasz Raymond #37 üzenetére

    Az Intel simán le fogja nyúlni az ötleteket a Cell-ből is, mint ahogy lenyúlta a Risc processzorokból, meg az Amd-től. 2010 körül meg fognak jelenni a SPU-k az x86 vonalon is, legfeljebb úgy hívják majd, hogy SSEn+x. Szóval nem süketelnek.

    in4m8ion 1ts 2 B 3

  • shabbarulez

    őstag

    válasz Raymond #39 üzenetére

    Miért gondolod azt hogy ennek úgy kellene történnie hogy hopp 2010 van, mától minden raytrace és kész, azért mert az Intel kiadta a Larrabee-t. Ez nem így működik. Ugyanaz a folyamat fog lejátszódni, mint pl. anno amikor még csak software renderelés volt, aztán a quakekel megjelent az első hw-en támogatott 3D engine is. Ott is a felhasználó választhatott a két mód között, az elején többen quakeztek softwares módban, mint hw-es támogatottsággal és hosszú folyamat volt a váltás itt sem két nap alatt fog lejátszódni. Anno már tavaly is írtam hogy az Intelnek a sw-es háttér lesz a keményebb dió, az hogy be tudja vinni a termékét a piacra. Ehhez várható hogy pl. vesznek pár engine-t akár a fizikai akár a vizuális megjelenítés területén, valami nagyobb nevet bekebelezve akik több játék alá teszi az enginejüket. Ez átírjaták úgy hogy raszteres és raytrace megjelenítést is támogassa hogy legalább az átmenet elkezdődhessen. 2010-ben szerint ennyi fog történni, nem lesz földindulás és lassú lesz majd az átmenet.

    Egy mai mainstream 2 magos proci úgy 25-30 Gflops-ot tud egy felsőkategóriás 4 magos a dupláját. A Larrabenál 300-1000 Gflops körüli teljesítmény ígérnek 2010 körül, ami egy nagyságrendnyi számítási teljesítmény növekedés. És ez 2012-ben, 2014-ben az új gyártástechnológiák 22, 16 nm kijövetelével ugyanúgy növekszik majd ahogy eddig is. Ráadásul ahogy videokártyáknál az SLI úgy processzoroknál is képbe jöhet a 2 vagy 4 socketes kialakítás mainstreamesedése.(a különálló videokártyáknak meg az lassú eltűnése, amit leginkább a nvidia fog megsínyleni). Ez 4 év alatt megint hozhat együttesen egy újabb nagyságrendnyi teljesítmény növekedést, és persze közben a software rész is fejlődni fog, ahogy Pohl fejlesztések sw része is igen dinamikusan fejlődött az elmúlt évek során. Ez együttesen megteremtheti az alapot az RT-nek, főleg ha lesznek olyan enginek amik mindkét módot támogatják, ugyanúgy ahogy anno sw/hw renderes átállás idején is történt.

  • dezz

    nagyúr

    válasz Raymond #37 üzenetére

    Attól függ, hány magos lesz a Larrabee... Ha csak 2-4x annyi, mint a Cell 8 SPE-je, az kevés lesz (tekintve azt is, hogy valószínűleg nem lesz annyira hatékony 1-1 mag, mint 1-1 SPE). Ha még ennek többszöröse, az már kezd elég lenni játékokra is. Legalábbis indításként.

    (#41) decibel: Erről azt lehetett hallani, hogy tud majd raszterizálást, hogy az erre építő játékok is elmenjenek rajta, de csak közepes teljesítménnyel. Ray-tracingre lesz gyúrva.

    (#47) Abu85: Az elméleti számítási teljesítmény néha nagyon távol áll a valóstól. Nézd meg a #36-osban linkelt oldalon, hogy viszonyul egymáshoz a G80 és a Cell ray-tracingben: 2x-es elméleti FLOPS, ehhez képest 1/5 teljesítmény (a G80 részéről)...

    (#51) Raymond: A GPU-k is kezdenek belassulni, ha komplexebb dolgokat akarunk velük csinálni, a nagyobb élethűség kedvéért... (Lásd pl. az Nvidia füstös demóját.) Közben nem láttam még olyat tőlük, ami ne lett volna teljesen mű. A ray-tracing nem csak 1-2 tükröződő felület, hanem számos dolgot könnyebben, és mégis élethűbben lehet megvalósítani. Csak többet kell hozzá számolni. Aztán később jöhetnek majd olyan dolgok is majd, mint radiosity, stb.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #53 üzenetére

    Inkább a raszterizálásnak kellene alaposabban utánanéznem (de ez nem fog bekövetkezni, mert nem szeretem). A ray-tracing az nagyjából megvan (mint írtam, írtam már ray-tracert, persze nem éppen Mental Ray szintűt [voltak textúrák, árnyékok, becsillanás, tükröződés, és persze árnyalás]).

    Kezdeném a szokásossal: többszörös tükröződés, amiben az árnyékok és minden szépen ott van, valós időben. Az említett élethű füst-effekt. Tömör, átlátszó, fénytörő anyagok. Változó függvény alapú felületek és terek. Metaballs. Most így hirtelen ennyi, de nem gondoltam jobban bele.

    [ Szerkesztve ]

  • ddekany

    veterán

    válasz Raymond #53 üzenetére

    "Mondj harmat. Es sok sikert mert nem lesz konnyu."

    Nem hiszem hogy értelme lenne itt felsorolni, avagy pontosan milyen raytracking-ről van szó? Egyszerűen egy komoly (lassú!!!) raytracing végeredménye valósághűbb mint egy raszterizálásé, és épp azért mert -- leegyszerűsítve -- nincs benne külön csel árnyékra, tükröződésre, szórtfény térbeli változására, stb-re, hanem sokkal inkább csak adódnak ezek a dolgok. Viszont, a raytracing elég tág fogalom, és pl. lehet valami úgy is raytracing, hogy teljesen "művi" marad a kép, mert hisz gyorsan akartunk végezni. Gondolom az ominózus Quake-os demó is valami agyonegyszerűsített raytracking-et használ.

    "Ne3zd, minden belassul ha eleg komplex szamitast raksz ra"

    Továbbra is kérdezem, hátha vki tudja, hogy a scene komplexitásának növekedésére és az effektek egyre inkább elszabaduló halmozódása esetén nem lehet-e, hogy a raytrace elvű megjelenítés lassabban lassul be mint a raszteres. Mert akkor nagyon hosszú távon lehet itt még váltás.

    Azt persze nem akarom elhinni (ezt Dezz mondta), hogy az Intel elsősorban raytrace alapon akarja működtetni a következő grafikuskártyáját. (Már feltéve hogy az nem 10 év mulva jön ki...)

  • ddekany

    veterán

    válasz Raymond #59 üzenetére

    Izé... én "komoly (lassú!!!) raytracing" alatt olyat értettem, amiben van GI (global illumination -- gyakorlatilag szórtfény hatásának utánzása) is, meg efféle nyalánkságok. De végül is ezek nem csak a raytracing kiegészítéseként működhetnek, szóval OK, rossz voltam, ez nem raytracing. Bár, pl. GI-ben, (és IBL-ben?) na meg AO-ban (Ambient Occlusion), legalábbis bizonyos megvalósításaikban, megint csomó kilövök-egy-sugarat-és-megnézem-kit-talál-el művelet van, szóval az is egyfajta ray tracing ha szó szerint értelmezzük a kifejezést, nem a szokványos jelentésében. Lehet hogy Inteléknek is majd ilyen alapon sikerül idekeverni a ray tracing fogalmat... csomó 3D-s dologban hasznos a sugarak lövöldözése, pl. akár ütközésvizsgálatban is, tehát akkor ők most jól megtraceolták a lightot. :)

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #60 üzenetére

    Végignéztem pár GT-HD videot, és tényleg nagyon szép, meg minden, de olyan igazán élethűnek nem mondanám (mást persze még kevésbé). A füst (vagy mi) meg egyenesen kapásból feltűnően "játékprogramos" (poligonos). És ugyebár statikus környezet tökröződik (mozgó alakok, többi autó nem).

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #67 üzenetére

    Jó, tükröződnek egymásban, de nem oda-vissza. :D
    Természetesen a falnál sem 1x-es tükröződésre gondoltam, hanem oda-vissza.

    A klasszikus ray-tracingben élesek az árnyékok, de itt is vannak újabb megoldások.

    "Abban a fust demoban nem a megjelenites volt a plane hanem az hogy az egyenlet szamolast is a GPU vegezte. Tehat a raytracinghez semmi koze."
    Lényeg, hogy lassú volt - ez volt a köze, mint már írtam.

    "Ugyanugy ahogy a voxeleknek sincs."
    Önmagukban nincs, de van, amikor úgymond egy sugarat engednek át rajta.

    "Nem ugy nez ki. Mar egy R300 is siman birta a HL2-ben."
    A HL2-t nem néztem eleget ahhoz, hogy ilyet lássak benne, de pont R300-ra volt egy fénytöréses demó, és igen lassú volt.

    "Latod ez meg vegkepp kiutne a raytracing algoritmust. Ujrageneralni a haromszogeket framenkent?"
    Raszterezéskor! Éppen hogy (fejlettebb - ennél nem poligon alapú) ray-tracingben meg nem kell.

    "Sok haromszog nem megoldas semmire. Az megol mindent raytracingel vagy anelkul. A haromszogeket okosan kell felosztani es azert nincs meg full automatikus modell generalas. Olyan algoritmust meg nem talalt fel senki amely lekorozne egy embert a modell optimalizalasaban."
    Éppen ezért jobb itt a ray-tracing.

    "Meg a LOD-ot sem veletlenul tallatak ki. Minek dolgoznal fel egy 250e polygonbol allo modellt ha az 100 pixelt foglal el a kepernyon? Ennek semmi ertelme."
    No azért ne a ray-tracing legbutább megvalósítását vegyük már elő. :)

    "Nezz mar meg par sokeves demot a www.scene.org oldalon. Metaballs effektet mar a 7.14Mhz-es Amigam is mutatott pedig abban FPU sem volt. De meg mindig nem ertem mi koze lenne ennek a raytracinghez."
    Aha, pár labdaccsal. Pár ezerrel már nem olyan jól boldogulna - egy GPU sem. Ray-tracingben meg pár függvény.

    Metasurfaces - ezt a kifejezést kerestem egyébként.

    Faces != poligons. Háromszögeknél 3 a váltószám, nemde? (Vagy talán 6, ha mindkét oldalt külön vesszük.)

    (#66)-ra: közben utánanéztem, és nem run-time ray-tracing, hanem előreszámolt mapokkal dolgozik.

  • Dare2Live

    nagyúr

    válasz Raymond #71 üzenetére

    szerintem elég evidens, hogy intel első körben legalábbis elsődlegesen nem real time játékokra szánja a GPGPUt. Van még 1001terület ahova nagyon jól jön ez a fajta TFlopsos teljesítmény.

    don't look up, don't look up, don't look up, don't look up, don't look up, don't look up, don't look up...

  • dezz

    nagyúr

    válasz Raymond #83 üzenetére

    Ugyebár arról beszélünk, hogy melyik technika mennyire számítás-igényes, nem-e? Így egy élethű(!) füst (tűz, stb.) raszterizált és ray-traced kiszámolása lassúságának összehasonlítása értelmes művelet... Vagy mégsem? :)

    A voxelekkel akár raszterezés közben is lehet sugaras alapon számolni, shaderből persze. Úgy emlékszem, volt ilyen demó is valahol.

    "Az ATI szereti egyebkent hasznalni a tech demokban ha megnezel parat."
    Khmm... "pont R300-ra volt egy fénytöréses demó, és igen lassú volt." (De valóban, több is volt.)

    Az említett demóban lehetett váltani egyszerűbb és élethűbb fénytörés között. Előbbi gyors volt, utóbbi lassú. Előbbi gagyi volt, utóbbi már jobb, de nem olyan, mint az igazi üveg, pl. egy ray-tracerben... Erről beszélek, a félig élethűségről, ami nekem nem jön be. Nem olyan szép, nem olyan izgalmas. (Remélem, ha valaha jobban behálózza az életünket a virtual reality, az nem ilyen lesz.)

    "egy par $os chipel akkor senki nem fog azzal foglalkozni hogy fizikailag pontosan lemodelezze par 100 $os CPU-n"
    1. Hmm, az elsőnél az anyagköltséget veszed, a másodiknál meg a végfelhasználói árat, vagy hogy? A nagykerben pár dolláros chipek "szart sem tudnak", és a Larrabee sem többszáz dollár lesz. (Talán a GPGPU-ra szánt kártya-változat.)
    2. Hol van a ray-tracing a fizikailag pontos lemodellezéstől...?

    "Dinamikus scene-el mit csinalsz?"
    Arról beszélek, hogy adott megvalósítás esetén nincs különbség dinamikus és statikus között. Ugyanaz a függvény... Ilyenkor nincsenek poligonok, csak függvények. Egy függvény, és egy egyenes metszését kell kiszámolni. Persze itt is lehet optimizálni különféle módokon, pl. éppen "az objektumok felosztasa darabokra" - csak nem poligonok mentén.

    A függvény komplexitásától függően lehet lassabb, vagy épp gyorsabb, mint x számú poligonnal végzett raszterezés. Így ma különlegesebb függvényeknél az optimalizáció éppen a poligon-generálás, és az azzal való számolás. De ez változhat, ahogy gyorsulnak a gépek. (Bár még talán távoli dolog, de megemlíteném, hogy a kvantumszámítógépeknek gyerekjáték lesz a leg függvény is...)

    "minimalizalni a belepo adatok mennyiseget"
    Erről (is) beszélek. Mondjuk egy pár paraméteres függvény is lehet igen komplex.

    Na ja, nem kellene félálomban fórumoznom (északai bagoly vagyok, de ha előző nap nem aludtam, úgy már nem az igazi :) ) - szal a poligon szó helyén vertexet láttam. :D A többit természetesen magam is tudom. De amikor pakolod kifelé a háromszögeket, akkor nem számít, hogy hol érnek össze, és hol nem: három oldallal kell számolnod. (Árnyalásnál persze számít. Meg persze abban is, hogy mennyi a bemenő adat.)

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #93 üzenetére

    "Nem, a raytracing-rol beszelunk es annak megvalositasarol jatekokban. Ezert lenne jo ha mar hagynad a fustot es a tobbi nem ide tartozo dolgot. Szamitasigenyes vagy nem az lenyegtelen, nem a raytracinghez tartozik. Az sem hogy az a fust realistikus-e vagy nem. Ezt ejtsd legyszi mert egyaltalan nem a temahoz tartozik. Mondtam mar a legelejen amikor azt a techdemot felhoztad."

    Te most ugye csak hülyéskedsz? Vagy tényleg nem látod át, hogy jönnek ide a raszteres képgenerálás azon esetei, amikor hasonlóan lassú, mint a ray-tracing?

    Előbb-utóbb mindenképpen megvalósítható lesz otthoni körülmények között is, ez nem kérdés. És mint írtam, volt erről egy grafikon, de még mindig nem találom, miszerint egy bizonyos komplexitás után a ray-tracing a gyorsabb. Attól kezdve miért is használnák tovább a másikat?

    A jövő ugyebár egyre inkább a párhuzamosításé. A ray-tracinget mintha direkt sokszoros párhuzamos feldolgozásra találták volna ki, szinte lineárisan skálázódik a teljesítmény a magok számával, stb. A raszteres grafika minden fő elemét lehet ennyire jól párhuzamosítani?

    "Mindig csak egy R300-as demot hozol fel (melyiket egyebkent?)"

    Kettő is volt, az egyikben valamilyen vároteremfélében keringtek különféle tárgyak, a másikban egy erdőt ábrázoló háttér előtt, egy emelvényen volt egy 3 üveggömbből álló szoborféle.

    "de ahogy mondtam a fenytores megvan oldva raytracing nelkul is ertelmes minosegben. Nem egy jatekban vagy offline rendererben."

    Igazán jó minőséghez mennyi idő tartozik?

    "Pedig a belinkelt Ferraris demo kimondottan nem szep es nem elethu meg par eves szinvonalhoz hasonlitva sem."

    Szerintem a vége felé már elég jól nézett ki, de tény, hogy bevilágításilag elég amatőr munka volt. Szal lehetett volna szebb is művészibb kivitelezéssel.

    "Ezen kivul magad is lattad hogy mi kell az eloallitasahoz."

    Természetesen láttam. De nem is holnap akarják bevetni a ray-tracinget játékokra. Ez amúgy sem játék-orientált ray-tracer.

    "Ad hardver arak - mindkettonel a vegfelhasznaloi arat vettem. Chip vs. chip."

    És mi értelme végfelhasználói árakat venni (tippelni előre)? Fontosabb, hogy az előállítási költség mennyi, a végfelhasználói árat a belátásuk szerint állapítják meg. Ha piacot akarnak szerezni, alulárazzák, stb.

    "Lehet az arakkal jatszani, de a akkor sem lesz jobb a helyzet. Amit linkeltem GT5P kepeket tudod min megy. Egy NV40 derivaton."

    NV45=G70/71 derivát.

    "Most nezd meg mi kraft van ahoz kepest egy mondjuk 150 EUR-ok HD3850-en. Es az mar egy kartyas, RAM-os vegfelhasznaloi ar most, nem valamikor 2 ev mulva amikor ugyanannyiert egy 4x erosebb chipet kapsz minimum."

    Shaderben 4x erősebb - és minden másban is?

    "Ezt mire alapozod? Mert en mar csak a meretbol es tranzisztor szambol itelve sem tudnam a mainstream vagy budget kategoriaba besorolni."

    Azt majd az Intel eldönti... Különben sem most jön ki, hanem valószínű 32nm-en.

    "Ahogy egyelore kinez a dolog a raszterezo hardver fenyevekre van barmelyik raytrace megoldastol ami a poligonok feldolgozasat es runtime optimalizalast illeti. Es nem ugy nez ki hogy ez valtozna a kovetkezo jopar evben. Larrabee es CELL ide vagy oda."

    Elő kellene szedni azt a grafikont, amit említettem, és megnézni, milyen komplexitásnál érnek egy szintre, ill. kezd jobban kijönni a ray-tracing.

    "Es ez mitol jobb vagy eppen mas mint a mostani GPU megoldasoknal? Mert en nem latok kulonbseget. Ahogy irtam, mindehol (offline es realtime) egyarant arra torekszik mindenki hogy minel kevesebbet kelljen szamolni. Meg az offline raytracing renderenel is ahol percegik, tizpercekig vagy orakig tart egy frame generalasa arra torekszenek nemhogy ott ahol 30 frame a kovetelmeny masodpercenkent."

    A ray-tracing kvázi lineárisan skálázódik - a raszterezés is?
    A ray-tracingnél nem-sík felületek adott esetben gyorsabban számolhatók egy függvénnyel, mint poligonokká alakítva.

    (#95) Kopi31415: És akkor most te abból az animációból akarod levonni, hogy mire képes a ray-tracing...?

    "Egyébként ha ezeket nem egyetlen processzoral számolják, max egy koproceszorral, akkor nagyipari alkalmazásban elfelejthetőek."

    Ez egy baromság, már megbocsáss. Renderfarmokról hallottál már? Meg nézd már meg azt a Boeinges cikket, direkt a tervezésre építettek egy gépet, jópár Cellel és Opteronnal.

    A PS3-ban 1db Cell van, ami összesen 9 magos (de ott egy mag le van tiltva).

    Otthoni játékgépként felejtős az ilyen, igen.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #100 üzenetére

    "Nem hulyeskedek de sokadszorra sem akarod felfogni. Az a demo nem a kepgeneralasrol szolt hanem arrol hogy a fluid szamolast el lehet vegezni a GPU-n. Semmi koze a raytracing alapu kepgenerelashoz. Remelem most mar eleg lesz."

    TUDOM, BAZDMEG, TUDOM. HÁNYSZOR KELL MÉG LEÍRNI, HOGY NEM EZ A PÁRHUZAMVONÁS LÉNYEGE????

    A többit mindjárt, de ez már nagyon felbaszta az agyamat.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #106 üzenetére

    Már kb. 20 hsz-szel előrébb leírtam: ha bizonyos effektek (pl. élethű füst, tűz, stb.) kiszámolása raszterizációval is hasonlóan lassú, mint ray-tracinggel, akkor már nem mindegy, hogy ez vagy ray-tracing? (Nem csak az Nvidiás demóból kiindulva.)

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #100 üzenetére

    "Megint semmi konkret adat nincs. Majd ha megtalalod a grafikont visszaterhetunk ra. Addig semmi ertelme es addig itt a valosag amit lathatsz az altalad linkelt demok es a mar ma jatszhato jatekok kozt."

    Annyi értelme van, hogy előbb-utóbb elérünk arra a pontra, amikor már a ray-tracing a hatékonyabb.

    "Mert a mostani shader alapu grafika nem parhuzamosithato? Mert egyelore ugy nez ki hogy igen ezert olyanok a GPU amilyenek."

    A shaderek igen, de ugyebár a raszteres grafika nem csak abból áll.

    "A raytracing minden eleme ennyire jol parhuzamosithato? Nincs semmi ami visszafogna?"
    Úgy tűnik. [link] (ezt már magad is linkelted), [link] (MS-os anyag :) ), stb.

    "Az R300 demo a "HDR demo volt". Meg ma is jol nez ki. Es az igazan jo minseg shader alapu refractionnal ugyanugy realtime mint a tobbi. Itt nincs ertelme olyan algoritmusnak ami nem megy interaktiv framerate-en."
    Volt egy másik hasonló is. Hát eléggé belassult fénytörésnél, pedig csak egy object volt. Azt se felejtsd el, hogy nem mindegy, hogy csak egy kép van mögötte, vagy egy egész scene. Ray-tracingnél egyszerűen csak megy tovább a sugár(vissza)követés a kilépő ponton, raszterezésnél hogyan tovább?

    "Az hogy a Ferrari demo ugy nez ki ahogy nem csak annak koszonheto hogy amator munka. Itt megint elojon az amirol vagy elfeledkezel, vagy nem tudod vagy elhallgatod mert nem illik a mantradba. Az hogy a jobb megvilagitashoz nem lenne eleg az amit csinalnak mert a raytracing nem a szent gral. Es ehez nincs mit hozzafuzni. Annyit csinalhattak volna meg hogy (eleg komolyan) megnovelik a fenyforrasok szamat (GI szimulacio) es javitanak az algoritmuson"

    A Global Illumination többé-kevésbé kiváltható az Ambient_occlusion-nal, amit használ is. És vannak más, nem olyan lassú megoldások is a megvilágítás élethűségének növelésére, vagy pl. a soft shadows-ra (és nem a sok lámpa - lásd pl. MS-os paper), stb.

    "de akkor mar hoppa - oda a realtime tenyezo."

    Max. beraknak még pár Cell blade-et...

    "Egyebkent meg nem nez ki jol. Ahogy mar irtam meg a realtime jatekok vilagaban is messze afolott a minoseg folott jarunk mint ami ott volt. Az egyetlen amit fel lehet hozni az a tukrozodesek minosege (micsida meglepetes). Semmi mas. Meg a kocsi lakkozasanak megoldasa is elmarad egy normalis szinvonaltol."

    Láttam már sokkal szebb ray-tracelt animot - jópár évvel ezelőtt, PC-n számoltatva. Persze az nem real-time volt, csakhogy sokkal lassabb gép is volt egy ilyen Cell alapú clusternél, szal talán az is real-time mehetne ma egy ilyenen.

    "Az hogy ez nem egy jatek engine nem jelent semmit. Mert jatekok reszerol meg itt sem tartanak. Lattad mi letezik - a Pohl Quake3 cucca ami olyan poligonszamokkal dolgozik az egesz levelre amilyenek az ujabb jatekoknal 1 (egy) karakter tartalmaz."

    Honnan tudod, milyen fejlesztések mennek még színfalak mögött? Meg aztán megnézhetnél pár PC-s ray-tracing demót... Azokat átvíve Cellre szerintem kicsit gyorsabb lenne, mint ez az IBM-féle iRT (amiben pl. követelmény volt, hogy automatikusan szétossza magát x Cellre, a memória-kezelésben is van automatizmus, stb.).

    "Ha ezt megnoveled a tizszeresere akkor sem ersz el semmit. Egy normalis jatek manapsag tobb millio poligont nyomat framekent komolyabb minosegben es nagyobb FPS melett."

    Akkor is mű az egész... Hol vannak a nagyszerű, és szupergyors raszterezős megoldások, amik ezen segítenek?

    "De mondom, ha tudsz olyan megoldasrol amivel beolvasol egy (ne legyunk telhetetlenek) 1 millio poligon/frame scene-t es megjeleniti legalabb mondjuk 25FPS-el 720p-ben mondjuk ket darab 3Ghz 4magos C2 procin akkor azt megnezem. Meg komolyabb minoseg sem kell, eleg az ami a Ferraris demo vegen volt. Meg AA sem kell."

    Miért egy ilyen konfigon? A Larrabee-n kellene ezt megvalósítani az Intel szerint.

    ("NV45=G70/71 derivát.")
    "Legyen G71-es hogy komolyabb szamokkal dolgozhass (pedig nem az)."

    Pedig az.

    "Meg igy sem valtoztat a lenyegen hogy sehol nincs az a chip a main low-mainstream kartyakhoz kepest teljesitmenyben."

    Ez most nekünk miért is fontos?

    "Varj csak...valtik azt allitottad a fust es voxel peldakkal hogy azert kapcsolodnak a temahoz mertt ott is szamolasrol van szo. Akkor a 4x shader teljesitmenyen kivul meg lenne meg fontos?"

    Hát egy teljes scene kirajzolása, összességében.

    "Aztan ott van meg a FlexIO-n keresztuli 20 ha jol emlekszem csak az nem mindenre hasznalhato"

    Hozzáférhet az XDRAM-hoz, szóval legalábbis textúrát olvashat onnan, de egyébként írni is tud oda is (ezt 15 GB/s-sel).

    "A Larrabee arat te jelentetted ki olyan magabiztosan hogy alacsony lesz. En csak mondom hogy minden eddigi sokeves tortenelembol itelve nem lesz alacsony aszerint amit a chiprol tudni lehet. A 32nm technologiat is mar figyelembe veve."

    Én nem mondtam árat, csak piaci szempontokról beszéltem.

    "Megint vissza oda amirol mar szo volt. Hogyan csinalsz meg egy levelt nem sik feluletekbol?"

    Ha körülnézel magad körül, van bővel nem-sík felület... De persze nem tiltott a sík felület használata sem.

    "Hiaba gyors ott a raytracing ha nem tudod felhasznalni semmire. Vagy ha felhasznalod, ok, de hany szazalekat fogja egy scene-bol kitenni? Es mit csinalsz a tobbi resszel amit poligonbol kell megcsinalnod. Reszletesen, texturazva, animalva stb? Ha szarra losz egy szobat vagy a kornyezetet ugy altalaban (inkabb ez ma a norma mint kivetel) akkor sem kell uj setup az egesz scenere ha raytracinget hasznalsz? Mert szerintem kell. Es akkor lehalt az FPS-ed is es a teoriad is a raytracing tutisagarol. De meggyozhetsz az ellenkezojerol."

    Majd máskor. :)

  • dezz

    nagyúr

    válasz Raymond #109 üzenetére

    Ha meg lehet állítani a füst mozgását, próbáld ki, felugrik-e az fps. Szerintem komolyabb, élethűbb füstnél, tűznél egyszerűbb és gyorsabb ray-traciggel csinálni. És nem a keretet, meg a padlót, hanem magát a föstöt, tüzet leképezni.

    (#110): Nem tudom, nálam 6600-ason megy.

    Kötve hiszem, hogy a dynamic branching miatt lett volna olyan lassú G80-on, mert akkor a szerző nem mondta volna azt, hogy "This kind of algorithm is pretty much ideal for the GPU"... Miközben G80 Dynamic Branching 20x slower than X1950XTX... A G92-n mitől is lenne hirtelen 5x gyorsabb, amikor az alig más, mint egy G80, kisebb csíkszélen? Mellesleg az SPE-k sem szeretik a túl sok ugribugrit.

    "Az 1.6M poligonos auto modell raytracing-el 10 FPS-t produkal 2 CELL-en (16 SPE). A normalisabb minosegu pedig csak (majdnem) 4-et."

    Azért 1.6m poligon már nem olyan kevés, tekintve a korábban említett számokat...

    (#111) Kopi31415: Külön Boeinges link még nem volt, csak kép, és ott a Roadrunnert nem említettem. Mint már írtam, nem így tervezték. De korábban nem nagyon jelenítették meg egyben az egészet.

    A fénytörést eléggé befolyásolja a sűrűség, azaz a fénytörési index. Attól függően eléggé eltérő lehet két anyag között.

    "Egyébként meg: ha olyan jól skálázódik a raytracing egy bizonyos bonyolultság fölött, és jobban megéri függvényként számolni vele, akkor vajh miért diszkretizálnak midnen modellt végeselemhez, ha meg akarnak kapni valamit, akár áramlást, akár rezgést, akár bármit, CFD, FEA területen?"

    A jobb (majdnem tökéletes) skálázódást és a függvényes tárgyleírást ne egyszerre tárgyaljuk. Az egyik egy általános tény ray-tracingre vonatkozólag, a másik természetesen csak bizonyos esetekben igaz.

    "Te tényleg azt akarod bemesélni, hogy egy felületi mikro és makroegyenetlenséggel megáldott nyeregfelület fényvisszaverési viselkedését gyorsabb, könyebb lemodellezni egy pontos függvénnyel, mint közelíteni egy síklapokból áló elemmel?"

    Ezt így nem mondtam. Bizonyos esetekben gyorsabb lehet, más esetekben nem. Ha pl. folyamatosan változik egy komplex függvénnyel leírható felület, vagy test, akkor gyorsabb lehet kihagyni a poligonokat. Lásd pl. azt a "deformálódó gömbös izé"-t, ami egy térbeli Julia...

    "A folytonos függvényre minden pontban ki akarod számolni az értékeket?"

    Ezt hogy kell érteni?

    "Vagy valahol diszkretizálsz? Ha utóbbi, akkor mégis mi az a nagy jobb skálázódás?"

    Ha már ott vannak a poligonok, nem mindegy, hogy honnan származnak? Nem attól skálázódik jobban a ray-tracing a szálak számával, hogy honnan származnak. ;)

    "Az a bizonyos logaritmikus teljesítmény: kéne valami link róla, vagy bármi. Így eléggé messziről jött ember jellege van."

    Szerintem ezt itt nem vitatja senki rajtad kívül. Kénytelen leszel rákeresni.

    (#119): "Ez szép és jó, de egy pixelbe mennyi irányból eshet be a fény? Innentől akkor hol lesz valósághű? Köszönöm, ez nem lesz az."

    Ajjaj. A "rossz" irányból jövő (és nem beeső) rossz irányban is folytatja az útját, azaz nem a szemünk adott pixelt leképző pontjára érne, így kit érdekel, honnan jött, és hová ment... ;) Vagy te már rögtön hologramot akarsz renderelni? :DDD (Egyébként 8.-os optika.)

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #135 üzenetére

    "Ja, es a raytracing is nem csak a sugarkovetesbol all. Ezt valahogy elfelejted mar tegnap ota minimum Az nyirja ki a raytrace enginedet hogy egy jatek scene nem statikus. Es akkor a frame setupnal meghalsz."

    Nem felejtem el. Miért halnék meg jobban, mint raszterezésnél? És itt legalább nem kell mindenféle map-generálásokkal kezdeni. (Már amikor azok dinamikusak raszterezésnél, mert ugye sokszor nem azok.)

    "Mondtam ha nem igy van, bizonyits be egy mukodo demoval. Sok sikert."

    Azon leszek, köszi.

    "Az R300 demonal nem tudom melyik masik hasonlorol beszelsz. Azok alapjan amit leirtal az volt amit irtam."

    Mint írtam, az egyik egy múzeumféle volt lebegő tárgyakkal, a másik meg egy tisztás egy szoborfélével.

    "A scene komplexitasrol meg annyit hogy annak a demonak pont az volt a lenyege - az a hatterkep volt a IBL forrasa. Egyebkent a Lambo- raytrace demoban sem latom hogy tomve lenne a hatter barmivel is"

    Persze, de éppen erről beszélek, hogy mi van, ha ott nem csak egy kép van, hanem egy dinamikus scene. Raszterezésnél minden képkockánál a 6 fő irányban le kell renderelni az egészet, ráadásul nagyfelbontásban, hogy nagyító hatásnál ne legyen randa. Ray-tracingnél meg annyi sugár megy tovább, mint ahány pixelt elfoglal az objekt a képernyőn. (AA-t mindkét esetben félretéve.) (Az olyan statikus, 1x számolt mapot inkább hagyjuk, amikoris a táj látszik, a mozgó objektek viszont már nem.)

    Itt nincs semmi a háttérben?

    "Nezd meg az a sok belinkelt GT5P videot es kepet - hat ugy Egesz jol megy nekik szeritem."

    Ott hol van fénytörés?

    "A GI-t nem valtod ki Ambient Occlusion-nal mert mindketto masrol szol. Kicsit olvass utana."

    Megtettem (még linkeltem is): "However, it is a very crude approximation to full global illumination." [link]

    "Az arnyekok megoldasa meg milyen erv mar? Ha mas megoldast hasznalsz akkor hogy tamasztja ala a raytracing-es ervedet?"

    Úgy, hogy ott is ugyanazt a tengely+metszés eljárást használják, csak nem egyet számolnak ki, hanem pl. 3-at, és átlagolják az eredményt.

    "Kismilliomodszorra leirva - mi koze van ennek az otthoni megoldasokhoz hogy a jatekok raytracing enginet hasznalhassanak? Semmi."

    A 14 Cell eleve nem otthoni környezet, így az az érv, hogy sok fényforrás, vagy más efféle alaposan leterheli, nem igazán ésszerű érv... Mert itt mindegy, hogy 14 vagy 25. Lényeg, hogy egy íróasztalon elférő cuccal képesek elég jó ray-tracingre real-time ma is.

    "Wow - offline render? Es akkor mi van? Semmi koze ahoz amirol most beszelunk. Mehet vagy nem az egy dolog a masik meg hogy nem latni sehol hogy menne."

    Talán mert az offline renderelőkkel manapság nem is erre törekednek? Hanem nagy precizitású, a játékok grafikáját alaposan meghaladó minőségre.

    "A realtime raytrace demok meg ugy neznek ki ahogy."

    Azért nézzél meg párat ebből is. Aztán szorozd meg úgymond az egészet annyival, amennyivel több mag lesz a Larrabeeben, mint a mai procikban.

    "Az hogy mi megy a szinfalak mogott milyen erv mar megint? Honnan tudod a tobbi megoldasnal mik mennek a szinfalak mogott? Ja ugy hogy par honapjara ra kijon valami es lathatod a sajat szemeddel egy jatek formajaban? "

    Éppen ezért nem teszek olyan állításokat, mint te...

    "Na ne rohogtess mar. A belinkelt GT5P autovalsztas jobban nez ki mint a Ferraris demo es minimum egy szinten van a Lambo-val. Es 60FPS-el megy egy PS3-on raytracing nelkul."

    Na ja, egy autót könnyű viszonylag élethűre csinálni ilyen fake tükröződésekkel, stb. Attól még nagyon műen néznek ki a mai játékok, főleg ami a külső tereket illeti, az olyan, mint egy rajzfilm.

    "Azert mert a Larrabee nincs itt es nem is lesz meg 2 evig."

    Kit érdekel, hogy most mi van, amikor itt pont a Larrabee a lényeg? Azon kell jól futnia a ray-tracingnek, az Intel szerint.

    "A mostani 140 EUR vegaru grafikus kartyak meg megeszik az ilyen scene-t reggelire."

    Nagyszerű, kár, hogy teljesen mű.

    "Talan azert mert azt a chip-et hasznalod argumentumkent? Lasd: "A Larrabee-n kellene ezt megvalósítani az Intel szerint". Egy kis konzisztancia nem ertana az argumentumaidnal mert igy csak random szovegre valaszolgatok."

    Az olvasásnál sem ártana a konzisztencia, ugyanis ez a kérdés az RSX-re vonatkozott. És hiába gyorsabb az a 3850, ha az élethűségtől kb. ugyanakkora távolságra van.

    "Ha a szamolas a limitalo faktor a tobbi resz nem jaszik szerepet."

    Arról van szó, hogy ha bejön egy ilyen számolnivaló a képernyőre, nem lesz előnyben a raszterezés. Ha közben nagy komplexitású a scene, akkor sem lesz, ha ez kimegy a képernyőről...

    (#136): "Komolyan...ahelyett hogy ileyn hulyesegeket irkalnal inkabb vagy alugy ilyenkor, vagy eloszor nezd meg es olvass utana mirol szolt az a demo aztan meg annak minek kene a fust es a tuz renderelesehez raytracing."

    Ha valamit nem értesz meg, az nem biztos, hogy hülyeség. Arról van szó, hogy az élethű füstnek nem csak a gomolygása számításigényes, hanem a megjelenítése is. Mivel hogy nem néhány poligon egy füst textúrával, undorító és illúzióromboló (még azt a kicsit is, ami volt) éles élekkel a metszéseknél, stb.

    "Javaslom a par evvel ezelotti offline rendererek megoldasait nez eloszor. A regebbi Lightwave es Maya verziokat - az elsot a fist miatt a masikat a tuz miatt."

    Nem láttam még ilyenekben élethű füstöt - nem a gomolygást illetően, bár az is megér egy misét: ha egyszer textúráról van szó, az nem térbeli, így élethű térbeli gomolygást sem igazán lehet vele összehozni.

    "G80? A 7800GT OC-n teszteltek. A masodik linkedben van benne. Azt kerdezted hogy menne ez most egy GPU-t rasztarizalassal. Arra irtam hogy meg a raytrace verzio is menne ugyanugy mint a CELL-en. Egy shader-es megoldas pedgi sokkal gyorsabb lenne."

    Azt nem tesztelték semmi máson, mert az eredeti 7800-as változat továbbfejlesztése/módosítása, csak Cellre. A nyuszisnál viszont G80-nal hasonlítanak, és továbbra is 4-es a szorzó...

    (#137): "A Pixar oldalarol a Cars-os dolgot direkt nem raktam be neked tegnap mert sokkolo hatasu lenne de egye fene, itt van: [link]"

    Ha esetleg jobban megnézted volna, itt interactive preview-ről van szó. Biztos bolondgombát ettek, hogy a végső rendereléskor mégis a sokkal lassabb ray-tracinget használják.

    "Egyebkent azt tudod hogy a Cars votl az elso filmjuk amiben raytracing-et hasznaltak? Addig elvoltak nelkule es par filmjuk megjelent"

    Naná, hogy észrevettem, a Pixar filmek mindig is totálisan "plasztikusak" voltak a számomra.

    "A Pohl fele munkarol mar volt szo sokszor es mondtuk hogy hanyat. Mert az is. Istenem hogy nez mar ki. Nezz meg egy DX10 alatt futo Bioshock-ot mondjuk (ha mar a sotet environment-nel tartunk..."

    Bizonyos szempontból kezdetlegesebb, más szempontból meg életszerűbb. A Bioshock és társai 2mp-nél tovább nem tudnak lekötni.

    "Egy 5900Ultra-n alapulo grafikon? Really? 2008-ban a G92 es az R670 idejeben? Ezt nem gondolod komolyan. Raadasul az Intel-tol?"

    Nézd már meg, mennyit számít a két kártya közötti kb. 2x-es különbség egy idő után! Semmit, együtt konvergálnak a nullához. Egy 5x gyorsabb kártyának is ez a sorsa.

    "Most komolyan, mi nez ki jol azokon a screenshotokon? Barmi ami ma vagy tavaly a piacon volt jobban nez ki."

    Melyikeken? A cikkben? Ha már screenshotok, inkább ezeket. De inkább ne csak screenshotokat, hanem a videókat. Mozgásban kicsit más. Lehet, hogy nem szuperrealisztikus, meg nem olyan alaposan kimunkált, mint az újabb raszterezős enginek és játékok, de az életszerűbb árnyékok, vetített textúrák, nem-statikus, (ön-)tükröződések, nem metsző füst és tűz, stb. nekem bejönnek.

    "Olyan egy hetig amikor elkezdesz egy 3D modellezo programot hasznalni. Aztan attersz normalis dolgokra."

    Jaj, hagyjuk már szegény golyókat, nem csak azokról van szó.

    "Vagy peldaul ez a kep: [link] Ehez abszolute felesleges a raytracing. Cube es Env mapping-al megcsinalod ugyanilyenre."

    Kár, hogy ez csak egy csalás, ami csak így első ránézésre életszerű (vagy még így sem).

    "Nem tudnad megmondani hogy raytrace-e vagy nem."

    Legfeljebb amíg meg nem mozdul... Statikus fake az egész, öntükröződés sincs. Az árnyék meg már most sem stimmel, vagy talán lebeg az út felett?

    "A regi sok eves 3D Studio (meg a max elotti) kepek jutnak rola az eszembe."

    Én inkább az Amigás ray-tracerekre emlékszem szívesen.

    "Ennyire azert nem kene. A csillogo gombokbol regen kinottek az emberek. Legalabbis remeltem."

    Én meg azt remélem, hogy az életszerűség igényéből nem nőttek még ki.

  • dezz

    nagyúr

    válasz Raymond #155 üzenetére

    No jó, az első mondatod után nem olvasom tovább.

    ps. én máshogy csináltam. gyorsabban. na bumm.

  • dezz

    nagyúr

    válasz Raymond #155 üzenetére

    A ray-tracelt Quake-ekben sem mozog ugye semmi, azért nem több mp egy frame, hanem csak 1/90... De ugye én beszélek össze-vissza... Te eszelős.

  • Ati_X_321

    aktív tag

    válasz Raymond #155 üzenetére

    Mert amint valtozik a scene ujra kell generalnod a KDtree-t es ez masodpercekig tart egy scenen.
    ugyanez meg van raszteresnél is, mindkettő háromszögekkel dolgozik, szóval nem értem, hogy jön ez ide

    a mostani játékok is kd fát használnak a pálya statikus részének leírásához (source engine, quake4), a dinamikushoz meg nem, ez eddig is így volt, továbbra is így lesz

    raytracingnél is lehet ugyanez

    mostani játékoknál kezd bejönni a full rombolható környezet, asszem láttam valami UE3-as videot ezzel kapcsolatban

    BSP fát nem implementáltam még, kifejthetnéd, hogy miért kell újra felépíteni az egészet, ha módosítás történik, olyan megoldás nem jöhet szóba, hogy kiegyensúlyozatlan lesz a fa a módosítás után? erősen véges számú módosítás esetében talán nem olyan nagy probléma, mostani játékokba se rajzolhatod újra a pályát rakétavetővel.

    vagy másik ötletem a módosuló partícióban lévő adatokat érvényteleníteni, és onnan egy pointerrel kimutatni egy dinamikusan jól karbantartható adatszerkezetre, persze ekkor is "kiegyensúlyozatlanná" válik

    Most mar vili hogy miert nem mozog semmi azokon a CELL relatime RT demokon?
    pedig simán mozoghatna, csak nem az objektumot kell eltranszformálni (nem háromszög esetén amúgy is bajos), hanem a sugarat kell inverz transzformálni

    [ Szerkesztve ]

  • Ati_X_321

    aktív tag

    válasz Raymond #168 üzenetére

    ok, hogy nem holnap lesz, de én már nagyon várom

    textúrázást, szűrést nem vágom, hogy kell raytracerben, csak raszteresnél

    de tényleg összejön a sok sugár, én így számolom, hogy miből:
    az első metszett objektumtól az összes fényforrás irányába + visszaverődés irányába + törésirányba = ez legalább 3 sugár, amiből az utsó kettő rekurzívan továbbhalad

    játékban bőven elég lenne kezdetben 3-as mélységkorlát, ez esetben a sugarak száma
    3+3*2+4*3 = 21 ha nem rontottam el

  • Ati_X_321

    aktív tag

    válasz Raymond #175 üzenetére

    A szures azert kell mert ha csak egy sugar van keppontonkent akkor gyakrolatilag point sampling "minoseget" kapnal. Ami nem kivanatos. Legalabb egy bilinearnak megfelelo kene ha mar tenyleg igenytelenek vagyunk.
    ezt vágom, csak én a korábbi hsz-edben úgy értettem, hogy emiatt akarsz még sugarakat lődözni, valószínű megoldható a bilineáris hatás elérése enélkül is

  • dezz

    nagyúr

    válasz Raymond #158 üzenetére

    A nénikéd futamodott meg - hogy szépen fejezzem ki magam. Csak (újfent) rá kellett jönnöm, hogy nem vagy vitaképes (csevegni lehet veled, de vitatkozni nem), mert nálad vagy fullra az egyik, vagy fullra a másiknak lehet csak igaza, és természetesen csakis neked. Annyira eszelősen ragaszkodsz az utóbbihoz, hogy a cél érdekében már otromba csúsztatásoktól sem riadsz vissza (lásd #155-ös eleje, amit a #165-ösben Ati_X_321 le is reagált, persze te véletlenül elkerülted a válaszadást). Amivel mellesleg ótvar személyeskedést próbáltál alátámasztani. Szívesen válaszoltam volna pár dologra, de elvetted a kedvem a beszélgetéstől. Ez nagyon megy neked. Hát gratulálok. Csak így tovább!

    Kopi31415: "mert dezz nagyon egysíkúan csak a RT-t tarotta valósághűnek, miközben az általa linkelt dolgok, amiket meg tudtam eddig nézni nem igazán voltak azok."

    Kissé kevered a dolgokat. Alapvetően arra válaszul linkeltem ezeket, hogy egyesek szerint ma még lehetetlen a real-time ray-tracing pl. egy asztalon elférő géppel. Ha az RT felsőbbrendűségét akartam volna demonstrálni, akkor ezeknél sokkalta jobb animokat is be tudtam volna linkelni, nem gondolod? Kapís végre!?

    kisfurko: Bump-mapping állítólag nem is kellett, mert poligonokból volt kirakva, ami korábban bump-mapping volt, azon az alapon, hogy az RT több poligonnal boldogul. Egyébként amit a #177-ben írtál, arról már volt szó.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #158 üzenetére

    "Nem mondja senki hogy a raytracing felesleges vagy nem lesz belole semmi"

    Érdekes, hányszor is írtad le, hogy mindenre van az RT-t megközelítő kinézetű, de 1000x gyorsabb raszteres megoldás...? Meg hogy hiába gyorsul az RT, a másik is ezt teszi, tehát...

    Meg az a belinkelt kép... Ügyi vagy, sikerült kiválasztanod azt, amihez tényleg elég egy egyszerű environment map (mert hogy semmi más nem mozog a képen, a vékony lábakon úgysem kivehetőek a dolgok, stb.). Csak éppen értelme nem volt.

    [ Szerkesztve ]

  • ddekany

    veterán

    válasz Raymond #187 üzenetére

    "Csakhogy azok a Q4 kepeken semmi nincs. Se tobb poligon, se bumpmapping, se normal mapping."

    Mivel a scene túlnyomó többsége statikus, nem hiszem hogy a poligon szám növekedés jobban földhözvágáná mint a raszterest, max. nem akartak még lassabb megjelenítést. A bump ill. normálmapping esetén meg vajon több a büntetés mint raszter esetén phong (vagy afféle normál interpolálós) shadingnál? Elvileg tök ugyan az az eset... aztán nem tudom van-e valami csel raszernál ami itt nem működik.

  • fLeSs

    nagyúr

    válasz Raymond #226 üzenetére

    Ez igaz.
    Egyébként mot hogy nézem, nem jelölték külön az RS/ROB-ot (meg L1 cache-t sem), mert a Powerben nincs is. A proci a dekódolás után utasítás-csoportokat hoz létre, itt történik némi OoO végrehajtás, de ez annyira primkó (és sztem ezért is szedték ki belőle, mert több hátránya volt, mint előnye), hogy nagyságrendilag valszeg kevés tranzisztorba kerül.

    "I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

  • fLeSs

    nagyúr

    válasz Raymond #228 üzenetére

    Úgy emléxem, hogy a Silverthorne is in order.

    "I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

  • Rive

    veterán

    válasz Raymond #224 üzenetére

    #223...

    Tisztázni kellene, hogy a 'core' akkor tartalmazza-e az L1I/DCache-t, vagy sem? Ha CPU-ról van szó, akkor ált. beleértem, de ha 'core' van terítéken, akkor nem mindig.

    /// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

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