[gl-como] Nvidia closed vs Nouveau

[Nicola Viganò]

Il 15/04/2012 18:44, ADB ha scritto:
> Nicola, posso condividere il fatto che sul risparmio energetico non ci
> siamo ancora e quindi, specialmente sui portatili con schede Nvidia è
> caldamente consigliato usare i closed per non ritrovarsi dopo
> un'oretta con le batterie "drenate",
> Ma per chi ha un fisso con un scheda nvidia gli open hanno raggiunto
> performace3D discrete, anche se il discorso  "ottimizzazione risparmio
> energetico rimane una chimera ma spero migliorerà.
> POi, sulla mia 9800 gt con gli open non ho MAI avuto una rogna con
> cambio di Kernel, aggionementi etc etc mentre con gli Open è un
> CALVARIO.
> Questo forse è segno di stabilità?
> Mah, per quanto mi riguarda gli Open Nvidia Sono sempre andati bene
> (sul mio PC) e gli ultimi migliramenti di performance anche in treddì
> mi riempiono di gioia e mi fanno pensare che i manutentori del codice
> "reversato" stanno facendo un buin lavoro.  In sostanza sono Ottimista
> e speranzoso, ma anche cosciente che specialmente su un
> reverse-engeneering è dura ottimizzare il codice.
Mh allora forse dobbiamo distinguere un attimo gli argomenti.

Sul fatto di aggiornamenti e compagnia bella, ricordiamoci che i rilasci
dei driver open vengono fatti in modo coordinato fra tutti gli attori
(kernel, mesa, Xorg etc) in modo che con configurazioni normali non vi
siano breakage.
Chi sviluppa i driver closed non può far esattamente la stessa cosa.

Se non sbaglio poi, tu usi Arch, che ha una politica alquanto aggressiva
sugli aggiornamenti, quindi finisce ovviamente per rompere i driver
closed. Con gentoo questo non avviene mai (ho i driver closed AMD da una
vita e non ho di questi problemi)

Per quanto riguarda le performance, anche qui bisogna intendersi.
Un driver video è un piccolo ecosistema, quindi non è nemmeno facile
fare stime a pollice, se non si conoscono bene i parametri di
riferimento da guardare.

Prima di tutto mi sembra di vedere da questi benchmark che Pietro ha
linkato, che le performance di Nouveau si avvicinano a quelle del driver
closed solo con le schede più vecchie e meno performanti.
Da questo mi sembra di poter dedurre che le performance sono simili
quando il fattore limitante è la CPU. Ma allora questo significa che il
driver non ha grandi meriti.
Non è un caso infatti, che non via sia un vero e proprio scaling delle
performance del driver, con lo scaling delle performance della GPU (cosa
che invece avviene con i driver closed).

Poi c'è il discorso del reverse engineering. Non tutto il driver è fatto
di roba che va reversata. Di solito, che devono esser reversate, son le
cose di più basso livello, quelle relative a quali registri (speciali)
ci sono ed a cosa servono, ed in particolare il mode-setting.

Per quanto riguarda le performance si usano i registri general purpose,
e quelli non ci vuole molto a scoprirli. Per di più si conosce già quali
sono le caratteristiche a livello tecnico dell'architettura hardware
(ISA: instruction set architecture, cache e palle varie). La menata in
questo caso è riuscir a scriver il backend del compilatore degli shader
in modo che possa emettere del codice shader efficiente.

Certo, io ora l'ho fatta più semplice di come sia veramente, ma le
performance, a meno di vere e proprie mancanze nella conoscenza
dell'architettura hw, dipendono da caratteristiche implementative che
non hanno quasi nulla a che vedere con il reverse engineering.

Ad esempio, una volta che sai quali siano le dimensioni del Tiling delle
texture in quel determinato HW, il pacco rimane solo implementarlo (ed
in modo che sia robusto/stabile/accurato)!

È per questo che, citando forse Bridgman, dicevo che LLVM è l'arma
giusta da utilizzare per ottenere con poco sforzo un compilatore degli
shader che faccia il suo dovere ed abbia performance ragionevoli. Sai
quanto è facile in LLVM creare un nuovo backend (subottimale) per una
nuova architettura?

Il problema è che non c'è solo quello, e come dicevo un driver video è
come un piccolo ecosistema. Basta una falla in un punto dello stack, e
tutto implode.