Nvidia 100.14.19 tapasztalatok

PCI-E 1.0a csatlakozóm rohammértékben történő elavulása miatt PCI-E 1.1 Videókártya vásárlást tervezek. Geforce 8as családból , ezért előre frissítettem a drivert, mert a jól bevált 8776 már ezeket az újdonságokat (- jól van lehet röhögni :D ) nem támogassa.

Aztán hogy mégis mennyire viseli el a házi 2.6.18as agyonbarkácsolt környezet meg hasonlók, azért gondoltam meg kéne nézni közelebbről ezt a drivert.

Valami olyan kiszerelésben gondoltam videókártyára ami 8600 gt alapú, 256MBDD3-as, nem túlhajtott az nvidia speckóhoz képest, és viszonylag csendes, de nem passzív hűtéses, mert nem lenne jó a kasznin belüli többi jószágból rántottát csinálni.

A kiszemelt áldozatok számát elméletben 3ra sikerült szűkíteni.:
ASUS EN8600GT/HTDP/256M

Leadtek PX8600GT TD 256

Ennek nem tudom milyen a hangerejű a hűtése...

és a gigabyte bár ez már alapból túlhúzott.:

Gigabyte NX86T256H-ZL

Még azért ezen filózom, addig is a driver tapasztalatok.

Egy szóban: lassabb. Kétszóban: Kicsit lassabb. :)

Bővebben: :)

A 8776os driver szundizás majd azt követő X restart után 1 darab nv_kernel_close üzenetet biggyesztett a kernelnaplóba, minden szundi után darabonként. gondot nem tapasztaltam, afféle "helyi sajátosság" :), és mivel x restart igen ritka, ezért nem is igen jött elő, de ha előjött akkor egyből 2 oldalra való :)).

Mindenesetre ez a jelenség az új driverrel megszünt.A glxgears kb. ugyanazokat az eredményeket hozza, picit talán gyakrabban megy 12000 alá, de nem'tudom, kb ugyanaz.

A syrnix2 test már érdekesebb volt, kapásból átváltott a xorg configban egyébként nem engedélyezett 800x600 as felbontásra - majdnem felborítottam a piát az asztalon, mikor megláttom, hogy eztmostmegmiértiséshogyan? -, mint kiderült valami ImplicitMetatypes opció került engedélyezésre az új driverben és hát ezért.

nvidia control center is dynamic twinview val enged "nem beállított" felbontásokra / videómódokra kapcsolni. Én nekem ez nem tetszik, nekem alkalmazások ne kapcsolgassák a nekik tetsző felbontást, majd én eldöntöm hogy mi kell nekik... :D

Pl. egyrészt azért nem mert helyi, de többfelhasználós rendszeren a kdm kijelentkezéskor érdekesen kapcsolgat át mindenféle korábbi user által használt felbontásokba, másrészt meg tényleg ne mert csak. Eittene mégis kinek a kvarcjátékos szemétdobja he'? alkalmazás devlóperé, vagy az uuseré ? :-)

syrnix ezután a kis közjáték után már a szokott módon beköltözött a képernyő bal alsó szögletébe és futkorászott viszont a 860-870 között maradt az eddigi 910-20 érték helyett. A csökkenés egyértelműen az új driver miatt van. Sanda gyanum szerint már geforce 8-ra "lőtték be", emiatt aztán a régebbi kártyákkal (most 6600 gt van), már nem az igazi...A teljesítmény csökkenés kb. 4-5%. majd még megnézem az nvidia doksiban a - nekem - új X modul és kernel modul beállításokat mit lehetne kisajtolni még belőle.

A stabilitására panasz eddig nem merült fel. GL van, ép és egészséges, játékaim futkorásznak. wine ból is.

compiz nincs, ez a része a linuxos deszktop világnak nem érdekel.

Mindenesetre az a gyanum megerősítést nyert, hogy régebbi - < mint geforce 8xxxx - nem érdemes az újabb driverekre frissítgetni, mert lassuláson és esetleges inkompatiblitáson kívül egyéb eredmény valószínűleg nem jelentkezik. Hacsak a használt kernel nem kíván meg újabb drivert / pl. 2.6.24 /. :)

( NagyZ v | 2008. 03. 13., cs – 14:37 )

azert eleg gaz, hogy agyonhaxolt kernelt hasznalsz, amibe mindenfele normalis audit nelkul (tudtommal nem vagy PAX szakerto) hanyod bele a patcheket...

most vagy desktopnak hasznalod, es akkor ne paxolgass, vagy vagy hasznald szervernek, de akkor nem ertem hogy kerul bele egy gef8 :-)

no offense, csak haszna nem sok van annak, hogy mindenfele szirszart beleszorsz a kernelbe.

most vagy desktopnak hasznalod, es akkor ne paxolgass

Desktopnak használom, de lusta vagyok előkeresni a firefoxban kódfuttatást lehetővé tevő hibák számát mondjuk csak az elmult 1 évből.

Ebbe a körbe beleértem a különféle pluginok hibáit is, mint pl. java, adobe flash player.

A gépet nemcsak én használom, én esetleg el tudom dönteni, hogy teszem azt xyz honlap meglátogatása káros ,más nem biztos... / viszont nekem kell utána takarítani, ha összeszed valamit :D /

Korántsem javítanak minden hibát a debianban (sem). Debsecan rendszeresen jelenti a rendszerben levő csomagok különféle javítatlan hibáit. a jelenlegi lista is több oldal. vannak amikre (pl. jre/flash ) kb. nincs javítás, és vannak visszatérő problémás esetek, amik majdhogynem hetente frissülnek, pl. az acroread. Ezek potenciálisan sérülékeny szofferek, cuccok, de nincs nagyon alternatívájuk. :(

Ezért igénylem az extra memóriavédelmet.

--------
csak haszna nem sok van annak, hogy mindenfele szirszart beleszorsz a kernelbe.

Neked mindenféle szirszar, nekem meg fontos. :)

I. 2.6.18al alapból nem megy a szundi. ergo nem tudom azt megcsinálni, hogy elmegyek dolgozni éjszakára, a kaszni magától bekapcsol, felvesz a tunerkártyával egy filmet/műsort/meccset, stb. , kikapcsol, 3 óra múlva megint bekapcsol, felvesz egy másikat, kikapcsol. egész éjszaka mennie kellene.

II: fenti használat miatt fontos hogy a szenzorinfok legyenek, ugyanis Murphy nem alszik, bármi bedögölhet. szünetmentes természetesen van. de ha mondjuk leáll a venti kitörölhetem azzal, ha kigyúllad az egész hóbelevanc. :)

III. sajnos a nyílván "megfelelően auditált" vanilla kernelek is tartalmaznak különféle hibákat, mert hibák mindenben vannak. Így pl. abban a spéci helyzetben vagyok, hogy bootoláskor az alaplapnak a liunx nforce 4 check vendor biossal köszön.

IV: néha napján különféle okok miatt / tényleg ritka, tavaly ha összesen 7szer előfordult / egy chrootolt apacheot indítok / másképp is meg lehetne oldani a dolgot, de ez tűnik a legcélszerűbben a bizonyos célra :), pár napra, egy hétre.

V: olyan alaplapom van, aminek bizonyos funkcióit (hypertransport) nem támogatja a 2.6.18as kernel megfelelően. meg néhány fals hibát (pl. check vendor bios üzenetek) bedobál bootoláskor. nem szép :)

Talán a PaX al egyetlen probléma volt tavaly, amikor különös bug jelentkezett de ezt is sikerült orvosolni, és ez sem a házilag gányolt cuccban volt, hanem a hivatalos stabil 2.1.10-2.6.19 grsec is tartalmazta a 2.6.19es vanilla kernellel.

csak azért tettem ki a házi gányolást, ha valakit érdekel, akkor ott van, ha nem hát nem. semmilyen célja nincs, csak föltöltöttem oszt kész. de ha már megvan, feltölteni igazán nem tart semeddig.

Egyedül az x64 -es portos cucc volt vakvágány, mert az X64es OS nem vált be, túl sok cuccnak kellett (volna) 32bites környezet, nem érte meg. Pedig nagy kár érte, dehát ez van. Az alkalmazások nem nőttek fel hozzá még mindig.

egyébként 2.4.18 óta (debian woody) ez a szokásom. Kijön a debian stabil verzió, keresek hozzá egy grsecet, aztán ami hiányzik menet közben, az szépen belekerül. Általában hamar megvan, és ez a házi módszerem nálam megbízhatóan működik.

Hogy egyszerűbben fogalmazzak, nekem egyszerűbb ez a módszer, mint szívni a 2hetente megjelenő újdonatúj vanilla kernelekkel.

A woody, és a sarge kerneleihez (2.4) a cuccok kisebb helyi servereken is futottak még. Aztán pénzkeresetileg eltávolodtam az informatika világától gyakorlatilag teljesen egy pár éve. :)

-------------

Nem a zsömle kicsi, a pofátok nagy...

tudom, hogy ez a szokasod, mar regebben is lattam a patcheket, pont ezert kerdem :)

csak azert lassuk be, a 2.6.18 nem mai darab. sot, a 2.4 -es szeria sem...

tudom, hogy a 2.6 -os szeria ellen vagy (bar nem ertem miert, attol fuggetlenul, hogy nem a legjobb a jelenlegi fejlesztesi modell, azt el kell ismerni, hogy sokkal gyorsabb fejlodik a kernel, miota ezt hasznaljak; akinek meg stabilitas kell, hasznalja a long-term agakat), de lehet, hogy ott sok minden alapbol mukodne, barkacs nelkul.. :)

csak probalom felfogni a dolgok ertelmet, szoval nem kotekedesbol irom most tenyleg :) de ha ennyi idod van, miert nem tanulsz meg valami olyat, amivel szakmailag elore lehet lepni? pl nemistudom, oracle, j2ee, php, istentudja ;)

hasznalja a long-term agakat, mivel már csak hivatalosan a 2.6.16 az és abba új stuffok nem kerülnek bele, csak bugfixek ... nagyritkán elvétve pár új PCIID .. és azért a 2.6.16 sem mai darab

2.6.22.y-nal leálltak, mert csak "plussz melő", és igen én is úgy vagyok vele, hogy inkább backportolok / megkeresem a megfelelő patchet git.kernel.org-on vagy egyébb distroban és azt belerakom, mint hogy frissitsek 2.6.23=< kernelekre, azok valahogy nem jönnek be, a másik ilyen dolog, hogy én spec a 2.6.22-es kernelt már kiismertem és ezzel a géppel, meg ahol használom, ott tökéletesen mennek; ezt a kernel-t (2.6.22.y) már -rc1 avgy -rc2 óta nyúzom, szóval jó ez, szeressük és marad :P

debian gnu/linux @ linux-2.6.22.20-op1 | patch
info

Azért vagyok a 2.6os széria ellen, mert fejlődésben túlnövi disztribúciókat. Az újabbnál újabb funkcióit képtelenség egy nem teljesen naprakész disztróban felhasználni. Az egy más kérdés, hogy nekem mezei desktop usernek nagyrészt tök feleslegesek.

vagy pl. lirc (tunerkártya távirányító esete) ami most már végleg felejtős.

És akkor nem beszélve arról miket művelnek időnként a kernelben. nem fordul le egy fájl egy architektúra alatt, és akkor kiszedik és nem fordítják le. És az érintett funkció, vagy működik, vagy nem. :). A látszólag értelmetlen függvényátnevezésekről már nem is beszélve. Addig nincs baj, amíg egy kernelközeli disztróbeli cucc nem akarja használni :)

ha ennyi idod van, miert nem tanulsz meg valami olyat

Nem tart ez olyan sokáig mint hiszed. A cuccokat apránként pakolgattam a kernelbe. A 2 nagyobb volumen, amivel pár nap néhány óráját elpöcsöltem a hypertransort interrupt support, és a suspend to ram volt. de mindkettővel megérte. Ezt ugyanis csak egyszer kellett megcsinálni a debian etch életciklusa alatt. A debian meg nagyrészt csak sec.fixeket ad ki a kernelhez, nagyrészt driverközeliek. azok meg egyik másik gányolásomat sem zavarják (legalábbis eddig egy sem zavarta).

Egy 2hetente frissülő vanilla kernellel tucatszor ennyi problmám lett volna.
pl. a szundi, hol ment volna, hol nem, attól függően éppen az adott percben milyen ACPI kezelést fordítanak a kernelbe / nem túlzás talán azt állítani azt hiszem hogy az ACPI kezelést kb. ha nem is percenként, de óránként változtatják /. Akkor clocksource= tsc unstable is megint mit keres a kernel logban, egyszer már sikerült kiírtani ? a sysfs ben jónéhány "bejegyzés" deprecated. azok az alkalmazások amik itt keresik, azokat lehet cserélni.

pl. lirc, nvidia driverek, xorg frissítés hogy csak a 2.6.24 legutóbbi próbájára gondolok. fél órát ha élt a 2.6.24 a rendszeren. és mindegyik probléma túlmutat azon, hogy bemegyek a git, be turkálok egy darab patchet a problémámra, lefordítom, és kb. el van intézve a dolog . :-)

pl nemistudom, oracle, j2ee, php, istentudja ;)

nincsenek informatikai ambícióim. megélhetésemet biztosabb alapokra helyez(t)em. :)

---------

Nem a zsömle kicsi, a pofátok nagy...

( Oscon | 2008. 03. 13., cs – 16:34 )

Titkon azt remél(t)em hogy a 3 kiszemelttel kapcsolatban kapok valami frappáns tippet, ami eldönti a dolgot.pl. valakinek van az egyikből és tud valami fontos negatív/pozitív tapasztalatot :)

---------------

Nem a zsömle kicsi, a pofátok nagy...

nv 8xxx+ kártyákban van valami, amiben látok jövőt, ez a CUDA, de amúgy szerintem én nem nagyon használnám ki / használom ki.

jelenleg egy jó kis ati r9600-tal és xorg-os radeon driverral elvagyok, a géppel nem játszom és nem grafikázok ..

debian gnu/linux @ linux-2.6.22.20-op1 | patch
info

linux alatt neked melyik driver van fent? suse 10.3 friss telepítés után feltettem az nvidia repojából, azt mondja rá a glxinfo, hogy van 3d-s gyorsítás, de semmilyen más program nem tudja használni a 3d-t. sem compiz sem játékok. igaz a compiz menne indirect renderinggel, de az meg azt mondja No GLXFBConfig for default depth, this isn't going to work. megnéztem ez ügyben a goggle első 20 találatát majd feladtam...

( chrono | 2008. 03. 13., cs – 17:41 )

Mielőtt megvennéd a 8-as kártyát szerintem olvasgasd az nvidia linuxos fórumát. Jobbára működnek ezek a kártyák Linux alatt, de alig valami performance plusz a 7-es szériához képest. Kb minden 10. topikban ezen sír valaki. Persze előbb-utóbb biztos rendbe rakják.

Nekem 7600gs van AGP-n és a legújabb driverrel pont ugyanolyan gyorsak a játékok, mint az egy évvel ezelőttivel, mikor vettem. És a glxgears nem benchmark.

Az ára nem olyan rossz, és mivel technológialiag ez az elérhető csúcs :D az alaplap miatt (PCI-E 1.0a), ezért ő lett a választott delikvens.

glxgears-ben szerintem nincs egészen igazad. Ha ugyanaz driver de eltérő kártyákkal, akkor szvsz megfelel egy kezdetleges tesztelésre. Meg xorg.conf opciók, ill. spéci kernel beállítások teljesítményre gyakorolt hatásának finomhangolására is.

Pl. a PCI - MSI support- ot ezért dobtam ki végül a .config-ból. nem volt meggyőző=felesleges :D. A hypertransport interrupt support viszont igencsak jótékony hatást gyakorolt.

Ha a driver is eltérő, meg a kártyák is, akkor valóban nem jó még kezdetleges bencsmárknak sem. A 8776os és a 100.s driver közötti mérésére pl. nem volt jó.

Ugyanazon kártyák Driverei közötti különbség mérésére a syrnix2-t használom :D... Itt már 4-5%ot bukott a 100.as driver a 6600 gt-s kártyával 8776oshoz képest ugyanazokkal az opciókkal.A fejlesztésnél már gondolom más kártyák támogatása volt a fő szempont. :-)

---------

Nem a zsömle kicsi, a pofátok nagy...

Biztos esik az ára, már van a 9-es széria. Egyébként a linuxos béta driverbe már bekerült a 9600gt támogatás, most olvastam a bejelentést. Hogy milyen csatolókkal kapható nem tudom.

A glxgears-ró annyit, hogy a 9200-as radeonommal többet mutatott, mint a mostanival, szóval nem tudom, mit mér, de hogy nem a vga teljesítményét, az biztos. Ezért szerintem irreleváns, hogy egyik vagy másik driverrel mit mutat, legalábbis a grafikus teljesítmény szempontjából. Benchmarknak én a Doom3-at használnám, ha tudnám hogy lehet kiíratni a képernyőre az fps-t. Hát nem vagyok valami nagy gamer:) Úgyhogy marad a Torcs.

Év elején sokat olvasgattam, az nvidia fórumát, mert bejelentettem egy hibát. A cég emberei cáfolni szokták azokat a véleményeket, hogy az új driverekkel lassabbak lennének a régebbi kártyák, merthogy nem csinálnak vele olyasmit, ami ezt indokolná. Azt ellenben elismerik, hogy a 8-as sorozat támogatása még nem az igazi. Mondom, a tulajdonosok csalódottak. Panaszkodnak 3D-re, 2D-re, xv-re. A 7-es már bejáratott és még olcsóbb:)

Az még hagyján , win alatt sem jobb a helyzet ahogy elnézem.DX9en a 7900 gt jobb, jobb mint a 8600as. DX 10 meg ugye engem nyílván húdenagyon érdekel. :)

meg kell ezt fontolni még egyszer.ez már látszik. :)

szerk:

és mégsem. 7900nak igencsak megkérik az árát 40-50 E körül van. Alig pár ezerrel olcsóbb mint a 9600ázas.7600as is igen drága.

7600as DDR2-esnél meg azért már mégiscsak inkább egy 8600gt DDR3as cuccal.főleg hogy 1800 Mhz-s régi kvarcjátékkal lehet még ezt se sikerül rendesen "kihajtani" :)...

Az asus féle 8600 gt-t egy helyi netes árlistában 27120ért látom DDR3al, egy 7600 DDR2vel 30 körül van, a 7900 ennél keményebb.

erre még aludni kell min. 2-t :)

------
szerk:

torcs al az a gondom teszt téren, hogy nehéz ua. statikus helyzetet találni, az egyik endurance qualificationnal, starttól nyomtam a gázt és 290-312 fps között csapódtam be a "szembelevő betonkerítésbe/falba" /ha ezt stat. tesztnek lehet tekinteni :). 1800 Mhzn 1280x1024@16(?) textúra tömörítés nélkül compatible módban.

----------

Nem a zsömle kicsi, a pofátok nagy...

Én egész más szemszögből nézem a dolgot. Hiába jobb papíron egy kártya, ha szaggat a smooth scrolling a firefoxban a driver vs. xorg akármi hülyeség miatt. Vagy ha nem megy a hibernálás, már mehet is a kukába.

Anno bevittem a gépet a boltba, és megengedték (igaz jól ismernek már ott), hogy a kiszemelt kártyát beletegyem, drivert telepítsek és kipróbáljam. Egy jóval drágább 7800-ast is kipróbáltam. A Torcs 70 helyett 100 fpst produkált, ami nem meghatározó, viszont a Foobillard ugyanúgy szaggatott vele, ha ráadtam az anizotróp szűrést. Pedig úgy gyönyörű szépek az egymáson tükröződő golyók:) Tehát maradt az olcsóbb kártya.

7600gs volt egy éve karácsonyra 28k. Azt hittem mostanában nem lehet több 20-nál.

Torcs-nál abszolút pálya és helyzet függő az fps, de a kedvenc pályán a startnál ugyanannyi autóval szoktam nézni:)

rendered, rendered+freshnel? nekem nincs túl vűjt szemem, de nem érzékelek szaggatást. amikor balra jobbra "forgok", akkor picit , de nem vészes szvsz. kár hogy angol tudásom oly pocsék hogy nem tudok vele játszani :D
nem tudom irányítani, meg stb. f1 tudom, de nem értem. :D

----------

Nem a zsömle kicsi, a pofátok nagy...

"nem tudom irányítani"

Elmagyarázom. Gyakorlatilag mindent egérrel csinálsz. Bal gombbal tudsz forogni, középsővel lőni, jobbal zoomolni. Görgővel erősséget állítasz. Ha sorban lenyomod a bal majd ezután a jobb gombokat, akkor tudod mozgatni a fehér golyót, ha erre lehetőséged van a szabályok alapján. Ha sorban lenyomod a jobb, majd a bal gombokat, akkor meg a fehér golyó megütési pontját (kis fekete kereszt) tudod mozgatni.
Ezen kívül az n billentyűt érdemes megjegyezni, ezzel tudsz új játékot indítani.

Többet én sem tudok, de nem is nagyon van többre szükségem.

nvidia-settings -> Antialaising Settings -> Override Application Settings
Antialaising Settings 16x, Anisotropic Filtering 16x - maximalistáknak

Foobillard - Reflections Rendered, és persze Game Type Snooker - 3-szor annyi golyó. Hogy kellene network playt játszani? Próbálom Join van ott port meg egy IP beállítva, Start Game és kampec. Majd nyomozok. Hátha LAN-on sikerülne, nem kéne egy gépen játszani. Kár hogy már nem fejlesztik ezt a játékot, pár apró hibát kellene kijavítani és a világ legjobb játéka lenne.

Quick race -> Ruudskogen -> 5 laps:)

Kösz a választ!

Nálam a max beállítható Antialaising Settings 2x2, Anisotropic Filtering 2x lehet. Talán nem csoda, hogy így nem is szaggatott. Bár az fps jelentősen esett, ez szemmel látható volt, de a játékélményen nem rontott szinte semennyit. Maximum a szememet zavarta, de tényleg csak árnyalatnyi különbség érzékelhető. Viszont sokkal szebb. :)

Ruudskogen: jó gyors map. :)

Hát lehet hogy mégis egy 7xxx-es kártya lesz, ez a 100.x.x es driver mégiscsak lassabb mint a debecs féle 8776-os volt, akár mit is mond ez az nvidia fórumos izé.

mplayer -vo gl2 ben 1000 Mhz-n néha bizony van egy kis framedrop, és a másikkal meg még jó volt. lehet hogy 8776os ban nincs compiz / amit amúgysem használok / -hoz support, de csak gyorsabb na. glxgears végül is egál mindkét kártyával aszondanám 120xx körül van. syrnix2 -bmark al viszont 100.as driver már lassabb, és mplayer is. lehet hogy mégiscsak egy 7600 GT lesz.

---------

Nem a zsömle kicsi, a pofátok nagy...

( blueghost | 2008. 03. 13., cs – 20:37 )

Hi!

Szerintem ma mar nem nagyon eri meg 256 MB-os videokarit venni, foleg nem a geforce 8-as szeriabol, 512-est picivel dragabban lehet mar kapni (max 1-2 ezer forint kulonbseg)

A vid.kártya memória mérete önmagában nem okoz akkora többletet, mint a sebessége (pláne egy 1800Mhz-s processzoron / athlon 64 3000+ /, lehet hogy ennek a cuccnak már a 8600 gt is sok lesz. ) és max. 1280x1024-es fölbontásban / nyomitor ennyit tud.

--------

Nem a zsömle kicsi, a pofátok nagy...

1800 Mhz-s cuccal nem biztos hogy ki tudom hajtani, ráadásul PCI-E 2.0-s csatolós (=lutri, hogy megy e a lapkában stabilan vagy sem.) biztosra megyek 8600 lesz. a 8xxx-es teljesítmény problémákat ha jól láttam akkor 100.14.19ben javították.

Eldőlt a dolog az ASUS aktív hűtéses, de csendes csávó lesz a nyerő 8600 gt kategóriában.

-------

Nem a zsömle kicsi, a pofátok nagy...