Ovladače NVIDIA 260.19.36

Vyšly ovladače NVIDIA 260.19.36 (x86, x86-64). Hlavní vlastností je to, že všechna užívaná paměť je inicializovaná na nuly, dále pak došlo na opravy různých chyb.

23.1.2011 23:53 | Luboš Doležel (Doli) | Nová verze

Komentáře

[Petr Tomášek]

OMG! Teprve ve verzi 260.19.36 zjistili, že je třeba inicializovat pamět!

[janskyj]

Tak vzhledem k tomu, že předtím jim to taky chodilo, tak to nemohli dělat zase tak špatně. Tohle je jen taková pojistka, že kdyby náhodou někdy přistupovali někam mimo rozsah (inicilizaci), tak to bude mít nulvou hodnotu a ne náhodnou.

[Petr Tomášek]

To, že něco „chodí“ je výmluva u všeho prasácky napsanýho kódu...

[atirage21]

Laicky to skúste prosím vysvetliť, čo to presne teraz prinesie, ...vyššiu stabilitu, nejaký lepší výkon, lepšie fungovanie , ..aby neboli problémy ako pri KDE4 ?

[stativ]

Neinicializování není nic prasáckého. Když můžu zaručit, že před tím než s pamětí pracuji tam budou validní data, tak je inicializace zbytečná.

[Šangala]

Inicializace může být užitečná/doporučená, ale ne-inicilizace nutně neznamená „špatný“ kód. I inicializace něco stojí…
Já bych to spíše vnímal buď jako, „dospělo to do fáze, že to téměř nic nestojí, tak je to dobrá pojistka zadarmo“ nebo „začínáme být nejistí, tím co děláme, tak to to raději pro jistotu uděláme“.

[Rivon]

+1, kvalitní komentář

[GeoRW]

„začínáme být nejistí, tím co děláme, tak to to raději pro jistotu uděláme“

hehe, tak to neni dobry signal do buducnosti

[chrono]

Možno ide len o bezpečnostné opatrenie (aby sa užívateľský priestor nedostával k informáciám jadra, iných procesov...).

[trekker.dk]

Opatrně s tou kritikou. O inicializaci se normálně stará gcc, jenže když máš strukturu, jejíž prvky se zarovnají tak, že vzniknou mezery (myslim, že se to stane např. u struct { short s; int i; } když int má 32bitů nebo víc), tak s i i budou nulové, ale ve volném prostoru mezi nimi zůstanou původní data.

Ta změna se pravděpodobně týká toho, že se vynulují i tahle data. Tipuju.

[finn]

No, tipnul bych si, že gcc použije memset(&str, 0, sizeof(str)) spíš, než aby inicializovalo ve struktuře položku po položce.

[nou]

praveze nie. cital som nejaku spravicku ze aj v kernely by chceli aby gcc inicializoval celu strukturu na nuly. nie len jednotlive polozky. ale nakoniec to ostava pri starom.

[trekker.dk]

Jak píše i předřečník nade mnou, tipuješ špatně. Víc najdeš třeba tady

[finn]

To je zajímavý, kdybych měl střelit od boku, tipnul bych si, že inicializace celé struktury bude v mnoha případech rychlejší než inicializace položku po položce.

[Jardík]

Inicializece položky po položce může být někde zase rychlejší než režie při volání funkce, která je navíc "obecná", obsahuje hromadu cyklů kvůli zarovnání, další cykly na zápis po nějakých "nativních" prvcích a další cyklus na zapisování po bytech, pokud velikost není zarovnaná na tu "nativní" hodnotu.

[Jardík]

Navíc GCC samo o sobě si nemůže dovolit volat funkci memset v knihovny C, když k ní třeba pak ani nemůsíte linkovat, takže sice by tam volání fce asi nebylo, GCC velikost a zarovnání struktury při překladu zná (takže by mohl vynechat různé ty blbosti kvůli zarovnání, pokud nejsou třeba),takže by mohl vygenerovat na x86-64 např. pár movů s nulou, ale ty movy bude generovat stejně i pro jednotlivé položky - takže když bude každá položka zarovnána na 8B, tak by se to nevyplatilo stejně a nebylo by to ani náročnější. Programátor ale s těmi dírami nemá co pracovat a ani se o ně starat, tak je to úplně jedno. A pokud tam budou nějaká data z předchozí aplikace, která měla citlivé údaje, měla si je před ukončením promazat ona a né vy.

[Mti.]

pokud to rozepises, tak treba v assembleru pro avr (protoze asm z pc jsem uz roky nepouzil a z hlavy bych tam nadelal jen zmatky) :

Predpoklad: v Z je pointer na strukturu, potrebuju v obou pripadech ldi r17,0 ;; nula, kterou to budu mazat (taktez v obou pripadech)

ldi r16, 8 ; delka struktury
cyk:
  st Z+,r17   ; 2 takty
  dec r16     ; 1 takt
  brne cyk    ; 2 takty pro kazdy skok "dokud neni nula" (1 takt pro pruchod rovne)

... tedy cca 16+8+15 taktu

a porovnej s timto

  st Z+,r17   ; 2 takty
  st Z+,r17   ; 2 takty
  st Z+,r17   ; 2 takty
  st Z+,r17   ; 2 takty
  st Z+,r17   ; 2 takty
  st Z+,r17   ; 2 takty
  st Z+,r17   ; 2 takty
  st Z+,r17   ; 2 takty

... 16+0+0 ...

V pripade, ze jeden setri kazdy takt cpu, je to velmi vhodne reseni. Pokud je hlavnim cilem misto, vyplati se pred startem hlavniho programu smazat celou ramku v cyklu, protoze jmenovite mazani jednotlivych struktur sezere nejvic.

[Jardík]

Na takovém procesoru na tom zřejmě záleží, ale x86 dokáže dělat divi, počet taktů není tak zřejmý, některé instrukce se dají paralelizovat ... Je třeba otázka, jestli na x86-64 bude rychlejší

; v rdi je pointer na strukturu
; { int64_t, int32_t, int64_t, uint8_t }
; kde jednotlivé prvky jsou zarovnány na 8B
; zarovnání dané struktury je 8B
mov QWORD [rdi], 0
mov QWORD [rdi+8], 0
mov QWORD [rdi+16], 0
mov QWORD [rdi+32], 0

Nebo

mov QWORD [rdi], 0
add rdi, 8
mov QWORD [rdi], 0
add rdi, 8
mov QWORD [rdi], 0
add rdi, 8
mov QWORD [rdi], 0

A nebo třeba

xor rax, rax
mov QWORD [rdi], rax
mov QWORD [rdi+8], rax
mov QWORD [rdi+16], rax
mov QWORD [rdi+32], rax

Nebo třeba použití instrukce lea apod...

[Mti.]

Na jakem? Na AVR? Velmi zalezi. To je naopak to dulezite. Ten cip jede presne na takt a diky tomu se tam jeste daji delat uzasne zverstva. A to i in/out jsou presne taktovane (1 takt a uderem dalsiho tiku to mate venku), takze to co si programator zmysli, ma "hned" vsude.

Nesnazil sem se poukazat na vytecne moznosti avr (8bit, 16MHz, casto 1-2 takty na instrukci... linux na tom nebeha), ale na jiny zpusob smazani bloku dat nez zrovna cyklem.

Navic pokud je struktura v gcc zarovnana, muze to zapisovat i ne-8bajty - a proto to muze takto produkovat - s dirama. Ikdyz si nejsu jisty, jestli to je rozumne (a jestli se to deje) i u velkych (megabajty) struktur

[SPM]

Spíš by mě zajímalo, jestli je tam už opravenej ten bug, kdy se některé grafiky přestaly dynamicky taktovat... ale jsem línej číst changelogy a jednak changelogům z nvidie stejně moc nevěřím :D

[Franta]

A souvisí to nějak s tím, že když probudím uspaný počítač, mám na obrazovce různé věci, které na ni kdysi byly (různá okna, plochy, ikony… různé rozházené, třeba jen část atd.) a až když pohnu myší, obrazovka se vymaže a zobrazí se přihlašovací dialog? Případně se po restartu počítače na obrazovce ukáže obraz, který tam dřív byl (nevím, jestli to jde z RAM nebo z paměti grafické karty).

[Wylda]

Mám přesně ten samý problém, než se objeví přihlašovací okno, tak se na chvilku objeví bloky šumu apod. Když pak restartuji, tak se objevují různé bloky předešlých oken, webových stránek apod. (a to ještě nejsem ani přihlášen;)

[trekker.dk]

IMO tohle spíš souvisí s tím, že máš rozbité něco jiného. Uspávání s nVidií a aktuálními jádry (tj. od 2.6.27 +/- dál) mi vždycky fungovalo bez problémů a bez zobrazování nesmyslů.

[Semo]

To iste sa deje aj pri prepnuti z X servera jedneho uzivatela na X server druheho, ak ten druhy X server bol neaktivny uz dost dlho na to, aby "prepol" monitor do suspend modu. Driver je ale OS ATI, takze chyba bude (aj) niekde inde ako v Nvidia driveroch.

[nou]

ide to z pamete grafickej karty. je to kvoly rychlosti kedze sa rata s tym ze sa aj tak cela obrazovka prekresly tak naco stracat cas mazanim.

[Ivan]

Tohle delal i Matrox. BIOS po rebootu nemazal video pamet. Dalo se toho vyuzit k ruznym blbostem.