Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Už pred rokom bolo neskoro.
No, dekomprimuje se. Na disku to bude komprimovane pouze jednou metodou. Tedy dekomprese v obou programech musi pouzivat stejnou metodu (podobne algoritmy) dekomprese. Jde tedy o srovnani jablek s jablky, jen u GPU muze byt pouzita masivnejsi paralelizace. Tedy pokud je metoda dekomprese paralelizovatelna...
Beru to jako následníka DMI, o tom žádná.
Ale trochu mi hlavu popletl ten kompresní algoritmus. Srovnává se Zlib na CPU s GDeflate na GPU. Hrušky a japka. Je spousta kompresních algoritmů, některé jsou rychlejší, jiné pomalejší, ale také náročnější a méně náročné, a hlavně, o co jde, jsou různé účinné. Nemám tušení, jak si v tomto vede Zlib oproti GDeflate, ale tak nějak mám tušení, že Zlib bude lepší, co se týká kompresního poměru. Ono taky ne každý kompresní algoritmus se dá paralelizovat při rozbalování, třeba je to případ právě Zlib.
Při načítání 3000 tisíc textur tě nemožnost paralelizace dekomprese trápit nebude. Prostě se pojede několik textur naráz, každá singlethread. Ale stejně jak píšeš ty. Zlib vs GDeflate ve mě značně evokuje pocit srovnání podobné LZMA2(7zip) vs Deflate(ZIP).
Každopádně o téhle pohádce jsme slyšeli při vydání PS5/XBOXsX a pokud vím, možná se DirectStorage používá v Ratchet & Clank : Rift Apart. Nikde jinde jsem o tom neslyšel.
edit: Tak ne, ani ten ne. Zatím to nejspíš nepoužívá žádná hra. Kdo ví jestli program.
Dnes možná moc ne, ale až to Epic implementuje do UE5 (což už oznámil - https://www.neowin.net/news/epic-games-confirms-microsoft-directstorage-... ), tak se s těmi hrami najednou roztrhne pytel.
Přesně tak, a mezi LZMA2 a Deflate je sakra rozdíl.
U textur bych čekal, že už komprimované budou; pokud vím, tak PNG používá právě Deflate.
Rychlým googlením jsem došel k tomu, že zlib je knihovna, ve které je implementované mimo jiné Deflate (pro CPU). Očekávám, že GDeflate bude knihovna s implementací Deflate pro GPU. Pak by se srovnávaly hrušky s hruškama, tedy stejné kompresní algoritmy, ale v článku to takhle napsáno není.
Pleteš se, srovnávaly se Avokáda :)
Je to tak. PS5 má nejhorší nahrávací časy her vs PC a vs XBox. Digital Foundry dělá testy a je to tam jasně vidět. Ratchet & Clank: Rift Apart má nahrávací obrazovky i když tvrdili, že tam žádné nejsou.
Celé to je jen marketingová blbost, prezentovaná navíc na fake UE5 demu :)
clovece nevim na jake DF se divas( ale ve vsech testech co delaji byla PS5 rychlejsi pri nacitani u native PS5 her, v compactibility modu(PS4 hry) to je trochu jina vec) , ale nenasel jsem hru ktera by se na PS5 nacitala pomaleji nez na XSX ...plus nejakou nahodou byvaji na PS5 o tretinu mensi, cim to bude ?
Mě spíš napadá jiná věc.
1. Chci načítat textury fo paměti grafické karty při rendru grafické scény. Ok tak abych jich víc protlačil skrz sběrnici mám je komprimované a hurá na to. Tohle se používá už dávno.
Ok novinkou je, že si grafická karta, čte data sama bez CPU. Ovšem nebude to zdržovat grafiku ve chvíli kdy má vykreslovat, scénu? Tzn. při jednoduché scéně je to jedno, ale při složité?
2. Opačný případ, kdy data načítám pro CPU a budu je dekomprimovat grafikou? Jakože je přes sběrnici protlačím tam a zpět? To je podle mě taky z kategorie ÚP (úplná pitomost).
Reálně podle mě narážíme na problém, že tohle lze využít jen v hodně specifických případech aby to dávalo smysl - napadá mě přehrávač videa kompletně běžící na GPU a neobtěžující CPU ;-).
Protože podle mě při komplexní úloze, je nakonec jedno, která část to udělá. Spíš jde o optimalizaci celého procesu. Tak aby se navzájem jednotlivé části nezatěžovali případně nepřetahovali o úzké hrdlo. Tím bude podle všeho DISK/Sběrnice.
Dokud ta data nejsou ve VRAM, tak grafika čeká na data a nevykresluje. Pokud se zkrátí doba, za kterou jsou data připravena ve VRAM, nastane vykreslování dříve. IMO se tohle projeví hlavně při startu hry a při změně scény. Tedy ve chvíli, kdy je třeba do VRAM naládovat velké množství nových dat, která jsou na disku.
Líbí se mi, jak se tím posouváme do nové generace úložišť.
Jakože kdysi tu byla magnetická gramofonová deska, ze které lineárně četla hlava, celé to bylo dost choulostivé, a hlavně pomalé a složité. A bylo to úplně normální, pamatujete?
Najednou jsou tu paměti, která jsou oproti tomu setsakra rychlé. Jejich přístupová doba je o tři a více řádů nižší, komunikace může probíhat po takřka neomezeně široké sběrnici. Jako první odpadla SATA, příliš složitá a tím pomalá, protože počítala s úplně jinem druhem komunikace. Odpadá SCSI (iSCSI, SAS...), ten samý důvod. Přišlo NVMe (včetně takových jako NVMe over Fiber a podobně). Využilo se PCI-e (jakožto NVMe over PCI-e vlastně), které v domácích podmínkách leželo takové trochu nevyužité.
A protože je to všechno poněkud modernější a z mého pohledu daleko přímočařejší, využila se myšlenka, kterou jsem myslel, že dnes naplňuje DMA (ne DMI, chyba), přímý přístup k paměti (tedy nemusí všechno lézt přes CPU, což mu přináší zejména přerušení, switchování kontextu a tím zpomalování). Přes to samé PCI-e, které už dávno umožňovalo komunikaci mezi device, si grafická karta sáhne takřka tak snadno, jak to jde, přímo na úložiště. A celé je to důstojně tiché a ještě k tomu designově i hezké (jak co, dle vkusu - HDD nebylo krásné nikdy, nic proti němu). Takhle vypadá nástup nové generace.
A to vše v době nové generace souborových systémů (ZFS, btrfs, ReFS), které i k organizaci dat v paměti (úložištích?) přistupují úplně jinak než dříve. Byť mi přijde, zejména u ZFS, že původní myšlenka stejně počítala s plotnami nebo podobným úložištěm.
No není to skvělá doba?
Ten popis sucasnych API je tak trocha historicky. Taketo sekvencne API sa pouzivali naposledy v MS-DOSe tam, kde clovek nemal zapnuty smartdrive. Akykolvek aspon trocha rozumny OS pouziva cache a snazi sa diskove operacie zjednocovat. Pri LBA (polovica 90. rokov) uz ani nie je treba riesit fyzicku geometriu disku.
A komu sa nepaci, ze si kazdy blok dat musi nacitavat cez read(2) existuje memory-mapped IO. Tam si proste poviem, ze subor XY z disku mam v pamati odtial-potial a k datam v subore pristupujem, ako k akymkolvek inym datam v RAM. Na to, ze su na disku, mozem kludne zabudnut.
Ci to skor nebude o tom, ze kombinacia rychlosti citania z media x rychlost dekompresie pri tom konkretnom algoritme je najvyssia. Gaming industry v zasade vobec ale ani trocha netrapi, ci ma hra 90, alebo 100GB. Ale trapi ich, ci sa hra bude nacitavat 10, alebo 15 sekund.
Podle mě ani ne těch 15 sekund. Spíš jde o to kontinuální nahrávání atd. Kdy se musí data měnit v RAM potažmo jsou tam přesuny velkých dat. Podle mě, je to všechno o nějaké úrovni optimalizace.
I to demo co ukázal MS je podle mě, problém návrhu. Prostě je postavené tak aby vypadalo dobře v jedné situaci.
Příkladem budiž například Zaklínač 3. Který je open world, na první pohled se tváří, že toho načítá strašně a reálně je tam velice dobře zvládnutá optimalizace, kdy většina dat je jen mapa, textury se nemění nijak dramaticky.
Haha, vraj gaming industry trapia nahravacie casy. Dovol mi ta vratit spat na zem:
https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/
Netrápí ho nahrácí časy textur, 3D objektů a podobně. Od příchodu SSD disků a gigantické velikosti RAM a VRAM.
Co se týče parsování XML, inicializace scény, generování čehokoliv, to vše bude chvíli trvat. Tahle technologie to nijak neřeší.
Možnosti SSD disků (NVMe) a velkých RAM & VRAM budou použity pro ještě větší a jemnější textury a pro větší rozlišení (4k bude časem části hráčů zase málo), takže časy nahrávání textur jsou vyřešeny jen na chvíli, se obávám.
Neřekl bych, například UE5 dema se nahrávají instatně i když mají desítky GB. I obecně se používají PBR materiály kde se z pár textur a shaderů vytvoří cokoliv. V řadě případů tedy odpadá nutnost mít pro každou věc extra texturu, jednoduše se použije stejný materiál pouze s jinými parametry. Stejně tak se recyklují modely kdy je 90% procent 3D scény poskládáno třeba jen z 10 objektů. To všechno redukuje velikosti dat a náročnost na přenosy mimo buffery (disk -> cpu/RAM -> VRAM).
Kromě toho čas honění za kvalitníma texturama a vizuální čistotou je dávno pryč, dneska frčí rozmazaný obraz. 4k textury nakonec vypadají hůře než 512 x 512 před 15 lety.
Gaming průmysl samožrejmě zatraceně trápí kolik GB má instalovaná hra.
1: při dělání masteru na různé distribuční platfromy to znamená dodávat a připravovat větší objem dat
2: náročnost stažení, více dat, delší stahování, ne každý sedí na Gbit netu.
3: na cílovém zařízení bude vyžadováno vyšší úložiště a to je docela zásadní, zvláště pak u konzolí.
Nemálo her už dělalo úklid Fortnite se zmenšil asi na polovinu, nebo třeba v Destiny 2 se také snížila velikost instalované hry (zvláště na PS) a aby toho dosáhli tak ze hry ubylo hodně i dříve placeného obsahu - celá DLC. Bylo to jednoduše nezvladatelné
To sem zvědav, sem velký skeptik, ten test je směšnej. Ted zrovna hraju Encased, kterej jede na Unity. Ten engine nahrava vsechno 10s. i kdybyste meli nejrychlejší disk ve vesmiru, tak se to nezkrátí. Pokud by se to nahrávalo jenom 2x rchleji, tak bych to považoval za revoluci rovnou příchodu SSD.
No já jsem hlavně rád, že to pojede i na Win10 a nebude kvůli tomu potřeba mít ten bastl Win11...
Když je konkr. major verze Windows (nakonec) povedená, je třeba vydržet úvodní problémy. NO a když zrovna napotvoru ne, tak následující major verze bývá výrazně lepší :-).
Kdyby Win11 neměly na sílu vše zakulacené, byl bych je ochotný používat místo Win10 klidně už dnes.
Konkrétně mi ve Win11 velmi vadí nové pojetí zvýraznění aktivní položky v roletových menu aplikací napsaných před Win11.
Např. menu File -> Open/Save/Exit ... Tam se nový design opravdu nepovedl.
https://stackoverflow.com/questions/73172147/can-you-get-the-windows-11-...
Mě na tom vadí snad úplně celý GUI...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.