Új hozzászólás Aktív témák
-
TTomax
félisten
Mindig is volt olyan játékok ahol ilyen-olyan okok miatt nem ment az AFR,legutóbb pl a RAGE,régebben pedig egyáltalán nem volt általános a 90%+ skálázódás... jó volt az 60-70%-nak is,mégsem temettuk az AFR-t...ameddig nincs jobb addig ez bizony maradni fog,korai még temetni.
-
#06658560
törölt tag
Ha úgy csinálod, akkor a cikkel mi a helyzet? Pont az van leírva, amikor egyik farmeböl kell adat a másikhoz-pl. hóesés- akkor áll meg a multi gpu tudomány AFR-rel. Ha Random hatás keletkezik-egy rendes modellben pl. random hatás szerű a helikopter légörvényébe keveredő hópehely, por-akkor ott kell tudni mi merre mozdul. Ha megmozdulsz két képkocka között, akkor az random, hogy merre mozdulsz- így a képi adatot nem tudod előre determinálni, merre változik, mi legyen megjelenítve. Az elképzelt kódod ezért nem működik.
-
lenox
veterán
válasz
#06658560
#62
üzenetére
Nem tudom, te hogy szoktal esemenykezelot irni, en az eger, billentyu esemenykezeleset a cpu-n futo koddal oldom meg. A cpu kod szepen eldonti, hogy melyik frametol kezdve akarja figyelembe venni, es ennek megfeleloen parameterezi fel a gput. A user poziciojat, iranyat en tuti nem szamolnam gpu-val, nem nagyon latom ertelmet. Szoval nem tudom, milyen random hatasra gondolsz, amit gpu-val kellene feldolgozni, nem cpu-val. En biztos ugy csinalnam, hogy ne kelljen egyik gpu-rol adatot a masikra tolteni, ketto kozott hasonlitani.
-
#06658560
törölt tag
és Mivel nézed meg, hogy mikortól kell váltanod, s mire, mennyit? Amikor a júzer befolyással van a képre- mert el tud fordulni, nézőpontot válthat, akkor rém egyszerű játékokon belül is nem determinisztikus helyzetet teremteni. vagy szerinted kötött, adott pozícióból merre nézhetek, merre mozdulhatok tovább? Ha pedig random hatások érik a képi infót, akkor hogy döntöd el, mikor kell módosítani az alapokat, amikből dolgozhat a GPU? mindig megnézed, van-e eltérés a két állapot között? Azt mivel oldod meg? Egy harmadik coprocesszorral? Mennyit kell ekkor várnia a GPU-nak, mire kiderül, hogy számolhat-e a régi adatokkal, vagy kell neki az új? Mennyi idő, mire megkapja az új adatokat? Mennyire esik vissza a teljesítmény így?
-
lenox
veterán
válasz
#06658560
#60
üzenetére
A gpu-ban egy jatek alatt hogy keletkezik nem determinisztikus input? Mert amugy olyat, hogy valamilyen algoritmus hasznal valami veletlenszamgeneratort, olyat szoktak csinalni, es ha egymastol fuggetlenul akarnak random szamot, ami viszont egymassal egyezik, akkor pseudorandom generatort hasznalnak.
Példádban a fél lépés nem értelmezhető, hisz egész képkockákat számolnak a kártyák, s ha nem t=10-nél lép be az új eset, hanem t=3-nál, te meg előre meghatározva csak t=10-töl kezded el változtatni a lépéseket, akkor nem lesz megfelelő az, amit számolni kell.
Termeszetesen ha t=3-nal van az input, akkor nem t=10-tol kell mast szamolni, hanem t=3-tol. A kimeneti szekvencia meg nem a kep sorszama, hanem a tartalma (pl. hol van az ojjektum, milyen szinu a kep, akarmi), az egyszeruseg kedveert eddig az 1. framenel ez 1, 2-nal 2, 3-nal 3 stb. volt, az emlitett peldaban 10-nel 10, 11-nel 11, 12-nel 12.5,13-nal 14 stb.
-
#06658560
törölt tag
A problémája a rendszerednek, hogy determinisztikus inputokat feltételezel. Nem determinisztikus hatásokat hogy kezelsz le vele? X időnként átmásolod az adatokat? Mennyi az x? Miért nem a fele? Vagy beiktatsz egy algoritmust, ami nézi volt-e érdemi változás a másik GPU-nál, s olyankor átemeli az adatokat? Olyan teljesítményvesztésed lesz, hogy ihaj. Példádban a fél lépés nem értelmezhető, hisz egész képkockákat számolnak a kártyák, s ha nem t=10-nél lép be az új eset, hanem t=3-nál, te meg előre meghatározva csak t=10-töl kezded el változtatni a lépéseket, akkor nem lesz megfelelő az, amit számolni kell.
#58 gbors: mivel le lett tiltva a multiGPU az adott game-ben ezért az ilyen kis intervallumoknál sem értelmezhető hibamentesen az elképzelés. Mert pont ezt csinálta volna. bizonyos időközönként meg kell osztani a memória tartalmát a GPU-k között, az időköz meghatározása pedig a probléma alapját nem változtatja- néha nagy adatmozgatás kell, s ennek minél sűrűbbnek kell lennie a folyamatos, zökkenőmentes számításhoz.
-
lenox
veterán
válasz
#06658560
#57
üzenetére
Egyreszt tobbfele dolgot is irtam, de megint akkor peldaval:
Mindig egyet adunk hozza a kovetkezo framenel, ket gpunal ha megvan az egyiken a 1. a masikon a 2. frame akkor ugye az mindketton 2-t adogatunk hozza, igy lesz 3,5,7 es 4,6,8 rajtuk. De tegyuk fel, hogy user input miatt 10-tol felfele mar nem 1-et kell hozzaadni, hanem 1.5-et. Ezt en ugy csinalnam, hogy mondjuk a t=10-nel ugye megvan a user input, ekkor az elso gpu eppen t=11-et szamolja t=9-bol, tehat ezt nem bantanam, a masik pedig eppen kezdene a t=10-bol a t=12-t szamolni. Itt akkor nem 2-t adnek hozza, hanem 2.5-et (1+1.5), es utana mar mindket gpu-n 3-at (1.5+1.5), tehat igy kijonne osszesegeben a 8,9,10,11,12.5,14,15.5,17 stb. sorozat. Nem kellett ugye egyik gpu-rol adatot atvinni a masikra, csak azt kellett mindkettovel kozolni, hogy melyik idopillanattol valtozott az input. Amugy csak mondanam, hogy oke, hogy probalsz ellentmondani, de amugy en evek ota multigpu-zok, aminek az eredmenyet lathatod a mozikban, es nem keverem ossze a frame-eket, nem rontom el a user inputot, szoval ilyen alap dolgokat azert a gyakorlatban is sikeresen megoldottam mar, biztos nem mindent, de azert kb. tudom mirol beszelek.
-
válasz
#06658560
#53
üzenetére
még egyszer: ilyen kis intervallumok esetén közel mindegy, hogy x+2-t x-ből vagy x+1-ből számolja a motor. többek között azért is, mert ha két frame között "félúton" van ütközés (akkor is, ha x és x+1 között), akkor azt mindenképpen figyelembe kell venni.
az egyedüli kérdés, hogy a fenti "közel" okoz-e vizuális artifaktokat, vagy nem. -
#06658560
törölt tag
"Ha te igy csinalnad meg, akkor az valoban hibas lenne. En meg ugy csinalnam meg, hogy adott idopillanat utani osszes update figyelembe vegye minden gpun, es maris adott kepkockatol kezdve mindegyiken megjelenik a hatasa. Szoval ertem, hogy tudhatsz krealni meg problemakat, csak nem ertem, hogy mi a cel vele?"
Csakhogy eddig nem ezt írtad, hanem hogy egyik GPU x-böl számolja x+1-et, másik x+2-t, s így lépkedjenek utána folytonosan. Ez pedig az x+1-ben történő változást pont nem viszi át az x+2n képekre, hacsak nem küldesz át valamikor adatot az x+2k+1 vonalról. Az meg pont az a probléma, ami most áll fenn, ergo semmivel nem jutottál előrébb. Vagy a GPU-k memóriaíban egyenként tárolt adatokat hogy fogod átvinni másik GPU-k memóriájába, hogy ne legyenek hibás megjelenítések? A képkockák fele nem vesz figyelembe A változást, másik fele B változást, stb.
-
lenox
veterán
válasz
#06658560
#55
üzenetére
A kép készítése szempontjából az nem lag, mert nem kapja meg az adott GPU adott pillanatig az adott kép elkészítéséhez szükséges infót. Hisz amíg erre lehetősége van, addig nem is jön létre az infó.
De megis igy hivjak. De tolem hivhatod masnak.
A játék pedig hogy később reagál-e? Egy négygpu-s rendszerben speciel kialakulhat az általad vágyott esetben az, amennyiben mindegyik rendszer ugyan onnan indul, vagy kettesével kapják az infókat, hogy egyik képkockában megjelenik a változás, másikban nem, akkor pedig nem tekinthetjük még véletlenül sem lagnak, latencynek, hanem csakis hibás implementációnak.
Ha te igy csinalnad meg, akkor az valoban hibas lenne. En meg ugy csinalnam meg, hogy adott idopillanat utani osszes update figyelembe vegye minden gpun, es maris adott kepkockatol kezdve mindegyiken megjelenik a hatasa. Szoval ertem, hogy tudhatsz krealni meg problemakat, csak nem ertem, hogy mi a cel vele?
-
#06658560
törölt tag
A kép készítése szempontjából az nem lag, mert nem kapja meg az adott GPU adott pillanatig az adott kép elkészítéséhez szükséges infót. Hisz amíg erre lehetősége van, addig nem is jön létre az infó.
A játék pedig hogy később reagál-e? Egy négygpu-s rendszerben speciel kialakulhat az általad vágyott esetben az, amennyiben mindegyik rendszer ugyan onnan indul, vagy kettesével kapják az infókat, hogy egyik képkockában megjelenik a változás, másikban nem, akkor pedig nem tekinthetjük még véletlenül sem lagnak, latencynek, hanem csakis hibás implementációnak. -
lenox
veterán
válasz
#06658560
#53
üzenetére
Jobb lenne szerintem, ha elobb neznel utana, es utana mondanal ellent, ha meg mindig ugy erzed. Mert itt is arrol van szo, hogy ha az input a frame processzalasanak megkezdese utan, de a kep megjelenese elott keletkezik, akkor annak altalaban nem lesz hatasa a kepre, csak majd valamelyik kovetkezore, vagyis az input hatasara a jatek kesobb reagal, ezt pedig pont ugy hivjak. De keress ra, akar wikipedian is fent van.
-
#06658560
törölt tag
A rombolhatóság az, ami két egymást követő képkockánál is komoly eltérést okozhat a megjelenésben- mert hirtelen máshova kerül egy objektum. Pl.
"én a cikkből azt vettem ki, hogy procedurálisan módosítja a motor a textúrákat, és frame-enként nem a teljes módosítást számolja, hanem csak update-eli az előző állapotot - de az update-hez használhatná valamelyik korábbi megelőző állapotot is, nem muszáj a közvetlenül megelőzőt."
Ameddig nincs változás ez jó is, csakhogy bármikor beléphet változás egyik frameről a másikra. S ha ezt nem tudja elérni, akkor gubanc van.
#48 lenox: megnéztem, rossz példát hoztam. ellenben ha akarod, akkor megérted mikor nem lehet alkalmazni amit szeretnél. Amikor egy input a kiindulási állapotod után keletkezik, az se nem lag, se nem latency, hanem a te elgondolásodban hibás eredmény.
-
Puma K
nagyúr
Minden maximumon, 2880x1660-ban sem megy 1296 MB fölé: [link]
A hírhez:
Tetszenek a több kártyás rendszerek, mert valami plusz érzetet ad, hogy több VGA kártya dolgozik az ember gépében, de a józanság talaján maradva azt mondom inkább optimalizálni kéne úgy, hogy a kártyák folyamatosan az aktuális szituációnak megfelelően a legteljesebb mértékig ki legyenek használva. Nem beszélve a játékok több kártyás gyér támogatásáról... (az nem támogatás, hogy 40-50%-on pörög a 2 VGA...)
-
válasz
#06658560
#42
üzenetére
... és @dabadab: olvassátok el a hsz 2. mondatát is. nyilván minél nagyobb a két frame közötti időintervallum, annál rosszabb eredményt kapsz, de 16ms VS 33ms esetén még nem vészes az eltérés. vonatkozik mindez az inputok kezelésére is, viszont a rombolhatóságra nem, mert itt most csak vizuális effektekről van szó.
én a cikkből azt vettem ki, hogy procedurálisan módosítja a motor a textúrákat, és frame-enként nem a teljes módosítást számolja, hanem csak update-eli az előző állapotot - de az update-hez használhatná valamelyik korábbi megelőző állapotot is, nem muszáj a közvetlenül megelőzőt.
amúgy ezt a fejlesztők vélhetően meg is próbálták, és valami problémába futottak - nekem a shimmering tűnik az első jelöltnek, de nyilván lehet más is. -
lenox
veterán
Ha x idopillanatban nyomod meg a balra gombot, akkor amikor x-bol x+2-t szamolod, akkor tudod, hogy le van nyomva, tehat jot szamolsz. Ellenben amikor x-1-bol szamolod x+1-et, legalabbis amikor elkezded, meg nem tudod, hogy majd x pillanatban le lesz nyomva. Tehat a kerdesedre valaszolva, igen. Ellenben ez inkabb alap afr latency problema.
-
#06658560
törölt tag
Nem pont erről szól a cikk, hogy a csoda új motor pont ilyen függvényt használ, ezért nem megy a jelen multi-GPU rendszereken? Egyébként ha nem használhatnánk ilyet, akkor hogy lehetne bontani falat, vagy bármi egyéb hasonlót kivitelezni? Vagy fokozatos átmenetet színeknek hóeséstől, esőtől, stb.
-
lenox
veterán
-
mzso
veterán
-
#06658560
törölt tag
Ha az adott paraméter x(i)=f(t) jellegű, akkor igen. De ha x(i)=f(t+X(i-1)) akkor már nem. kérdés az időjárás-szimuláció önmagától független, vagy sem, kell hozzá objektumok ismerete, van-e interakció, stb. normális esetben ha nem az antarktiszi hópehelyfutam tizenhárommal játszik az ember, akkor vannak objektumok, épületek, esetleg mozgó tárgyak, amik pl. a szélre hatással vannak- így pedig nem lesz független egyik kép a másiktól. Vagy egy helikopter rotorján egyenesen áteső hóvihart vizionálsz téli gyilokjátékokba?
#34 lenox: egyszerű ellenpélda: Fibonacci-sorozat.
-
Abu85
HÁZIGAZDA
Mindenképp az algoritmus az egész probléma forrása, ez nem kérdés. Csak ezen nem kevés ideig dolgoztak, így minimum felmerül az, hogy ezt megéri-e egyáltalán lecserélni csak azért, hogy a multi-GPU tulajoknak kedvezzen. A nemleges válasz igen egyszerű döntés, még ha nem is tetszik a gyártóknak.
(#35) WayneGace: Az x bites busz önmagában nem információ, mert ahhoz egy órajel is tartozik. Lehet gyorsabb egy 128 bites busz is egy 384 bitesnél, ha megvan az órajelkülönbség. Szóval nem a bit számít, hanem a GB/s.
-
lenox
veterán
válasz
#06658560
#29
üzenetére
Ket peldan keresztul hadd vilagitsam meg.
Egyik pelda, hogy az a feladat, hogy mindig szamoljuk ki az elozonel eggyel nagyobb szamot. Szoval x-bol x+1-et ugy kapod, hogy hozzaadsz 1-et. Ha szetosztod ket gpu-ra, akkor rajohetsz, hogy ha 2-t adsz hozza, akkor ugyanazt kapod, mint ha hozzaadsz eloszor 1-et, majd utana meg 1-et. Vagyis kifejleszthetsz olyan muveletet, ami ugyanazt az eredmenyt adja, mintha ketszer megcsinalnad az eredetit, de kevesebb eroforras kell hozza, mint az eredeti muveletekhez osszesen.
Masik pelda, ha a kep eloallitasaban a textura update az ido 50%-at veszi el, a tobbi 50% meg a kep kiszamolasa, akkor egy gpu-val z fps-t lehet elerni, de kettovel 1.333*z-t, mivel ugyan mindket gpu-val 2-szer csinaltatsz textura update-et, de a tobbit csak egyszer.
Persze lehet, hogy lehetetlen az osszevont muvelet is, es valojaban a textura update viszi el az ido nagy reszet, vagyis egyik megoldas sem mukodik, erre irtam, hogy akkor leginkabb az algirtmusban keresendo a hiba. -
Abu85
HÁZIGAZDA
GPU és GPU között jelenleg nem biztosított a hardveres koherencia. A mai motorok működésénél egymás munkáját akadályoznák, ha közös tárat kapnának. Kell ehhez egy speciális fejlesztés, ami biztosítja a koherenciát a megosztott memóriaterületen. Ilyenkor viszont az AFR is felesleges, ugyanis arra meg pont azért van szükség, mert két külön memóriaterület van.
-
M@trixfan
addikt
Én csak azt nem értem miért nem jobbak nagyságrendileg az egy kártyán lévő két GPU-s megoldások két külön kártyánál. Ott aztán lehetne olyan adatbusz és olyan közös memóriaterület a két chip között amilyet csak akarnak. Ehelyett semmivel sem teljesítenek jobban mint két külön kártya és ugyanazok a nyűgök érvényesek.
-
válasz
#06658560
#29
üzenetére
nem feltétlen, ez az algoritmustól függ. ha pl. az x+1 állapot kiszámolásához szükséges függvényben szerepel az idő, mint paraméter (márpedig időjárás-szimuláció esetén nyilván fog), akkor nagy vonalakban ugyanazt fogja csinálni a két GPU, csak egy frame-nyi idővel eltolva, és az egy GPU-hoz képest kétszeres intervallummal. az mondjuk valóban kérdés, hogy ez a megoldás shimmeringet fog-e okozni, és milyen mértékűt.
-
#28
lenox
veterán
KevinMulder
#27
lenox
veterán
válasz
KevinMulder
#27
üzenetére
Az x+1 is az x-bol lett kiszamolva, tehat amit ki lehet szamolni x+1-bol, azt x-bol is ki lehet.
-
lenox
veterán
válasz
#06658560
#25
üzenetére
En ugy ertelmezem, hogy nem a kepet kell kiszamolni, hanem a kephez szukseges texturakat kell update-elni. Ha x+2-t is tudsz szamolni, akkor sem x-bol szamolod az egyik gpun az x+1-et, a masikon az x+2-t, hanem kiszamolod egyiken az 1-et, masikon (akar attoltessel) a 2-t, es utana az egyiken mindig kettot lepve 3,5,7,9 stb, a masikon meg 4,6,8 stb.
-
#06658560
törölt tag
Az egykártyás fogyasztási limitek miatt nagyon mással nem tervezhetsz hosszú távon.
#24 lenox: ha az x-edik állapotból akarod kiszámoltatni egyik GPU-n az x+1-et, másikon az x+2-t, akkor annak semmi értelme, csak feleslegesen fűtesz vele. hisz akkor mindegyik GPU kiszámolja mindig a teljes képet, különben honnan tudná mi kell a következő képhez?
-
lenox
veterán
Tehát párhuzamosan számolnák ugyanazt.
Ha tul sok az adat, hogy egyik gpurol a masikra tolteni lehessen, akkor az lehetne az ertelme, hogy igy gyorsabb. Eleg fura motor az, hogy sok az adat, hogy attolthesd, de kiszamolni is ugyanannyi, es amugy a textura szamolas viszi el az ido nagy reszet. De ez Abu leirasa alapjan ilyen, szerintem eleg fura, foleg az, ha az sli/cf-ben keressuk a hibajat.
Az egyik az egyik felét, a másik a másik felét mutatná. Ennek mi a halál értelme lenne?
Ezt meg nem ertem.
-
Abu85
HÁZIGAZDA
Több hónapig dolgoztak megoldáson az NV-vel és az AMD-vel. Az utolsó pillanatban döntöttek úgy, hogy nem tudják megcsinálni, így kimarad az AFR. Az NV és az AMD ezt májusban be is építette a driverekbe.
A textúrák zizegnek, ha a számolt tartalmakat több képkockát kihagyva dolgozod fel. Ez a megoldás ezért lett elvetve.
A több számítás az opció volt, csak annyira számításigényes ez az egész, hogy az adatokat jobb lementeni, majd ahhoz hozzászámolni az új információt. Így is megeszi a rendszer az ALU kapacitást. A GeForce Titánon és a Radeon HD 7970-en 30 fps közelében vagy kimaxolva. -
#21
mzso
veterán
MCBASSTION
#9
mzso
veterán
válasz
MCBASSTION
#9
üzenetére
Szerintem, meg nem dual gpu-s embereknek kéne kedvezni. Alig van belőlük.
Valószínűleg sok fejlettebb dolgot lehet megvalósítani dinamikusan számított dolgokkal, ami amúgy csak statikus lehetne.
-
#20
lenox
veterán
KevinMulder
#19
lenox
veterán
válasz
KevinMulder
#19
üzenetére
Azt, hogy ha az x. kepkocka texturajabol szamolja valaki az x+1-dik kepkocka texturajat, akkor az x+2-ediket lehet szamolni az x+1-bol egy lepessel, vagy az x-bol ket lepessel. Utobbi esetben nem kell a gpuk kozott toltogetni.
-
#19
KevinMulder
tag
lenox
#18
KevinMulder
tag
Nem teljesen értem ezzel az x+2-vel mit akarsz mondani.
A probléma az, hogy a textúrákat szinkronban kell tartani. A másik kártya is kiszámolhatná a textúrát, de akkor voltaképpen minden textúra számolás duplázódna. Ha sok ilyen van, akkor a teljesítmény csökken. A textúra módosításnak a paramétereit pedig mindkét kártyának el kell küldeni. Ha valahol bibi van, akkor lesznek villogó textúrák (mivel ugyanazt a geometriai elemet, de más textúrával készíti el a 2 kártya).
-
lenox
veterán
Nem tudom, hogyan mukodik a motor, de amugy ha olyan sok az adat, akkor nem feltetlenul kell masolni, hanem ki is lehet szamolni a masik gpu-n is. Illetve meg azt nem ertem, hogy ha lehet az x. kepbol tovabb szamolni az x+1-ediket, akkor miert nem csinaljak meg, hogy az x+2-ediket is lehessen, es maris lehet fuggetlenul szamolni a paros es paratlan kepkockakat. Amugy legegyszerubb azt mondani, hogy jaj, keves a 2 GB ram, jaj, nem skalazodik dual gpu-ra, de leginkabb az jut rola eszembe, hogy nincs kedvuk/idejuk jol megcsinalni.
-
nbg
senior tag
Alternatív lehetőség esetleg a VRAM megosztása a GPU-k között. Ez kézenfekvőnek tűnik, és a fenti gondokat is megoldaná, de ezt a koncepciót egyszerűbb felvázolni, mint megvalósítani. Nem véletlen, hogy még nem született ilyen elven működő CrossFire-ös vagy SLI-s VGA.
A ket GPUs kartyakon megosztott a VRAM, vagy ugyanaz az elv mint sima CF/SLI mellet, es csak a NYAK kozos?
-
Milka 78
nagyúr
Remélem ez nem lesz tendencia az új játékoknál.Remélem a vga gyártók odaloccsantanak egy kis pénzt,mert nem hiszem,hogy érdekük lenne az SLI/CF rendszerek ellehetetlenítése.Nálam is a 7970 vs 7870(tahiti-le) játszott és az utóbbi nyert amivel a gyártó sem járt rosszul árban.
-
#9
MCBASSTION
aktív tag
MCBASSTION
aktív tag
hat mondjuk nem kene temporalis eljarasokat hasznalni, amugy is sztem annyira nem jok, foleg fps-eknel, mert elmosodott lesz a kep, meg ilyen essence 3.0 szerueket. Mondjuk ok, hogy tok jol kezeli az idojarast, de azert megiscsak a jelenlegi generaciora kene tervezni egy engine-t ami most kell, hogy mukodjon. Most meg meg aft van.
-
#06658560
törölt tag
Szerintem túl sok a határfelület a két kártya munkatere között, rengeteg adatot kell ide-oda mozgatni ott is, vagyis az új motor problémája jelentkezik.
Ha jól sejtem akkor erre a problémára SLI/CF viszonylatban az egy kártyára ültetett két GPU+irgalmatlanul sok VRAM a megoldás-teljesen megosztott memóriával.
-
BiP
nagyúr
Én azt nem tudom, hogy a pepita feldolgozással mi van? (supertiling) Ahol a 2 kártya ugyanazon a képkockán dolgozik, csak sakktábla felosztásban.
Azt valahogy nagyon ritkán használják (sőt, inkább nem is), nem is nagyon beszélnek róla. Pedig elvileg azzal nagyon kiegyensúlyozottan vehetnek részt a kártyák a feldolgozásban. Vagy azt nehezebb szinkronizálni? Nagyobb a késleltetés? Több ramot igényel? Mi az ok, ami miatt nem használják?(a felsoroltak közül mindet el tudom képzelni amúgy) -
#6
bitblueduck
senior tag
akkor SFR? valahogy igazan megoldhatnak ezt akar directx szinten is vagy barhogy.
-
Dany007
veterán
Spec esetekben szvsz.
Ami eddig is így volt. Legalábbis úgy tudom a GTA4 szépen felzabált 1GB + vramot is.
Legalábbis mikor én próbáltam anno a 640MB-ot úgy felzabálta, hogy a látótávolság ~ 30%-on volt... És ahogy húztam feljebb úgy fogyott a vram.
De ez is egy spec eset volt anno. Lehet ez is az marad.
egy olyan piac ahol a titan ereje a belépőszint 
Gyors ki is törlöm a listáról, ne hogy még egyszer véletlen ide írjak... 
Új hozzászólás Aktív témák
- AKCIÓ! Lenovo Legion Slim 5 Gamer notebook - R7 7435HS 16GB RAM 1TB SSD RTX 4070 8GB GDDR6 WIN11
- Új és újszerű 15"-16" Gamer, irodai, üzleti, készülékek nagyon kedvező alkalmi áron Garanciával!
- Gamer PC-Számítógép! Csere-Beszámítás! I5 12400F / RTX 3070 8GB / 32GB DDR4 / 1TB SSD
- 145 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4090
- SzinteÚJ! HP Elitebook 860 G9 i7-1255U 32GB 1000GB 16" FHD+ Gar.: 1 év
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest