- Ideiglenesen leállította az Xperia 1 VII értékesítését Japánban a Sony
- Kisebb méretben is elérhető a OnePlus Watch 3
- Belépő táblagépet is villantott a OnePlus
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- Teljes külső kijelzővel hódítana a Flip7, ami kapott egy kistestvért is
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- iPhone topik
- Igazi csúcskészülék lett a Poco F7 Ultra
- Teljes külső kijelzővel hódítana a Flip7, ami kapott egy kistestvért is
- Azonnali mobilos kérdések órája
- Apple Watch Sport - ez is csak egy okosóra
- Samsung Galaxy Watch7 - kötelező kör
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Feljutott a G96 a Moto széria csúcsára
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A Vulkan API-val eleve nem volt annyi gondjuk, mint a DX12-vel. A Vulkan nem bindless API. De itt nem egy API egy architektúrára írt specifikus implementációjáról van szó, hanem arról, hogy mennyire sok befektetés a teljes termékskálára optimális támogatást adni több explicit API-hoz. És ez itt anyagi szintű, illetve erőforrás-menedzsmentre (humán szempontból) vonatkozó probléma. Az már önmagában egy gond, hogy az API-k teljes termékskálán keresztüli támogatását többször annyi erőforrás befektetésével tudod biztosítani. Egy programozót és pénzt csak azért égetsz, mert a múltban hozni kellett egy döntést, és az nem sült el jól. Nyilván itt megjegyzendő, hogy az AMD pattoghat azzal, hogy ők jól döntöttek, mert a pénzüket és az embereiket most ráállíthatják mindenféle olyan fícsőrre, mint a Chill, az Overlay, a Link, az új vezérlőpult, meg a következő aktuális lófaszjancsiság, amit kitalálnak, amikor nem tudnak mit kezdeni a szabad kapacitásukkal, de azért úgy marha könnyű ám jól dönteni, hogy az éles bevetés előtt két évig egy saját API-n teszteled, hogy mi a jó.
Nem függ a host CPU-tól ez. Itt az volt a gond, hogy az NV-nek hiányzott a tapasztalat egy saját explicit API-n. Ez nem az ő hibájuk, nyilván átgondolták, hogy mit csinálnak, de nem ugyanaz fejben lejátszani, vagy konkrétan lemérni a gyakorlatban. Az AMD ezt meg tudta tenni, ők nem. Mivel az Intel is ugyanarra indult, így nyilván ez tűnt papíron logikusnak. Na most ha beleöltél egy implementációba több évet, sokszázezer dollárt, és az az implementáció alapvetően működik, akkor van egy olyan íratlan szabály, hogy ne írd újra. Erre jó példák vannak az iparágon belül is, amikor az ATI még 2005 körül úgy döntött, hogy a nulláról újraírják az OpenGL meghajtót. Megtették, 2006-ra be is vetették, és javult-javult, csak hát elvertek egy rakás pénzt és erőforrást igen kevés extráért, eközben az újraírás időszakában még a régi meghajtót sem fejlesztették, mert ugye minek, az úgyis kuka lesz. Szóval alapvetően ha önteni is kell bele a pénzt, vagy akár fel is kell azt gyújtani, akkor is nagyon megfontolandó nulláról újrakezdeni. Főleg úgy, hogy igazából nem látni félelmetesen nagy problémákat a GeForce Vulkan és DX12 implementációin. Aztán persze lehet, hogy a háttérben már megkezdték a váltást, ahogy az Intel, csak nem verik nagy dobra.
-
Abu85
HÁZIGAZDA
Sajnos nem nagyon tesztelnek Threadripperekkel. Még az van belevésődve az agyba, hogy a kevesebb, de nagyobb órajelű mag a nyerő, de ez már nem univerzális igazság. Esetenként pont a több mag a jobb.
Alapvetően DX12/Vulkan API mellett jót tesz mindennek a több mag, csak abban a környezetben, amit a Forza Horizon 4 használ fontosabb az NV-nek a több mag, mert nagyon más a terhelés a többi explicit API-t használó játékhoz képest. De ez nagyrészt az implementációjukból adódik. Azért mégis kb. három év különbség van az AMD és az NV implementációja között, és az a három év sokat ér ám, hiszen amíg az NV még csak tervezte a meghajtóját, addig az AMD már javában tesztelt. Nyilván az AMD meghajtója sem volt jobb három évvel korábban.
Az a fő különbség egyébként, hogy nem túl jó irányt választott az Intel és az NV. Józan paraszti ésszel elvileg az a jó, ha minél kevesebb rétegből áll a meghajtó, így gyakorlatilag az API-hoz natív támogatást írsz. Az AMD ezzel szemben furcsa dolgot csinált még 2014-ben. Már akkor úgy épült fel a Mantle implementációjuk, hogy volt egy PAL, illetve ezen egy Mantle ICD, tehát a meghajtón belül rétegezett volt az implementáció. Józan paraszti ésszel ez hülyeség, mert teljesítményt vesztesz vele, viszont az AMD úgy tapasztalta a Mantle tervezése során, hogy ez a teljesítményveszteség elhanyagolható amellett, amennyi tempót lehet nyerni a PAL folyamatos optimalizálásán. Emiatt a DX12-t és a Vulkan API-t úgy támogatják, hogy raktak a PAL fölé még egy-egy ICD-t. Tehát minden erőforrást beleölnek a PAL optimalizálásába, és abból nyer a Vulkan, a Mantle és a DX12 meghajtó is. Az Intel és az NV natív támogatást írt eredetileg ezekre az API-kra, vagyis nekik egy optimalizálási munka dupla erőforrás és pénz, mert nincs rétegezve az explicit API-k támogatása. Azóta az Intel már megindult a rétegezés felé, így később olyan meghajtójuk lesz, mint az AMD-nek. Az NV-nek az a gondja, hogy nekik azért a DX12 meghajtójuk extrém bonyolult a binding emuláció miatt, tehát most azt újrakezdeni nem valami költségkímélő megoldás, így valószínűleg maradnak egy darabig a natív implementációnál, még akkor is, ha ma már úgy gondolják, hogy jobb a rétegezett. Innen már nehéz visszafordulni, így is változtattak az implementáción nemrég, és eléggé logikátlan lenne megint belenyúlni, mert lassan az Intel is izomból fog optimalizálni, az AMD pedig régóta ezt csinálja, szóval le kell nyelni, hogy nekik ez drágább lesz, és csinálni a meghajtó kigyúrását.
Egyébként valószínűleg az NV és az Intel nem hibázott, amikor erre mentek. Azért az AMD-nek ott volt a Mantle, amin élesben tesztelni tudták még a legextrémebb meglátásaikat is. Akkor nem vállaltak nagy kockázatot, hiszen hasonló API még a kanyarban sem volt. Az Intel és az NV jóval később kezdte meg ezt a munkát, és ott már valószínűleg nem volt idő minden eshetőséget aprólékosan letesztelni. Na most ilyenkor azért jóval nehezebb jól dönteni. Nagy hátrány egyébként nem éri így az Intelt és az NV-t. Alapvetően több pénzt égetnek el, és lassabban tudnak dolgozni, de működni működik így is a meghajtó.
-
Hajdi
senior tag
Ne húzd fel magad, nem a tiéd a cég, tudtommal!
Mellesleg neked teljesen mindegy, legutóbb is félre kommentáltál Pepe hozzászólása alapján. Csak azt láttad, hogy NV és máris RAGE! Én nem írok minden cikk alá AMD fun szöveget, hiába szeretem a termékeiket, szóval nem a flame keltés volt a célom, csak megjegyeztem, hogy túl sok a felesleges védelem egy az országunkat is megevő cég iránt!Jó éjt!
-
Abu85
HÁZIGAZDA
Tudtommal az opciók azt határozzák meg, hogy milyen távolra lövi ki a sugarat a rendszer. Valószínűleg low-on nem annyira távolra, így kevesebb ütközés lesz. Mediumon pedig már elég távolra, így több ütközés lesz, aminél mondjuk a legtöbb jelenetben nem jelent sokkal több ütközést a high és az ultra távolsága. Emellett a low beállításnál az árnyalás kevésbé terhelő, míg medium-high-ultra szinten ez ugyanaz. Valószínű, hogy az árnyalás annyira drága művelet az utóbbi három opcióban, hogy mindegy mennyire távolra megy a sugár, az nem okoz nagyságrendi változást.
Van már. Egy rakás új hardverünk (CPU-k, VGA-k) van, mennek a tesztek párhuzamosan. Csak nincs elég rendszermemóriánk, hogy annyira sok gép működjön egyszerre.
-
kikikirly
senior tag
Grafika fejlődéséhez annyit hozzátennék, ha már végképp nincs mire elkölteni a számitási kapacitást, hát növeljük a felbontást.Miért ne játszuk középkategóriás kártyákon is 4K 60fps-el?Flagship tulajoknak meg ott a 4K144hz/8K60hz.Ezerszer szivesebben választanám a 4K60hz-et mint RTX 1080p60hz-et.
-
Nartaas
tag
Biztos jó ez a technológia meg minden de nekem mint egyszerű usernek semmi nem jön át belőle, hogy jobb lenne. Ez pedig gond mert nekem kéne eladniuk
Eddig is dinamikusak voltak a tükröződések és árnyékok. Akkor és úgy tükröződik minden ahogy annak kell, az árnyékok detto. Az hogy ezt milyen alternatív megoldásokkal érték el nem igazán érdekel. Ezzel a csudajó RTX-el meg most az van, hogy egyelőre csak részlegesen alkalmazható, nagyítóval kell kereseni a különbségeket a végeredményben és brutálisan erőforrás igényes. Szóval ez így ilyen formában kinek jó?:S Ha az lenne, hogy bekapcsolom és hirtelen Hollywood-i CGI minőséget kapok látványban akkor még a 30fpst is elfogadnám de ez így nudli. -
kikikirly
senior tag
Fejlesztők panaszkodnak a növekvő jejlesztési költségek miatt.Ezek szerint nem a Ray Tracing fogja ezt megoldani. Költséghatékonyság se szól mellette.
Megnéztem újra a BF5 Ray Tracing videót, nem látok semmi különbséget a füstnél.Nincs is hozzá semmi köze, nem ad fizikát a füstnek.A fény reagál a füstre de ennyi.
Mit várok grafikától?Leképzéstől semmit,baromi szépek és részletesek az objektumok/modellek.
Leirtam párszor,komplexebb fizikát,részletesebb sérülés modellezést, több animációt ezeknek örülnék.Több kivégzés,leütés animáció, el tudnám viselni ha lőfegyveres kivégzések is lennének a játékokba mint a John Wick cimű akciófilmbe.Részletesbb fizikát szerintem nem nagyon kell magyarázni(sima particle törmelék rendszerért már kezet csókolnék,rombolható környezetet ez is elég jól imitálja,nekem elég lenne).Sérülés modellezésből is jó lenne valami dinamikusan számolt, részletesen lemodellezett testfelépités, csontok izmok szilárdságának számolása lövedék becsapódásnál stb. Jelenleg le van néhány scriptelve azt viszlát.Csávó arca fejlesztők igényességétől függöen 2-3 féleképp esik szét, ugyanez a helyzet a többi test résszel.És az már nagy szó ha egyáltalán van végtag leszakadás.Basszus még a lövedéknyom sincs minden játékba(Shadow Of The Tomb Raider se sikerült megcsinálni,imádom az új Tomb Raidert is ne értsetek félre,de új pályákat leszámítva ez a játék is alig fejlődik valamit egyik részről a másikra) pedig 2004-es Far Cry-ba tökéletesen működött.Far Cry 3-4-be szintén van,de sokszor baszik működni,fejbe lövöm a palit közvetlen közelről és nincs ott a lövedéknyom.Belelövök még egyet már ott van.És sajnos ez nagyon gyakori,többször van mint ahányszor rendesen működik.Far Cry 5-el nem játszottam ha 3 játékra végre sikerült kijavítani nem szóltam.Ghost Recon Wildlandsnél se működik sokszor úgy ahogy kellene.
A 20secen belül eltűnü lövésnyomok,Bloodsplattering,töltényhüvelyeket már emlitettem.Pedig ezek is elég jól növelnék a részletességet.Tűzharc közbe és után is elég pazar látvány lenne ha teszem azt csak 10 perc után tünnének.Jelenleg annyira rövid ideig maradnak meg hogy szó szerint még jóval a tűzharc vége előtt eltűnnek.
Ezekhez nem kell komplexebb fizika,már most is meg van hozzá ami kell, feltételezem a rajzolási parancsokkal spórolnak a fejlesztők. -
ribizly
veterán
A "baromi egyszerű használni" valóban nem helyénvaló, de elvileg elegendő volna berendezni a megfelelő helyszíneket, amelyekhez utána "csak" be kellene állítani a megfelelő napállást, meg belső fényforrásokat. Done. Amit persze megelőz egy erre felkészített engine és egy 10^99999-en model minden paraméterével.
Nekem inkább az a fura, hogy amikor már minden működik frankón a közelítő megoldásokon (nézz csak meg egy Ubisoft game-t (új AC, FC) vagy egy Witcher 3-at), akkor kezdenek el erre rámenni. Ami egy grafikusnak, engine fejlesztőnek, 3D modellezőnek, informatikusnak, VGA fejlesztőnek új és jó dolog az a gaming és gamer oldalán ez kb. egy nagy 0. -
kikikirly
senior tag
Ha rendbe teszik a DX12 mi lesz?Ugyanúgy közel harmadolni fogja a teljesitményt és ugyanúgy alig lesz futtatni képes hardver a játékosoknál.Ray Tracing egy lényege hogy baromi egyszerű használni,hatalmas számitási igényért cserébe.Biztos lesznek még optimalizásálások amikkel nyernek pár százalékot,kétlem hogy nagyságrendileg csökkenni fog a teljesítmény igénye.Ott kezdődik a probléma hogy dedikált magokat kell tenni a kártyára hogy valaha egyáltalán használni lehessen.Ennyit nem ér ez az egész bohózat,inkább tennének általános számláló egységekből többet a kártyákra.
"Egy lépés a valósághűbb fizika felé.,,
Közben a füst tojik az utjába kerülő objektumokra,vagy ha valaki belemegy nem örvénylik,eltűnő törmelék darabokról,töltényhüvelyekről már beszéltünk.Harctérről csak a tükröződés hiányzik,az előbb felsoroltak teljesen másodlagos tényezők.
-
kikikirly
senior tag
Persze és a nagy kapkodásba véletlenül kikapcsolva felejtették kisfiú árnyéka.
Jó hogy mondod BF5 160FPS-el fut 2080Ti-on,Én kérek elnézést.
Ezek után el se merem képzelni mi lett volna ha Nvidia eljárását használják.''vagy éppen erről szólt a cikizés itt is a PH-n hogy 30 FPS lesz a Tomb Rader RTX támogatással. Hát nem annyi lett a végére mert tudták optimalizálni, de ezt nyilatkozták is a fejlesztők,hogy FHD @60 FPS a cél, csak az már nem jutott el a mi kis közösségünkbe, hogy nem volt idejük a bemutatóig.,,
Az élet szép csak te világ vagy beteg.
Új hozzászólás Aktív témák
Hirdetés
- Számtech boltosok memoárjai, azaz amikor kiborulunk...
- Milyen billentyűzetet vegyek?
- Azonnali informatikai kérdések órája
- Budapest és környéke adok-veszek-beszélgetek
- EAFC 25
- Villanyszerelés
- Kerékpárosok, bringások ide!
- Luck Dragon: Asszociációs játék. :)
- Külföldi rendelések: boltok, fizetés, postázás
- Kínai és egyéb olcsó órák topikja
- További aktív témák...
- ASUS TUF Gaming GeForce RTX 3090 24GB GDDR6X
- ROG Astral GeForce RTX 5080 16GB GDDR7 OC Edition - 32 HÓNAP IPON GARANCIA
- GIGABYTE AORUS RTX 4070 Ti ELITE 12GB - 20 hónap garancia
- BESZÁMÍTÁS! Gigabyte AORUS MASTER RX 6800 XT 16GB GDDR6 videokártya garanciával hibátlan működéssel
- Eladó PNY GeForce RTX 4070 Ti SUPER 16GB OC XLR8
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060Ti 8GB GAMER PC termékbeszámítással
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
- AKCIÓ! MSI B365M i5 8600 16GB DDR4 512GB SSD RX 5700XT 8GB CM MASTERBOX Q300L Zalman 600W
- AKCIÓ! 16GB (2x8) G.Skill Trident Z RGB 4266MHz DDR4 memória garanciával hibátlan működéssel
- BESZÁMÍTÁS! 2TB Kingston KC3000 NVMe SSD meghajtó garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest