Új hozzászólás Aktív témák

• hapakj őstag

  #13 jún. 11., 19:05:38

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  hapakj

  őstag

  hja, lassíthat a CPU is, s belegondolva DIY PC piacon lehet olyan abominationöket csinálni, hogy egy 2 magos pentium mellé rak 5090-et az ember

  Lehet rágörcsöltek, hogy ilyen eseteket is kezelnek.

  Így már befolyásolhatja az eredményt a CPU is, de az ARM-os platformokat jóval kiegyensúlyozottabbnak gondolnám ilyen téren.

• Abu85 HÁZIGAZDA

  #12

  #11 hapakj

  jún. 11., 18:23:08

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Abu85

  HÁZIGAZDA

  #11 hapakj

  #11 hapakj

  Hát egy tesztprogramnak nem kell általánosan minden hardverelemen futni.

  Tényleg nem értem, hogy egy sw-nél aminek elsődleges célja, hogy a GPU-t terhelje, hogy futottak annyira CPU-n optimalizálandó dologba.

  Itt konkrétan a CPU-nak kb csak annyi a dolga hogy kb fix dolgokkal eteti a GPU-t.

  Szóval vagy 2 hónap embermunka

  Ezt régen úgy magyarázta nekem Markus, aki anno felügyelte a 3DMarkot, hogy a CPU-nak nagyon fontos szerepe van abban, hogy a GPU-k jó teljesítménnyel fussanak. Emiatt a CPU-oldali kódot nagyon optimalizálni kell, hogy minél később jelenjen meg valamilyen limit, ami lassítja a teljes rendszer feldolgozását, és így a GPU-t is.

• hapakj őstag

  #11

  #8 Abu85

  jún. 11., 17:48:27

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  hapakj

  őstag

  #8 Abu85

  #8 Abu85

  Mert tesztprogram. Az az egésznek a célja, hogy minden egyes hardverelemen optimálisan fusson. Ennek érdekében a programozók assembly szintű optimalizálásokat is alkalmaznak. Ha ilyen mélyre lemész, akkor az már nem feltétlenül portolható nagyon eltérő architektúrák között, tehát ki kell dolgozni a másik architektúrára is ezt. Ez egy nagyon reális szemlélet az UL Benchmark részéről, mert nem akarják azt, hogy bármelyik hardver is hátrányt szenvedjen. Egy általános programnál nem ennyire kritikus ez, és ott nyilván nem lesz az, hogy eltökölnek több hónapot az ARM-ra való optimalizálással, hanem átrakják gyorsan, aztán ha lassan fut, akkor mondják, hogy vegyél gyorsabb procit. De az UL Benchmark ezt a programjuk célja miatt nem teheti meg.

  Hát egy tesztprogramnak nem kell általánosan minden hardverelemen futni.

  Tényleg nem értem, hogy egy sw-nél aminek elsődleges célja, hogy a GPU-t terhelje, hogy futottak annyira CPU-n optimalizálandó dologba.

  Itt konkrétan a CPU-nak kb csak annyi a dolga hogy kb fix dolgokkal eteti a GPU-t.

  Szóval vagy 2 hónap embermunka

• Abu85 HÁZIGAZDA

  #10

  #9 Busterftw

  jún. 11., 14:01:32

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Abu85

  HÁZIGAZDA

  #9 Busterftw

  #9 Busterftw

  Az biztos azon ment a fejlesztes, ha mar az piacon volt.
  Viszont szerintem van osszefugges a Spark es a teszt program launch kozott, ha mar az Nvidia az elmult par evben osszeboronalt a Microsofttal az arm miatt.

  Akkor lenne összefüggés, ha lenne ilyen hardverük, de nincs.

• Busterftw nagyúr

  #9

  #6 Abu85

  jún. 11., 09:53:16

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Busterftw

  nagyúr

  #6 Abu85

  #6 Abu85

  Mert ez egy tesztprogram és kritikus tényező, hogy hasonlóan jó optimalizálást kapjon, mint az AMD64-es kód. A legtöbb programnál megelégednek csak a lefordítással, aztán megy ahogy megy, de az UL Benchmark azért a programjaiban eléggé használ alacsony szintű optimalizációt, viszonylag sokat, és azokat nem olyan egyértelmű portolni, mert máshogy működik az ARM64 architektúra. Ezeknek a teljesítménykritikus kódrészeknek a portolása az, ami viszi az időt. A tipikus "fut, ahogy fut leszarják" mentalítással nyilván ők is gyorsabban megcsinálták volna.

  #5 Busterftw : Azt kétlem, mert az UL Benchmark írta, hogy Snapdragon X-eket használtak. RTX Sparkot még csak nem is láttak. Ettől nyilván kompatibilis lesz, mert az ARM64 adott, de egyáltalán nem erre a hardverre dolgoztak. A legtöbb döntést is a Qualcomm magdizájnja alapján hozták meg az optimalizálásnál.

  Az biztos azon ment a fejlesztes, ha mar az piacon volt.
  Viszont szerintem van osszefugges a Spark es a teszt program launch kozott, ha mar az Nvidia az elmult par evben osszeboronalt a Microsofttal az arm miatt.

• Abu85 HÁZIGAZDA

  #8

  #7 hapakj

  jún. 11., 09:10:08

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Abu85

  HÁZIGAZDA

  #7 hapakj

  #7 hapakj

  Ez egy GPU tesztprogram. Rég baj, ha problémát okoz a CPU load.

  Őszintén nem értem miért kéne annyit vakargatni a CPU kódot. 2 hónap embermunka max.

  Mert tesztprogram. Az az egésznek a célja, hogy minden egyes hardverelemen optimálisan fusson. Ennek érdekében a programozók assembly szintű optimalizálásokat is alkalmaznak. Ha ilyen mélyre lemész, akkor az már nem feltétlenül portolható nagyon eltérő architektúrák között, tehát ki kell dolgozni a másik architektúrára is ezt. Ez egy nagyon reális szemlélet az UL Benchmark részéről, mert nem akarják azt, hogy bármelyik hardver is hátrányt szenvedjen. Egy általános programnál nem ennyire kritikus ez, és ott nyilván nem lesz az, hogy eltökölnek több hónapot az ARM-ra való optimalizálással, hanem átrakják gyorsan, aztán ha lassan fut, akkor mondják, hogy vegyél gyorsabb procit. De az UL Benchmark ezt a programjuk célja miatt nem teheti meg.

• hapakj őstag

  #7 jún. 11., 01:20:35

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  hapakj

  őstag

  Ez egy GPU tesztprogram. Rég baj, ha problémát okoz a CPU load.

  Őszintén nem értem miért kéne annyit vakargatni a CPU kódot. 2 hónap embermunka max.

• Abu85 HÁZIGAZDA

  #6

  #4 hapakj

  jún. 11., 00:00:01

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Abu85

  HÁZIGAZDA

  #4 hapakj

  #4 hapakj

  Tényleg érdekelne, hogy ez miért került ennyi időbe és miért annyira nagy szám.

  Ennek két emberhónapnyi munkának nem kéne többnek lennie

  Mert ez egy tesztprogram és kritikus tényező, hogy hasonlóan jó optimalizálást kapjon, mint az AMD64-es kód. A legtöbb programnál megelégednek csak a lefordítással, aztán megy ahogy megy, de az UL Benchmark azért a programjaiban eléggé használ alacsony szintű optimalizációt, viszonylag sokat, és azokat nem olyan egyértelmű portolni, mert máshogy működik az ARM64 architektúra. Ezeknek a teljesítménykritikus kódrészeknek a portolása az, ami viszi az időt. A tipikus "fut, ahogy fut leszarják" mentalítással nyilván ők is gyorsabban megcsinálták volna.

  #5 Busterftw : Azt kétlem, mert az UL Benchmark írta, hogy Snapdragon X-eket használtak. RTX Sparkot még csak nem is láttak. Ettől nyilván kompatibilis lesz, mert az ARM64 adott, de egyáltalán nem erre a hardverre dolgoztak. A legtöbb döntést is a Qualcomm magdizájnja alapján hozták meg az optimalizálásnál.

• Busterftw nagyúr

  #5

  #4 hapakj

  jún. 10., 15:44:25

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Busterftw

  nagyúr

  #4 hapakj

  #4 hapakj

  Tényleg érdekelne, hogy ez miért került ennyi időbe és miért annyira nagy szám.

  Ennek két emberhónapnyi munkának nem kéne többnek lennie

  Nagy szamnak nem az, a launch viszont nem veletlen, kulfoldi forrasok az RTX Spark megjelenest irjak indoknak, ami ertheto.

• hapakj őstag

  #4 jún. 10., 15:29:45

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  hapakj

  őstag

  Tényleg érdekelne, hogy ez miért került ennyi időbe és miért annyira nagy szám.

  Ennek két emberhónapnyi munkának nem kéne többnek lennie

• kilua őstag

  #3

  #2 Busterftw

  jún. 10., 15:24:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  kilua

  őstag

  #2 Busterftw

  #2 Busterftw

  Ezt meg januarban irta az egyik dev Steamen:
  "A Linux version is under development. Until then, you have to understand that it is beyond silly to complain about something not working if you are running it thru an emulation layer that is incomplete. Wine/Proton cannot run anything relying on kernel level drivers/libraries, and our Windows hardware detection is based on Kernel level drivers. 3DMark is fine. Wine/Proton is unable to run it. "

  Milyen emulátor rétegről beszél? "Wine Is Not An Emulator" 😅

• Busterftw nagyúr

  #2

  #1 Rowon

  jún. 10., 13:29:13

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Busterftw

  nagyúr

  #1 Rowon

  #1 Rowon

  Linux port van már? Steamen láttam, hogy futtatható Protonnal, de azért kíváncsi vagyok, hogy lesz-e natív Linux verzió.

  Ezt meg januarban irta az egyik dev Steamen:
  "A Linux version is under development. Until then, you have to understand that it is beyond silly to complain about something not working if you are running it thru an emulation layer that is incomplete. Wine/Proton cannot run anything relying on kernel level drivers/libraries, and our Windows hardware detection is based on Kernel level drivers. 3DMark is fine. Wine/Proton is unable to run it. "

• Rowon nagyúr

  #1 jún. 10., 11:30:35

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Rowon

  nagyúr

  Linux port van már? Steamen láttam, hogy futtatható Protonnal, de azért kíváncsi vagyok, hogy lesz-e natív Linux verzió.

Új hozzászólás Aktív témák