Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2128
üzenetére
Azért mert még nem ütötted be a Google-be az NVIDIA (esetleg Intel) black screen keresését. Ott is milliós nagyságrendű találatot kapsz.
Egyébként nem feltétlen más komponens okozza, hanem két komponens közötti kompatibilitási probléma. Külön-külön lehet, hogy minden jó, de együtt ...
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2133
üzenetére
Indulj ki ebből, de ettől a PC Partner adata erre vonatkozóan világos. Attól, hogy te ezt öncélúan kizárod és egy hatványozottan nagyobb statisztikai alapot nem fogadsz el nem változik meg a valóság.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2206
üzenetére
Például a geometry shader fázisig az egyik hardver dolgozik, míg onnantól a másik. Mintha egy GPU lenne a kettő. Ez akár kombinálható AFR-rel. Vagy az IGP csinálja a geometriát, és a dedikált GPU a többi számítást. Vagy akár két dedikált GPU is megteheti ezt. Sok lehetőség van.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2208
üzenetére
Nem igazán a low-level API a követelménye, hanem az érzékelt GPU-k fölötti teljes kontroll (QoS). Az API absztrakciós szintje nem sokat számít, bár a low-level valószínűleg segít nagyon egzotikus működési modellt tervezni.
A DX-ben azért nincs ilyen, mert az API egy erőforrást detektál, és a mai SLI/CF csak egy szimpla driverhack.
OpenGL-ben van erre egy specifikus megoldás: AMD_gpu_associationSenki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
daneeeeee
aktív tag
válasz
FLATRONW
#2299
üzenetére
Világos, hogy hogy működik az SSAA de ha ez tényleg "csak" ennyit tud a Ryse-ban akkor én nem vagyok biztos benne, hogy bekapcsolnám.
HSM: Ok, a TR-t vissza szívom a kinagyított képeken már látom a különbségeket mondjuk játék közben nem emlékszem ez ennyire látványos lett volna.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2514
üzenetére
Az Asura motor esetében a textúra streaming működése egy érdekes optimalizálási stratégia valóban, de teljes egészében a DX11 miatt alakították így. Azért tölt be a memóriába alacsonyabb felbontású textúrákat idővel, hogy a nem használt területet ne kelljen törölni. Viszont, ha nem törlöd, akkor egyre kevesebb használható területed van, tehát alacsonyabb felbontáshoz kell folyamodni. Egyszer persze úgyis lesz törlés DX11 alatt is, tehát ezzel csak az időt húzzák. Nyilván nem mindegy, hogy több órás játék során hányszor akad be a program a nem használt textúrák törlésétől. A Rebellion abszolút a folyamatosságot helyezi előtérbe, tehát minél kevesebb akadás lesz ebből, annál jobb lesz az élmény a fejlesztők szerint. És ezért úgy gondolják, hogy megéri beáldozni néhány textúra minőségét is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2522
üzenetére
A régi verzió negyedakkora méretű textúrákat támogatott. A Sniper Elite 3-ban a low szint az, ami a Sniper Elite v2-ben a maximum volt a textúrarészletesség szempontjából. Erre reagál az új streaming stratégia.
Igazából ezeket a streaming rendszereket nagyon nehéz PC-re kifejleszteni. Tökéleteset két év alatt sem lehet alkotni. Nagyon akadályozza a fejlesztőket az a tény, hogy a DX11 nem engedi a közvetlen memóriaelérést, tehát nem tudnak akármit megcsinálni, hanem kerülőutak tucatjait kell kidolgozni, hogy egy átlagosnál jobb streaming rendszer egyáltalán működjön a gyakorlatban.
Kevés olyan játékot láttam, ami annyira példásan lett volna DX11-re optimalizálva, mint a Sniper Elite 3.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2524
üzenetére
Ennek az a célja, hogy minél később és egyben minél ritkábban kelljen törölni a nem használt textúrákat a VRAM-ból, mert a DX11-ben bármit törölni annyira körülményes procedúra, hogy jó eséllyel be fog akadni a program. Maga a DX11 API kényszerítette a Rebelliont egy olyan döntésbe, hogy akadjon, vagy ne, és akkor egy kis minőségcsökkenés belefér. Ez egyáltalán nem a fejlesztők sara. Ők két rossz közül választották ki a nézőpontjuk szerint kevésbé rossz opciót.
És hogy mennyire nem egyedi a Rebellion gondolkodása megemlíthető, hogy a Frostbite és a CryEngine új verziói ugyanerre a streaming modellre állnak át. Sőt, a Ryse már használja is. Bár a Ryse annyiban más, hogy ott még a maximális textúrarészletességet sem állíthatod be egyénileg, hanem a program automatikusan intézi ezt.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
TTomax
félisten
-
Habugi
addikt
válasz
FLATRONW
#2861
üzenetére
Anélkül, hogy ebbe jobban belemennénk (mivel nem vagyok egy programozó zseni), nem értem mi a bánat köze van az alkalmazás indíthatóságának/indítását gátló védelemnek ahhoz, hogy később milyen effektek futnak le.
Még ha játék szinten akad is ilyen (volt már rá példa ugye.., különböző rejtett kedvességek..), a benchmarkban nem lesz benne.Meg lehet nézni hány hw-s techoldal ad hangsúlyt annak 1-1 tesztkörös cikke elején, amiben teljesítmény adatok (is) szerepelnek, hogy az éppen felhasznált 5-10 játék közül melyiknek milyen a verziószáma, Steames vagy dobozos verzió-e adott játék, milyen patchek vannak rajta.
Pedig ennek sokkal több jelentősége van/lenne a legtöbb esetben!
Példának okáért FC4.., nekem itt csak azzal van "problémám", hogy sokan akik "nem szeretik" a virágot (ez tök jó csak nekem ehhez semmi közöm nincsen.., és vica-versa
) emiatt nyígnek hangosan, ugyanakkor pedig, amikor ihletet kapnak szemrebbenés nélkül linkelgetnek a 7ből 6patchel ezelőtti FC4 eredményeket a "konkurencia" VGA gyártó topicjaiba.. 
Szerintem vagy-vagy, de simán előfordulhat hogy velem van a hiba..
SE3-hoz is kijött már hány patch? Egy tucat? Adatmennyiségben ez már tetemes hányada magának a játéknak is..
Steames SE3 patcheli magát automatikusan (ha akarjuk ha nem ugye..), a többi?
Semmi problémám azzal aki kifogásolja a virágot, nekik van igazuk, egyébként is tabu téma.
Egyszer leírja valaki oké.., de esetleges bencheredmények tekintetében kár lovagolni rajta, főleg azonos verziószám mellett (mert innen indult ez az egész röhej..), közben azt vízionálni milyen effekt fut vagy nem fut le de csak a virág esetében, mert amikor arról van szó, hogy Benő NV-s 120+K-s VGA-ja gyorsabb-e mint Kálmánka hasonló értékű Radeonja, akkor szemrebbenés nélkül van linkelve, netről, korábbi mérésből, innen-onnan mindenféle eredmény, ami x patchel ezelőtti, csak most ahhoz fűzi érdeke, hogy az "ilyen effektekhez" fűződő különbségeken átlendüljön.Tehát amit leírsz azt ebben a formában nem is értem, NV-s kártyákon vannak effektek amik Radeonon nincsenek vagy vannak csak optimalizlva nincsenek.
daveoff például Mantlés eredményt kért nemrég, pedig neki az nincs NV-vel és gyökeresen más eredményt hozhat, gyökeresen más az API müködése, mégis kíváncsi egy összehasonlításra, miért ne lenne, ez teljesen rendben van!
Az egész "témát" egy teljesen fölösleges szőrszálhasogatásnak érzem, de lelketek rajta.
Többet nem nyilatkozom meg a témában, mert egy, ez itt nagyon off, kettő tabu, három, ha a fejem tetejére állok sem tudom ennél jobban elmagyarázni. Aki ezután sem érti meg, esetleges bencheredményeket szem előtt tartva, miért (nézzétek el nekem..) "piti" dolog ez, azon nem tudok segíteni!
..játékokban a Depth of Field bizonyos szempontból olyan mint a zöldborsó.., szükség idején valami állat kitalálta hogy ehető...
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#3090
üzenetére
Az teljesen világos, hogy van hova fejlődni, mert a hajszimuláció gyakorlati megvalósítása csak most indult. De a Hairworks egyrészt úgy kerül több erőforrásba, mint a TressFX, hogy nem csinálja meg az önárnyékot, nincs rajta semmilyen analitikai élsimítás, és spagettis az egész hatása sorrendtől független átlátszóság nélkül. Oké elfogadom, hogy az NVIDIA-nak ezeket nehéz beintegrálni a Hairworksbe, mert akkor nem lehetne gyorsan beépíteni a motorokba, de azt már nehéz lenyelni, hogy a minőséget eredményező tényezők nélkül is több ideig tart a feldolgozás, mint a TressFX-nél.
HBAO-nak mindig az volt a gondja, hogy rengeteg hamis árnyékot generált. Ezt sosem tudta levetkőzni, bár javult a helyzet. De nem miért nem lépünk. Ott az Obscurance Fields.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#5834
üzenetére
Én a GTX 760-en a 25-30%-os kihasználást nem mondanám magasnak. Ezt szerintem fel lehet tornázni a GCN-es hardverek 35-40%-os szintjére, vagy a közelébe. Az, hogy egy program mit ír semmit sem jelent. A belső kihasználás számít, amit mondjuk GPUView-vel tudsz ellenőrizni, vagy GPUPerfStudióval. Ettől a 99%-ot oda fogja írni rá az olyan kamuprogram, mint az afterburner és bármi hasonló.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Televan74
nagyúr
válasz
FLATRONW
#6106
üzenetére
Mint ha olyan érzésem lenne hogy az NV tulajok kicsit tartanának a DX12 -től.Nem szeretnék elveszíteni a driveres előnyt.Jó lett volna még nekik a DX11 1-2 évig.A másik oldal meg mint messiást,úgy várják DX12 -t.
Amikor nincs remény! Jusson eszedbe nincs isten, csak én!
-
-Solt-
veterán
válasz
FLATRONW
#6106
üzenetére
Vagy azt ismerte fel, hogy túl sok embert és erőforrást köt le a driverekkel való szarakodás, ráadásul sokszor a tőlük független nyűgök miatt is ők vannak felelősségre vonva...
Az AMD teljesen másképpen áll hozzá a driver kérdéshez, azt hiszem Abu ezt taglalta is itt. Erre nekem jó példa az ETS2, ahol a 290X alig hoz több FPS-t mint a GTX780, mégis előbbivel stabilabb értékeket kapok. Ha a GPU kihasználtság 50-60% fölött van, akkor forgás közben a GTX780 nem tudja tartani a fix 60 FPS-t. Nézel előre, stabil fix 60 FPS, elkezdesz forgolódni, beesik 50-55-re, majd amikor megállsz, újra visszaugrik 60-ra... ugyanez a 290X esetén csont stabil végig még akkor is, ha a GPU 100%-n teker!
Ebből nekem nem az következik, hogy az AMD nem tesz semmit szoftveresen, pedig ez egy DX9-s játék... Az, hogy az NV-nék elsődleges cél az FPS szám, még nem jelenti azt, hogy ők tesznek meg mindent a hardverek jobb kihasználásáért. Főleg amikor NV-s címekben megy a felesleges erőforrás zabálás...
[ Szerkesztve ]
www.smart-bus.hu
-
#85552128
törölt tag
válasz
FLATRONW
#6106
üzenetére
Ezt nagyon jól összefoglaltad.
Én ~10 évig AMD VGA-t használtam, de az nV-nek tavaly/most jobb ajánlata volt/van.
Ettől persze nem zárom ki, hogy akár most/jövőre ne váltsak AMD-re ha letesznek egy jó ajánlatot (akár CPU téren is...), de ahhoz az kell, hogy már most DX11-ben is jók legyenek.[ Szerkesztve ]
-
HSM
félisten
válasz
FLATRONW
#6106
üzenetére
Szerinted nem tudnak. Szerintem meg teljesen jó a driverük. Más filozófia szerint készült, mint az Nv-é, aminek megvannak a maga előnyei és hátrányai.
Jelenleg driveresen maga a DX11 a legnagyobb korlát, ez ellen nem sokat tud tenni az AMD. A DX12 előtt pedig végképp semmi értelme, hogy pár szintetikus teszt kedvéért átírják a driverük parancskezelését olyanra, mint amit az Nv is használ.
(#6112) imi123: Gondolhatod, micsoda emberfeletti kényelmetlenség volt egyszer beállítanom az MSI Afterburnerben, hogy -20mv, +50% powertune és 900Mhz GPU clock, és a végén bepipálni, hogy save profile és "Apply overclocking at startup".
És vaj simán futott azon is minden....(#6113) -Solt- : No igen. De hiába mondod, az Nv driver jobb, tudod, több az FPS. Az Nv ezt remekül felismerte, az FPS kell, és megvesznek vele mindenkit kilóra. Nem számít, ha beesik, nem számít, ha kitúrja a prociról a játékot magát, nem számít semmi, legyen FPS mindenáron. És van.
[ Szerkesztve ]
-
#85552128
törölt tag
válasz
FLATRONW
#6195
üzenetére
Azt ott rosszul írtam csak már nem tudtam szerkeszteni.
Akkoriban pont az nV hozott mindent hamarabb, ugyanúgy nem származott belőle számottevő előnyük
Na jó a 8800-ból igen, de ott sem a DX10-es újdonságok miatt, meg ugye eléggé megkésett az akkori ATi válasza és nem is volt valami siker a 2900XT...
Meg ha jól emlékszem a 6600GT/7600GT is akkor "best buy" volt.[ Szerkesztve ]
-
-Solt-
veterán
válasz
FLATRONW
#6827
üzenetére
Ahol Mantle van, ott a DX11 módra nem fordítanak akkora figyelmet ha jól tudom, tehát az összehasonlítás úgy kerek, hogy AMD-n Mantle, NV-n DX11. Így máris ott a hiányolt előny AMD-n.
Jön az átdolgozott driver, meglátjuk, hogy az mennyit ad még hozzá a DX11-s teljesítményhez. Ennek az API-nak a CPU limit a fő kerékkötője, DX12 alatt más lesz a limitáló tényező, tehát abból, hogy az NV driverek jobban szerepeltek DX11 alatt, nem következik, hogy a DX12 alatt is ez lesz a helyzet. Főleg, hogy a driverek úgy ahogy ma ismerjük őket, megszűnnek.
A DX12 egyelőre szerintem még eléggé kérdőjeles... benne van a pakliban, hogy Hawaii "életre kel".
www.smart-bus.hu
-
-Solt-
veterán
válasz
FLATRONW
#6844
üzenetére
Csak az az előny túl kevés, ahhoz közeli értékeket a DX11-es mód csiszolásával is ellehet érni.
Túl kevés az, hogy egy 290 a 980 előtt van minimum FPS-ben?
Jó hogy jön az átdolgozott driver, de már későn.
Egy olyan driver ami plusz teljesítményt hoz, bármikor jól jön szerintem.
Az a szomorú, hogy ezt a kis előnyt is csak az alacsonyabb hardverelérésnek köszönhetik.
Ez miért szomorú? No meg mi a kis előny? Mert amit a Sniper Elite 3 alatt látni, az szerintem nem kis előny.
Az is igaz, hogy elég kevés AMD-s játék készült (pedig milyen sok fejlesztő áll mögöttük)
Ez egy "friss" történet, ennek a gyümölcse mostanában mutatkozhat meg. Az egészből mi játékosok meg akkor profitálhatunk, ha elterjednek azok a játékmotorok, amelyek az alapoktól a Low-Level API-k valamelyikére épülnek. Évek óta szívunk az ArmA széria alacsony látótávjával... hol lehetnénk már, ha nem lett volna évekig behúzva a kézifék.
de amelyekbe be is építették a Mantlet ott sem minden esetben működött jól.
Ez szerintem bőven benne van a pakliban... annyira más irány az előzőekhez képest, hogy semmi meglepő nincs abban, hogy nem tökéletes az első pillanattól. Szerintem.
www.smart-bus.hu
-
keIdor
titán
válasz
FLATRONW
#7294
üzenetére
A folyamat már elkezdődött 2013 végén, csak jövő év Q1 és Q2-ben mértek és akkor már ennyire drasztikus különbségek voltak. Az nVidia már a GK100-as Keplerrel elkezdte ezt a folyamatot, a Maxwell csak azért erősített rá jobban, mert nem volt rá válasza az AMD-nek.
HSM: Az lesz, hogy ha az AMD nem szedi össze magát, akkor DX13-ban már meg sem lesznek említve. Mert a piac ilyen szigorú sajnos, nem ígérgetni kell, hanem letenni az asztalra olyan terméket, ami pénzt hoz.
[ Szerkesztve ]
¡GLORIA A LAS PLAGAS!
-
#7823
FollowTheORI
nagyúr
FLATRONW
#7822
válasz
FLATRONW
#7822
üzenetére
Az a baj hogy rengeteg keresztlicenc technológiát használnak... egyik sem tud a másik nélkül megélni (persze az intel igen, ha fel tudná vásárolni az AMD-t, de ezt meg nem engednék nekik a hatóságok).
Szóval ilyen "elválás" elképzelhetetlen úgy hogy a kompatibilitás is megmaradjon.
(SSE, AVX stb stb)Ez nagyon költői filozofálgatás ami itt most felütötte a fejét.
[ Szerkesztve ]
Steam/Origin/Uplay/PSN/Xbox: FollowTheORI / BF Discord server: https://discord.gg/9ezkK3m
-
HSM
félisten
válasz
FLATRONW
#8138
üzenetére
Az a gond, hogy ez így nem teljesen igaz, mivel az időzítések a gyári órajelhez vannak belőve, szóval ha csökkented az órajelet, akkor durván nőnek az elérési idők is, ami viszont visszaüt a sebességnek, hiába nincs kihasználva a sávszélesség.
Viszont a 290-es méri, mennyire van kihasználva a memóriája, ez pl. egy BF4 multi, FHD maxgrafikán Mantle-vel: [link]
Szépen látni, hogy a GPU 100%-on teker, a memória meg ugrál olyan 20 és 50% között, néhány rövid, de magasabb csúcs mellett.[ Szerkesztve ]
-
HSM
félisten
válasz
FLATRONW
#8142
üzenetére
Nem feltétlenül. Ha a következő generációs API-knál bejön az aszinkron számítósdi, az önmagában erősen megnövelheti a memória igénybevételét, hiszen az lehetővé teszi, hogy a GPU különböző részei egymás mellett is működhessenek. Abu írta régebben, hogy jelenleg úgy fest, a memória sávszélesség erősen meghatározó lesz az új API-k esetén a kártyák erősorrendjében.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#8750
üzenetére
Nincs HDAO benne. Csak HBAO és SSAO van. A Frostbite 2/3 zömében az NVIDIA effektjeit használja, persze helyenként módosítva, mert nem volt ideális a leképzőhöz, de pont erre való a nyílt forráskód, hogy ha nem működik, akkor átírják úgy, hogy működjön. Az új Frostbite-ban már egyetlen új, NVIDIA által fejlesztett technológia sem lesz, mert abban a formában, ahogy kínálják az EA nem tudja jól integrálni.
Az EA stúdiói mögött marha nagy tőke van, és ezzel nem tud mit kezdeni az NV. Akármennyi pénzzel mennek oda igényelve azt, hogy "használjátok a játéklassítóinkat", nemleges lesz a válasz. Az EA-nek nem éri meg, mert sokkal kedvezőbb számukra, ha optimalizálni tudják a programot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#8762
üzenetére
A régi NV-s effektek nagyon jók. A HBAO egy nagyszerű algoritmus, és azért választották, mert jobban paraméterezhető, mint a HDAO, így jobban hozzá tudják igazítani a motor igényeihez. Ez volt mindig a jó az NV régi effektjeiben, hogy széles spektrumon testre szabhatók voltak. Persze ennek van egy olyan átka, hogy tudni kell, hogy mit csinálj velük, hiszen kaptál egy olyan forráskódot, amibe nagyon bele kellett, hogy nyúlj, de hidd el egy Johan Andersson kaliberű programozónak ez inkább áldás, mint átok.
Két effektet ugyanarra a problémára nem éri meg kidolgozni. A legtöbben hülyeséget csinálnak akkor, amikor kitömik a játékot mindenféleAO-val. Sokkal többet érne, ha kiválasztanának egyet, és azt paramétereznék jóra.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#10741
üzenetére
Az a baj, hogy a konzol egy fix hardver. Tehát a programozó tökéletesen képes olyan kódot írni, amelynek minimalizálja a memóriaelérését. Kvázi a munkát a lapkán belül tartja. Egy PC-n a rakás eltérő hardver miatt ilyet nem lehet csinálni, mert nem érdemes egy hardvert kiválasztani a sok száz közül, és arra rágyúrni a programot. Fix hardvert a változó hardvert kínáló platformokkal nem szabad összehasonlítani, mert fix hardverrel olyan dolgokat tehetsz meg, amelyek drasztikusan gyorsíthatják a feldolgozást.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#11172
üzenetére
Régi API-val az, de a low-level érában már nincs kernel driver. Ott 100%-ban a programon múlik a sebesség.
(#11175) FLATRONW: Az AMD nem téma, mert visszafejtik a D3D bájtkódot és kiveszik belőle a mesterséges lassítást. Ez egy-két hónap munka biztos lesz, de megcsinálják. Ott a HairWorks példának. Egyszerűen kicserélték a shadert rá és begyorsultak. De az igaz, hogy a kezdeti 64x-es tesszelláció helyett már csak 32x-est használ valamelyik W3 patchtől kezdve, és az FC4 is már csak 16x tesszellációval fut. Egyedül a Keplert tudják így bátani, ami a nem TWIMTBP játékokban (pl.: Battlefront) mutatja, hogy még mindig elvan, ha nem szopatják szoftverből. És ez nettó bunkóság, a Keplert vásárlók is megérdemlik, hogy teljes erőből mehessen a kártya.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12016
üzenetére
A TressFX számításigénye akkor meglapozott volt. Az effekt büdzséje 4-5 ms egy erősebb GPU-n. Ebbe kell beleférni a szimulációnak, a geometria kirajzolásának, az élsimításnak, az átlátszóságnak és az önárnyéknak. Hogy érzékeld azt, hogy ez mennyire durva terhelés elárulom, hogy a konkurensnek tartott HairWorks az utóbbi két eljárást meg sem csinálja, mert már a szimuláció, a geometria kirajzolása és az élsimítás elvitte az 4-5 ms-os büdzsét. És arányaiban az átlátszóság, illetve az önárnyék problémája jelenti a legnagyobb terhelést a GPU-ra nézve és a TressFX 1.0 számításigényének a 80%-át ez vitte el. Valójában a TressFX ezek nélkül is üzemképes lenne gyakorlatilag lényegesen gyorsabban, de olyan félelmetesen ronda lenne, mint a HairWorks.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
válasz
FLATRONW
#12043
üzenetére
konzolon tressfxet használ a witcher 3 is. ha konzolon is elfut, annyira azért csak nem lehet erőforrásigényes, mármint a pchez képest.
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12043
üzenetére
Csak nézd meg a két effektet. A hajszimulálásnak a legkritikusabb pontja, hogy a haj nagyon vékony tincsekből áll. Olyan vékonyakból, amelyeket baromira nehéz sorrendben megjeleníteni, illetve nehéz meghatározni, hogy a több tucat hajszálból, ami átmegy az adott pixelen melyik is látszik dominánsan.
Ha megnézed a Witcher 3-ban Geralt haját, akkor látod, hogy a kamera forgása közben a hajtincsek pozíciója folyamatosan változik. Mindig más tincs lesz a domináns és ettől olyannak tűnik az egész, mintha a haj élne és mozogna. Másrészt gondot jelent az is, hogy nincs egyértelmű sorrend a hajszálak között, így az egész spagettiszerű lesz. [link] - ezt némileg a képek is visszaadják, de mozgásban sokkal rosszabb a HairWorks.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12043
üzenetére
Annyit hozzátennék, hogy a TressFX memóriaigénye amiatt, hogy belevitték a minőséget jóval több, mint a HairWorks-é. A PPLL gyorsítóstruktúra egy karakterre 170 MB körüli, és ez szükséges ahhoz, hogy sorrendtől független átlátszóságot kapj. Az AMD másik megoldása erre a gondra a mutex zárolás, ami kevesebb memóriát használ, mint a PPLL, de a hibátlan futtatása csak olyan architektúrán garantálható, amely virtualizálja az LDS-t. Erre pedig az aktuális hardverek közül csak a GCN képes. Viszont ilyen formában a TressFX 3.0 például mutex zárolással több karakterre is használható lenne. De a többi architektúrára szükséges egy PPLL path, illetve a legtöbb hardveren így is csak két karakteren lenne aktív, mert az műr hat UAV, és rengeteg GeForce például nem támogat 8 UAV-nél a futószalagon.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
válasz
FLATRONW
#12047
üzenetére
a tomb raider 2013 ps4en tressfx 1.0át használ, a felújított változata pedig 2.0át.
franc tudja már hol olvastam. azt hiszem, annak kapcsán, hogy volt az a petíció a CDPRhez, hogy adjanak ki tressfx patchet a játékhoz.Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
valójában is, ha látom az árnyékot nem ilyen szétkenődött valami, hanem tényleg mint az általad linkelt képen a normál.
) emiatt nyígnek hangosan, ugyanakkor pedig, amikor ihletet kapnak szemrebbenés nélkül linkelgetnek a 7ből 6patchel ezelőtti FC4 eredményeket a "konkurencia" VGA gyártó topicjaiba.. 
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Letiltás - hogy is van ez?
- Interactive Brokers társalgó
- Autós topik látogatók beszélgetős, offolós topikja
- Halo sorozat
- PlayStation 5
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Rezsicsökkentés, spórolás (fűtés, szigetelés, stb.)
- LEGO klub
- Crypto Trade
- Mibe tegyem a megtakarításaimat?
- További aktív témák...
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest