Akadasmentes scrollozas linuxon?

Linux-haladó

hali,

Van egy uj gepem, a videokartya Nvidia 2060GTX, most pedig kaptam kolcson egy Radeon R9 280 szeriaju kartyat, ez azert mar nem mai darab.
Na most mind a ketto tokeletesen akasasmentesen scrolloz Windowsban. Linux eseten pedig mindketto akad neha. Van hogy scrollozok egy rovidet akkor nem akad meg, van hogy igen, de ha vegig gorgetem fel-le egy hosszabb weboldalon, tuti hogy akadozik.
Az NVidiahoz nyilvan a zart drivert hasznaltam, a Radeonnal meg kifejezetten azt szerettem volna probalni, hogy a nyilt driver segit-e, probaltam Xorg-al, Waylandel, de igazagol mindketto szaggat.
Probaltam tobbek kozott egy frissen telepitett Ubuntun.
Lehet, hogy van kulonbseg es az nvidia tobbet szaggat, sot talan az inditomenu effektje Nvidian neha beszaggat, Radeonon meg nem, de a windowshoz kepest a scrollozas mindkettovel eleg gyatra.

Szoval a kerdes, hogy sikerult ezt valakinek valamilyen beallitassal megoldania, vagy esetleg van olyan kartya amivel akadasmentesen mukodik a dolog OOB?

( wheelmaster | 2019. 07. 19., p – 21:39 )

Ez még 2019-ben is probléma linux desktopon? Döbbenet.
--
ne terelj

Szerintem egy operációs rendszer kernele kiszolgálja a hardware eszközöket ahogy tudja, de az az érzésem, nincs semmiféle garancia arra, hogy mennyi időn belül. Miért döbbenet ez? Ha csinálsz egy exponenciálisan eszkalálódó fork-ot több százas load-dal, szerintem még az egér kurzor sem fog megmozdulni, mert a kernelnek más dolga akad. Valós idejű problémákat szerintem továbbra is mikrokontrollerekkel, FPGA-kkal, CPLD-kkel oldunk meg, nem pedig operációs rendszerekkel.

De lehet, hogy azóta máshol tart a technika, én meg lemaradtam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Ez még 2019-ben is probléma linux desktopon? Döbbenet."

Engem már nem lep meg ha valami nem működik normálisan kapásból egy friss ubuntun. Amennyiben egy ubi a linux desktop, egyáltalán nem döbbenet.

Az nem derül ki konkrétan a posztból, hogy reszel-t is valamit a kolléga, vagy csak simán telepítette az ubuntu által felkínált zárt drivert.

Mindenféle disztro gyűlölködés keltés nélkül mondom. Ugyanez más diszrónál is jelentkezhet.

powered by ©gentoo

( barii | 2019. 07. 19., p – 22:38 )

lehet hogy a gnomeal van valami mert szerintem kde-ben nem csinalta

( gyuri2012 | 2019. 07. 19., p – 22:43 )

Mi az hogy "OOB"?
Nálam semmi baja a scrollozásnak, Intel (Lenovo x230, x280...), testing Debian.

( barii | 2019. 07. 19., p – 22:45 )

talan ez?

This issue is locked to the fact that gnome shell is both the "shell" and the window manager, on a single thread. this means any activity on the shell can even slow down window movement :/ it will require a large rework to solve

( barii | 2019. 07. 19., p – 23:04 )

kde-vel tokeletes, legalabbis a radeonnal, nvidiaval meg nem probaltam. gnome viszont remes

( Wooody | 2019. 07. 20., szo – 14:20 )

Nem 100% hogy ez a megoldás, de nekem azóta ne csinálja hogy, feltettem az
tuned (balanced vagy desktop profil) és az irqbalance csomagokat.

Tesztelve: Debian 9.9, Ubuntu 18.04 és Fedora 30
nvidia gtx 1050 (430.26)

Wayland használatakor, azaz görgetéskor 1-1 vízszintes sávban behomályosul.
Szerintem ez zavaróbb:)

( asch v | 2019. 07. 20., szo – 01:14 )

Régen kellett csinálni egy olyan programot, ami minden frame-t (60 FPS-re) tökéletesen rajzol ki, _soha_ nem akad el.

Próbálgattam egy csomó konfigurációt, meg méregettem és azt találtam, hogy volt például olyan egér driver, ami időnként megakasztotta a rendszert! Fogalmam sincsen, hogy mi volt a hatásmechanizmus: egyetlen faék egyszerűségű programot futtattam fullscreenben, ami számolta a saját frame-jeit, és közben nézte az időt. Pár százalékos volt a teljes CPU kihasználtság, frame limiterrel ment. És még ez is akadt! Elkeseredésemben elkezdtem kikapcsolni a kernel-modulokat. És az egérdriver kikapcsolásával megoldódott a probléma :-)

Csak azért írom, hogy egyáltalán nem biztos, hogy a videóvezérlőben kell kereseni a problémát.

Azért a JavaScriptben megírt bughalmokra, amik egy szálon futnak az ablakkezelővel, azokra én is mernék szavazni: például egy GC nem valószínű, hogy lefut 16 milliszek alatt.

( zz7 | 2019. 07. 20., szo – 21:39 )

Gyakorlatilag a vsync még mindig probléma Linux alatt, egyik általam próbált disztribúció se kezeli alap telepítés után megfelelően. Sajnos ez van, itt tartunk, a Linux desktop még erre se képes rendesen.

Nvidia driver bármelyik, nálam Mate és XFCE alatt bármilyen Linux rendszer verziónál.
A Vezérlőpultban meg kell keresni az Indítópultot. Ott fel kell venni hozzáadással új elemként:
nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 {ForceFullCompositionPipeline = On }"
Újraindítás után jónak kellene lennie.

Ezen kívül van még AMD és Intel VGA-hoz is vsync egyengető megoldás, ha kell valakinek leírom azt is. De kereséssel a neten is megtalálható mindez.

Hogy ezeket miért nem lehet végre beépíteni az asztali Linux változatokba, én se nagyon értem.

Rendben, elfogadom hogy talán, lehet.
De akkor ezt a vsync dolgot például a Windows hogyan csinálja ha mondjuk a monitorod 60Hz-es? Általában 2D használat közben gondolom be van kapcsolva alapból különben ott is szakadozottnak látnánk a képet néha. Aztán 3D alatt meg átadja a játék vezérlésnek, ott a játék beállításain belül be vagy kikapcsolod ahogy tetszik?

Windows alatt vélhetően 2D-ben van vsync (és talán ez lehet a megfejtés a scroll-mód oprendszerfüggő eltéréseire is), linux alatt én speciel soha be nem kapcsolom, ha meg valami miatt netán be lenne, akkor kikapcsolom.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

A Linux kikapcsolt vsync-el elég ronda tud lenni. Már ha egy HUP oldalt görgetek akkor is szép hullámokat produkál. Filmnézésnél katasztrófa. Ezért nálam alapból be van kapcsolva. Vagyis meg kell csinálni külön video vezérlő függően, mert a Linux nem kapcsol be alapból semmi ilyet, főleg nem egységesen kezelhetően. Desktop Linux nesze.
Megnéztem a Metro játék Linux-os verzióban a vsync-et a játékban be és ki lehet kapcsolni. Még nem néztem hogy viselkedik, de gondolom ha a Linux-ban 2D-ben be van kapcsolva, akkor a teljes képernyős játék majd ezt felül írja a saját beállítása szerint. Ha kikapcsolod a játékban akkor nem lesz teljes képernyő 3D-ben vsnyc. Legalább is így lenne logikus.

Kezdem kapisgálni: A játékmotor frissítése lehet gyorsabb akkor is ha nem minden frémet rajzolunk ki. Tehát te megnyomod a gombot és kimegy a lövés akkor is ha a monitor éppen nem tud frémet rajzolni. Mert kirajzolt frame nem lesz több mint amennyit a monitor tud.

Jól értem?

Igen, emberi szem (asszem) 25Hz fölött már folyamatosnak látja a képsorozatot (lásd pl, mozgókép), de attól még a játékérzet sokkal többet igényel. Gondolj bele: ha alacsony frame-rate mellett ugyanakkora reakcióidővel kell reagáljál, akkor hátrányban van a többiekhez képest, akik meg tolják mint a bolondóra.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ez szerintem biztos hogy emberfüggő. Annak idején a 60Hz simán villogósnak tűnt a 85Hz -hez képest (CRT). De ez csak a kép villogása.

Ugyanez volt igaz az FPS-re, pl. a CS -ben sokkal folyékonyabb volt az animáció és rajzolás 60 fps helyett 85 -ön, de 100nál már nem éreztem a különbséget. De itt nem a low latency interakcióra kell gondolni, hanem simán sétálsz előre és a falakat, meg a fegyvert a kézben folyékonyabban rajzolta.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene

A költői kérdésem az, hogy ez a két dolog miért függ egymástól? Miért nem lehet egy szálon futtatni az eseménykezelőt ami fut mondjuk 200Hz-en (5ms késleltetés) és a megjelenítő szálat ami meg fut mondjuk 60Hz-en (17ms késleltetés)?

Egyébként érdekelne erről egy értelmes tanulmány, mert a 100ms-től az 5ms-ig minden előfordul, mint küszöb, ami alatt már nem észlelünk késleltetést.

Első kérdésre: lehetne ilyet csinálni elvben, de baromi bonyolult lenne. A játékok a legutóbbi időkig egyszálúak voltak nem véletlenül. A játék állapot modellt így nem kell szinkronizálni a szálak között, és sokkal egyszerűbb minden. Ugye ezek tipikusan fa struktúrák szoktak lenni. Ha egy rajzolás közben szimuláljuk az inputot és a fizikát, akkor bizony szinkronizálni kell.

A frame limiter úgy működik, hogy amint lehet szimuláljuk a modellt, elkészítjük a képet, majd várunk addig, amikor kikerül a képernyőre. Majd megint szimulálunk, rajzolunk ész nélkül, aztán várunk. A várakozás hozzáadóduk a latencyhez, mert az inputot a rajzolás előtt dolgozzuk fel. Teház mira a képkocka a képernyőre kerül, addigra szisztematikusan van 16ms késleltetésünk az inputban. De ha eleve tudnánk, hogy mondjuk 4ms elegendő egy szimulálás+rajzoláshoz (~250FPS), akkor megtehetnénk, hogy várakozunk T-4ms-ig, és csak aztán szimulálunk+rajzolunk. Így az input késleltetése 12ms-mal kisebb lesz. Amiért ezt nem szokás csinálni az az, hogy "kockázatosabb", esetleg elkéshet a rajzolás és akkor frame drop van, ami a legnagyobb baj.

A látásunk időfelbontását úgy kell érteni, hogy 25-60FPS környékét már folyamatosnak látjuk, oké, de az agyban nem állóképek sorozata van, hanem mozgásokat épít belőle. És azon belül egy dolognak a helyét sokkal pontosabb időfelbontásban állapítjuk meg, mint 16ms. Például egy pingponglabdát nem tudnánk visszaütni, ha ekkora felbontású fizikai modellünk lenne róla a fejünkben. Ezért jön jól ha több frame van, mint 60. Egyáltalán nem felesleges. Csak túl drága...

John Carmack-tól hallottam vagy olvastam annó, hogy olyannal próbálkoztak még, hogy rajzolás után egy utófeldolgozó lépésben még a késői input eseményeket feldolgozták a VR szemüveg miatt. Mert ott rosszullétet okoz a túl nagy késleltetés, és számít ez a kb 12-15ms plusz. És a fej forgatását közelítőleg utólagos transzformációként is el lehet végezni, akár 1ms alatt. (Ugye ezek az eredeti VR szemüvegek 60FPS-sel mentek.)

Eddig rendben. De a gyakorlatban ez mondjuk Linux viszonylatban hogyan működik?
Tegyük fel 2D desktop felhasználáshoz be van állítva egy 60Hz vsync. A kép sima, minden rendben weboldal olvasáskor, meg film nézéskor. És akkor indítok egy 3D teljes képernyős játékot amiben legyen mondjuk a vsync a játék beállításaiban kikapcsolva. Akkor mi történik? Marad a Linux desktop, például az Nvidia driverben beállított vsync a játékra is, vagy a játék átveszi és kikapcsolt vsync-el fut teljes képernyőn 3D-ben?
És hogy csinálja ugyanezt a Windows?

( azbest | 2019. 07. 23., k – 13:05 )

Ha jól látom az nem írtad, hogy böngészőn kívül más is akad-e. S hogy melyik böngészővel.

Chrome alatt az advanced settings részen lehet pipálni, hogy az oldal rendereléséhez használjon-e gpu-t.
Viszont videó codec hardveres gyorsítása nincs engedélyezve linuxon és nem is lehet chrome-ban bekapcsolni. Chromiumból létezik patchelt változat, amiben engedélyezték. Ez lényegesen kevesebb procihasználattal megy a hd4000-es intel gpu-mon.

Néha a chrome-ban a gpu renderelés is csak ront a helyzeten, bár lehet az inkább régi gépenek. A t61-es gépemen a gma965-tel akadozik mellette. A videolejátszás chromeban és chromiumban is dögletes rajta, igaz azzal a géppel sehogy sincs hw dekódolás. A crystal hd kártyámat meg már nem támogatja semmi. Poén, hogy ugyanezen a gépen a firefox simán megy és youtube is 720p-1080@30 vp9 módban is jól megy.

Lehet 4k desktoppal dögletesebb a böngésző is. Bár nvidia gpu-val egészen más kéne legyen.