- Megérkezett a legújabb és eddigi legátfogóbb 3DMark teszt
- SSD kibeszélő
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Milyen billentyűzetet vegyek?
- Videós, mozgóképes topik
- HiFi műszaki szemmel - sztereó hangrendszerek
- iPad topik
- Milyen SSD-t vegyek?
- Épített vízhűtés (nem kompakt) topic
- Kormányok / autós szimulátorok topicja
Hirdetés
-
Olcsó és visszafogottan elegáns kompakt AIO jön az ID-Cooling berkeiből
ph Az előzetes tesztek alapján korrektül teljesítő modellnek nem kenyere a cicoma, és akár titkos favorit is válhat belőle a kategóriájában.
-
Destiny 2: The Final Shape - Befutott a fejlesztői videó második része
gp A minap kiadott videóban többek között a képességek kerülnek a középpontba.
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
lenox
veterán
Az miert is lenne jo, ha a virtualis memoriat elerne a gpu? Szoval a kiswappelt lapokat probalna a gpu elerni, valahogy diskrol beolvasna, es azon processzalna? Ez eleg furanak tunik nekem.
A megatexturazashoz szerintem eleg a fizikai memoriat elerni, azt meg mar tobb eve lehet nvidian is, ha valamiert ugy akarnad, csak cudat kell hasznalni. Amennyire en ertem, ezt a Rage-nel meg nem csinaltak meg, de majd fogjak, vagy nem? -
lenox
veterán
A virtualis memoria elerese gyorsabb lenne a gpu-bol, mint a fizikai?
Nekem az a resze sem nyilvanvalo, hogy ez licenszkerdes lenne, magamtol azt gondolnam, hogy ez driver kerdes. Kuldenel erre egy linket? Csak mert mint mondtam, cudabol mar tok reg elerheto a gpu es a cpu memoria is, bar az igaz, hogy automatikusan nem transzferalgatja oket egymast kozt (nem cache-eli), de szerintem az amugy is inkabb hatranya lenne, ha nem tudhatna az ember, hogy amit el fog erni, az gyors lesz-e, vagy lassu. -
lenox
veterán
Nem tudom milyen elv szerint igen, szerintem ami a virtualis memoriaban van, az vagy a fizikai memoriaban van, akkor hasonlo gyors (valamivel lassabb a virtual/physycal cimforditas miatt), vagy ki van swappelve, akkor meg joval lassabb. Mitol lenne gyorsabb? Szerintem semmitol.
Ez azt jelenti, hogy a textura update egy hosszú szoftveres procedúra eredménye, amibe be kell vonni a processzort és a rendszermemóriát. Ha a GPU elérné a virtuális memóriát, akkor a teljes folyamat hardveres lehetne, vagyis a rendszermemória és a CPU kizárható a frissítési procedúrából.
Ez alatt nem tudom mit ertesz, szerintem ez teljes felreertes. Az, hogy melyik lapokat kell majd hasznalni, az mindenkepp egy szoftveres procedura eredmenye, es a rendszermemoriat is mindenkepp bele kell vonni. A video memoria virtualizalasa ezt nem oldja meg, csak annyira jo, hogy nem kell a lapokat explicite atnyomni a gpu memoriaba, mivel ha a gpu amugy is eleri a rendszermemoriat, akkor onnan is hasznalhatja az adatot, legalabbis ha jatekrol beszelunk, mert virtual gepeknel ennel tobbre is jo. Carmack meg arrol beszel, hogy ha egy lap helyett annak egy masik valtozatat kell hasznalni, akkor konzolon kb. atirjak a pointert, pc-n meg at is kell tolteni az uj lapot gpu memoriaba. Persze konzolon meg nem tudod elerni 1xx GB/sec-kel. Mindenesetre ha egy cuda (vagy opencl) kernelt hasznalnanak az update-hez, akkor azt is meg lehet csinalni egy kernellel, nem kell hozza 50 update, es mar evek ota mukodik.
-
lenox
veterán
Carmack gondolom nem a kisujjából szopta ki, hogy a texture update PC-n tízezerszer lassabb, hanem kimérte.
Nyilvan nem onnan szopta, azt kell csak latni, hogy ugyanolyat csinalhatsz pc-n is (cudaval legalabbis igen), persze sok esetben lassabb lesz, mintha updatelned a lapokat a gpu memoriaban, ugyhogy kerdes, hogy jo-e ugy csinalni. Ha olyan apud van, ami supportalja, hogy a gfx membe kozvetlenul irj a cpu oldalrol, az nyilvan feleslegesse teszi ezt. En leginkabb azt a reszet nem latom, hogy milyen virtualizacios licensz kell ehhez gamer oldalon. Mert oke, hogy virtual gepeknel van haszna, de jatekoknal szerintem semmi haszna, hogy ki tudjon swappelodni a gfx memoria, a fizikai memoriat meg mar eddig is el lehetett erni. OpenGL-bol meg DirectX-bol talan nem, lehet hozzajuk uj drivert irni, de licensz nemigen kell hozza.
-
lenox
veterán
Szerinted mennyivel lenne lassabb egy API-n keresztül CPU-val update-elgetni x ezer textúrát, mint ugyanezt hw-ből intézni?
Megatexturazasra gondolsz? Melyik scenario? Ami most pc-n van diszkret gpu-val, opengl-lel vagy directx-szel, vagy diszkret gpu-val pc-n cudaval, pc-n apuval, vagy konzolon? Nagyon nem mindegy.
Amúgy a textúrák ugye lehetnek a main ramban is (ami kívül esik a CUDA felségterületén)
Marmint ha pinned memory, akkor pont hogy eleri a cuda es a cpu is, ez a lenyege. Ha nem eri el, akkor meg nem lehet belole texturazni. Nyilvan gyorsabb buszon gyorsabb. Az egeszet egyben atmasolni a leheto leglassabb, legrosszabb megoldas. Ha van pl. gpu memoriaban 100 lapod, amik egyenkent 4 MB-osak, akkor ha az egeszet updatelned, az 400 MB, az mondjuk opengl-nel kb. 0.25 sec alatt menne fel, cudanal meg 0.1 sec alatt, mindkettonel tul lassu. De ha csak 5 lapot updatelnel, akkor ertelmetlen is lenne mindet feltolteni.
Ja, és szerintem előbb-utóbb a swappelési lehetőséget is ki fogják használni...
Szervereknel, virtual gepeknel biztos, jatekoknal nem nagyon hiszem, hogy ez barmit hozzatesz.
-
lenox
veterán
Végülis bármelyik.
Hat pl. opengl diszkret gpuval az eleg bena pc-n pont erre, ugye Carmack is erre panaszkodik, azon gondolom egy hardverrel tamogatott megoldas segitene, a cudas diszkret gpus esethez szerintem kulon hardver mar nemigen gyorsit rajta.
De még mindig gyorsabb, mint sok-sok műveletben, textúrán belül is részletenként update-elgetni, nem?
Hat ha opengl-lel akar az ember kurvasok nem egybefuggo pixelt egyessevel modositani valamiert, akkor igen. De amugy az is elegge ossze van mosva, hogy valamilyen reszletet akar eppen az ember updatelni, vagy a megatexturanak akarja a megfelelo lapjait behozni, mert ez utobbihoz nem egy-egy pixelt kell updatelni, raadasul ha nincs kesz a kovetkezo frame-ig, az sem baj, mert rosszabb felbontasban ugyis megvan. Persze opengl-nel problemak vannak a multithreadingnel, ha esetleg a hatterben akarna az ember frissiteni, directx-nel nem tudom, opencl meg cuda az meg ok.
1,6-4 GB/s? Miért ilyen állati lassú?
Az opengl az ilyen lassu (1.5-2.0 GB/sec), szokott benne lenni egy plusz copy, leginkabb azert, a cuda pinned memorybol olyan 5.5, csak nem akartam 5 tizedesjegyik irni, csak a nagysagrendet, az meg amugy nem olyan lassu, cpu mem-en belul sem masolsz sokkal gyorsabban. Nyilvan ha nem kene masolni, az jobb lenne.
-
lenox
veterán
DMA-val.
Meg aztán nem csak a sustained rate számít, hanem ha sok kis írásról van szó.
Azt kerulni kell, amennyire csak lehet, ezert mondom, hogy en egy kernellel csinalnam az update-et, akkor csak egyszer van overhead. Nyilvan ha egy egysegben csak 1 pixel van, akkor ez sem fog mukodni, de a megatexturing azert nem errol szol.
Hááát, annak inkább 10+ GB/s kellene lennie.
Ha ezt is ugy szamolod, hogy 5.5 GB olvasas, 5.5 GB iras, akkor ez is 11.
-
lenox
veterán
Nincs közben/előtte valami konverzió, GPU-val, vagy éppen CPU-val? Vagy véletlenül nem GPU-specifikus? Tehát, hogy adott GPU-n vacakul van megoldva a PCIe->GPU->VRAM átvitel.
Hat en ezt eleg sok nvidia (quadro 6000, quadro 4000, tesla 2050-2070, gtx 590, gtx 580 stb.) es par amd (5870, 5770 - ezek mac-en) kartyan neztem cudaval es opencl-lel, hp z800-on, mac pro-n, 6 GB/sec folotti atvitelt semmi nem produkalt, legtobbszor sajat koddal, de az nv-nek is van ilyen tesztprogramja, ez viszonylag jol van definialva, hogy hogyan lehet a leggyorsabb atvitelt elerni, mert amikor a kartyan belul mar majdnem 200 GB/sec van, akkor nyilvan erdekes, hogy mi a max sebesseg, hogy a leheto legkisebb legyen a bottleneck a fel-le toltesnel. Bevallom, nem neztem utana, hogy miert nem 8 GB/sec, orultem, hogy nem 1.5-2, mint amit opengl-lel el lehet erni.
Nos, lehet, hogy arról szól az egész, hogy játékokban bizonyos esetekben elkerülhetetlen, nem?
Hat ha a jelenlegi opengl-lel csinalnja az ember, akkor gondolom igen, en csak azt mondom, hogy ezen nem az x86 virtual mem licensz fog segiteni.
Nem úgy... Pl. a DDR3-1600 max. olvasási sebessége 12,8 GB/s és az irási sem sokkal kevesebb, és ez még procival is megközelíthető.
Jo, de ez nem olvasas vagy iras kulon, hanem masolas. Ott meg amikor kijon a 12 GB/s-es masolas, akkor az 6GB/s olvasast es 6 GB/s irast jelent, nem? Everest/Aida-nal tudtommal igen.
-
lenox
veterán
-
lenox
veterán
Nem tudom mit akarunk kihozni belole, egy sb-s gepben ha gpu-ra feltoltesrol beszelunk egy gtx 580-nal pl, akkor legyen mondjuk 18 GB/sec savszel a cpu ram-nal, 192 GB/sec a gpu ram-nal, 8 GB/sec a buszon, ki tudja, milyen bottleneck van meg kozben itt-ott. Ki lehet valasztani, hogy akkor mehetne 18 GB/sec-kel, de akkor miert nem mindjart a 192 GB/sec-et valasztod? Nyilvan egyik sem jo semmire, hiszen a busz meg kozben 8-at tud. Csak mert ha ahhoz a scenariohoz hasonlitod, hogy apu van, es ott kell masolni a cpu es a gpu altal lefoglalt memoria kozott, akkor ott copy van, tehat nem lesz 18 GB/sec, csak 9. Persze ha meg ahhoz hasonlitanad, hogy idealis esetben nem is kene toltogetni, csak atirni a pointert, akkor annak meg nem is lesz ertelmezheto savszelessege.
Új hozzászólás Aktív témák
- AMD AM4 Processzorok - Ryzen 3 / 5 / 7 / 9 - Új - Garanciás
- Beszámítás! Intel Core i9 11900KF 8mag 16szál processzor garanciával hibátlan működéssel
- Xeon E3 1230 V3 LGA 1150 processzor i7 4790 i7 4770 teljesítménnyel
- Hibátlan - INTEL Core i7-9700K 8 mag CPU 4.9GHz + UHD Graphics 630 - LGA1151v2
- Intel Core I7 13700K - //Új//6hó garancia//Beszámítás//
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen