I requisiti video di Windows Vista sempre più impegnativi

[fek]

Originariamente inviato da W4rfoX

Me la devo essere persa da qualche parte, perche' questo tu scrivi.

Disinformazione: il rendering finale offline non usa ne' OpenGL ne' Direct3D, ma la CPU nella stragrande maggioranza dei casi, per una questione di precisione.

In grassetto.

Quindi, se capisco bene:
Situazione di oggi:
D3D che non possono far girare due applicativi in uso esclusivo della GPU. OGL che hanno performance che per comodita' quantifichiamo con 1.

Situazione di domani:
D3D che possono far girare due applicativi in uso esclusivo della GPU.
OGL che sono wrappate su D3d per definizione e hanno performance di 1 - 50%. Oppure OGL in uso esclusivo della GPU ma solo in full screen.
Il problema e' che la vedi dal punto di vista del programmatore di giochi. Onestamente a parte la presunta (dico presunta perche' non ho elementi per giudicarla se non il fidarmi di quello che tu dici) migliore architettura del driver non vedo un reale vantaggio per tutte quelle applicazioni che fanno uso pesante di OGL in finestra (lasciamo da parte i giochi al momento).

Il vantaggio e' globale. Un problema che prima affliggeva tutte le applicazioni grafiche, ora ne affligge solo una parte. Dal punto di vista prestazionale non cambia nulla rispetto ad oggi usando implementazioni ottimizzate.

1 - 50% poi e' una stima quanto meno esagerata. Sono pronto a scommettere che quelle applicazioni sono talmente GPU bound che l'utente non noterebbe neppure la differenza. Previsione personale.

Infine, non e' necessario fidarti di quello che dico sull'architettura dei nuovi driver video, esistono alcuni articoli piuttosto autorevoli che la descrivono con molti dettagli, ad esempio su Beyond3D. D'altronde io non posso rilasciare alcuna informazione che non sia gia' di dominio pubblico su questi argomenti.

P.s. io nn ho mai espresso teorie complottistiche. Sicuramente in passato MS ha fatto scelte da un punto di vista tecnico discutibili.

Alla luce della necessita' di stabilita' e sicurezza del sistema, questa mi pare una decisione assolutamente ineccepibile dal punto di vista tecnico. Scrivere solo il codice indispensabile a livello kernel e' sicuramente il modo migliore per incrementare stabilita' e sicurezza: d'altronde il codice che non c'e' non puo' contenere bug. Questa mi sembra un fatto evidente che e' alla base di questa decisione.

[fek]

Originariamente inviato da W4rfoX

Peccato che due post piu' sotto scrivi: La GPU e' usata solo per il preview delle scene. Dimenticato apposta?
Ma lasciamo perdere, non e' questo il punto del contendere.

Non sto scrivendo il capitolo di un libro di rendering, quando li scrivo ho due settimane di tempo ed un manipolo di gente che mi fa le review per correggere ogni imprecisione.

Direi che il concetto che ho espresso e' piu' che chiaro, se pensi di contraddirlo solo andando a pescare i piccoli vizi di forma, possiamo anche smettere di discutere

E' un vantaggio che non percepisco se non per i programmatori di giochi. Non vedo il vantaggio dell'uso esclusivo della GPU da parte di piu' programmi (anche se ad ogni modo deve essere uno share di risorse per definizione, a meno che Microsoft non abbia trovato la moltiplicazione dei chip) .

Provo con uno schemino:

- oggi la GPU non puo' essere condivisa facilmente da piu' applicazioni
- domani si'

Se non trovi il vantaggio, beh, a questo punto non so cos'altro aggiungere.

Un peggioramento delle prestazioni OGL c'e' aggiungendo uno strato software in piu' (le D3D), che l'ordine di grandezza sia del 50% o del 20%, non ne vedo comunque il motivo, se non un "disinteresse" di Microsoft nei confronti di OGL. (e dico anche giustamente, loro hanno le loro librerie grafiche e il sistema operativo e' il loro).

Il motivo e' prettamente tecnico: diminuire la quantita' di codice in kernel mode per aumentare la sicurezza e stabilita' del sistema?

Hai mai programmato? Stabilita' e sicurezza sono sempre a scapito delle prestazioni, in questo caso Microsoft ha valutato che il decadimento prestazionale vale ampiamente l'incremento di stabilita' e sicurezza del sistema. Decisione tecnica ineccepibile.

Se tu ci vedi altri motivi, ma non sai dare spiegazioni tecniche a giustificarli, ricadiamo nel caso di ricerca affannosa di complotti al di la' di ogni spiegazione tecnica. E di fronte a questo comportamento nessuna spiegazione sara' sufficiente.

Io parlava del passato e non delle scelte a livello implementativo fatte per vista. Direi comunque che dopo qualche anno che fanno sistemi operativi, se ne sono finalmente accorti. Il problema e' che ne dovrebbero togliere altra di rumenta dal kernel per metterla in userspace, ma e' gia' un inizio.

Scrivi tu un kernel senza quella rumenta allora. Tutti bravi a parlare, vero?

[roby1483]

Originariamente inviato da fek

Non sara' possibile lanciare applicazioni che usino un'implementazione ottimizzata di OpenGL in contemporanea ad altre applicazioni grafiche (come la GUI).

Ciao fek, non ho ben capito come funziona quello che ho quotato quì sopra. Se io ad esempio ho un'implementazione ottimizzata di OGL per lavorare con Maya non posso utilizzare Maya e la GUI contemporaneamente? Forse la domanda è stupida ma questo punto non mi è affatto chiaro.
Grazie.

[samslaves]

Vi rimando a:

http://www.macitynet.it/macity/aA22226/index.shtml

cosi' apriamo un'altra bella parentesi su Areoglass. Leggete perche' e' interessante. Molto interessante...

[fek]

Originariamente inviato da roby1483

Ciao fek, non ho ben capito come funziona quello che ho quotato quì sopra. Se io ad esempio ho un'implementazione ottimizzata di OGL per lavorare con Maya non posso utilizzare Maya e la GUI contemporaneamente? Forse la domanda è stupida ma questo punto non mi è affatto chiaro.
Grazie.

La tua domanda non e' stupida e non ho una risposta precisa, perche' ancora non so come sara' implementata effettivamente questa sorta di cooperazione.

Fino ad oggi funziona piu' o meno cosi':

- un'applicazione grafica al momento del lancio si prende la GPU se questa e' libera
- se la GPU non e' libera esce
- se la GPU e' libera, l'applicazione continua il suo lavoro ed ogni applicazione che richiedera' la GPU da questo momento la trovera' occupata
- quando l'applicazione grafica esce, rilascia la GPU
- se l'applicazione grafica crasha quando usa la GPU in esclusiva, e' molto probabile che tutto il sistema si impalli

La situazione di oggi non e' affatto rosea, l'archiettura grafica di WinXP con varie librerie che cercano di cooperare e' poco elegante e molto poco stabile.

Da domani la situazione sara' differente, perche' la GPU sara' sempre occupata dall'interfaccia utente di Vista e dovra' lavorare in coopeazione. Un'applicazione D3D non avra' grossi problemi perche' non richiedera' piu' l'uso esclusivo della GPU, che e' gia' "bloccata" dall'interfaccia utente.

Ripeto che questo non e' un problema dello scegliere D3D o OpenGL come libreria di rendering, ma e' inerente alla scelta di usare la GPU per renderizzare la GUI.

Domani un'applicazione che non usi D3D dovra' richiedere l'uso esclusivo della GPU come avviene oggi e la trovera' occupata dalla GUI. La GUI dovra' implementare qualche sistema per cedere la GPU a quest'applicazione e riprendere il controllo al suo termine. Decisamente meglio di cio' che accade oggi.

Resta un punto da affrontare: meglio scegliere D3D o OpenGL per renderizzare la GUI? Piu' del 90% delle applicazioni grafiche di qualunque genere su Win32 (mi tengo stretto) usa D3D. A voi la risposta a questa domanda.

[fek]

Originariamente inviato da W4rfoX

Dovrei impressionarmi?

No, dovresti capire che su un forum si possono commettere imprecisioni che non invalidano il discorso. Di solito si cerca di controbattere i discorsi altrui con discorsi sensati, non andando a pescare eventuali imprecisioni.

O meglio, ci si attacca al secondo metodo quando non si e' in grado di portare avanti il primo.

Evidemente lo era per te' e non per me'. O pensi che tutti ragioniamo allo stesso identico modo?

Ho l'ingenuita' di pensare che tutti ragioniamo usando la logica e mettendo da parte le simpatie personali. Purtroppo questa si rivela sempre piu' spesso una mia grave ingenuita'.

Vediamo di capirci allora. Ad oggi piu' applicativi posso comunque utilizzare la stessa risorsa (ad esempio e' possibile lanciare Lightwave e Maya in contemporanea ed utilizzarli entrambi).

Quando non richiedono l'uso esclusivo, il driver OpenGL cerca di far cooperare le due applicazioni. Prova a lanciare Maya assieme ad un gioco D3D e nella migliore delle ipotesi esplode il sistema operativo.

E ne sono ben felice, ma non capisco perche' SOLO OGL ha un decadimento di prestazioni. Seguendo il tuo ragionamento tutto il comparto video avrebbe dovuto avere un decadimento di prestazioni.

Mi sembrava gia' chiaro: perche' nell'implementazione standard OGL sara' mappato sopra D3D (un'ulterire strato di indirezione). Tu pensa che oggi invece l'implementazione standard di OpenGL e' software ed usa la CPU, e NVIDIA e ATI installalo le loro versioni durante l'installazione dei driver.

Prova a non installare i driver della scheda video e lanciare un'applicazione OpenGL.

Sei tu che non mi dai una spiegazione tecnica del perche' SOLO OGL ha un decadimento di prestazioni, se non una scelta tecnico commerciale. Da un punto di vista tecnico, cosi' come D3D puo' avere il massimo delle prestazioni, anche OGL potrebbe, senza essere wrappata su 3D3, e rimanere in userspace senza problemi, l'unico motivo e' il non interesse di MS in Ogl, ma non vedo nessun complotto in questo, vedo solo il disinteresse di MS per queste librerie.

Ho perso il conto di quante volte ho dato quella spiegazione. Se la ignori, non e' piu' un problema mio.

Mi spieghi come un'implementazione OpenGL totalmente in user space puo' accedere all'hardware quando le porte hardware sono accedibili solo in ring 0? Qui mancano proprio le basi.

Ma la domanda che sorge spontanea e' .. ma tu che ne sai di quello che scrivo e faccio nella vita io?

Nulla. Giudico quello che scrivi.

[fek]

Originariamente inviato da W4rfoX

Ok, mastah... mi inchino alla sua conoscenza.

Non vedo il motivo di fare infantile ironia e metterla sul personale.

[roby1483]

Originariamente inviato da fek

La tua domanda non e' stupida e non ho una risposta precisa, perche' ancora non so come sara' implementata effettivamente questa sorta di cooperazione.

Fino ad oggi funziona piu' o meno cosi':

- un'applicazione grafica al momento del lancio si prende la GPU se questa e' libera
- se la GPU non e' libera esce
- se la GPU e' libera, l'applicazione continua il suo lavoro ed ogni applicazione che richiedera' la GPU da questo momento la trovera' occupata
- quando l'applicazione grafica esce, rilascia la GPU
- se l'applicazione grafica crasha quando usa la GPU in esclusiva, e' molto probabile che tutto il sistema si impalli

La situazione di oggi non e' affatto rosea, l'archiettura grafica di WinXP con varie librerie che cercano di cooperare e' poco elegante e molto poco stabile.

Da domani la situazione sara' differente, perche' la GPU sara' sempre occupata dall'interfaccia utente di Vista e dovra' lavorare in coopeazione. Un'applicazione D3D non avra' grossi problemi perche' non richiedera' piu' l'uso esclusivo della GPU, che e' gia' "bloccata" dall'interfaccia utente.

Ripeto che questo non e' un problema dello scegliere D3D o OpenGL come libreria di rendering, ma e' inerente alla scelta di usare la GPU per renderizzare la GUI.

Domani un'applicazione che non usi D3D dovra' richiedere l'uso esclusivo della GPU come avviene oggi e la trovera' occupata dalla GUI. La GUI dovra' implementare qualche sistema per cedere la GPU a quest'applicazione e riprendere il controllo al suo termine. Decisamente meglio di cio' che accade oggi.

Resta un punto da affrontare: meglio scegliere D3D o OpenGL per renderizzare la GUI? Piu' del 90% delle applicazioni grafiche di qualunque genere su Win32 (mi tengo stretto) usa D3D. A voi la risposta a questa domanda.

Grazie mille, quindi non rimane che aspettare maggiori dettagli per sapere come sarà implementata la faccenda.

[killer978]

Sempre la solità solfa, come esce un articolo su MS tutti a spalare merda Mi ricordo ancora quando uscii Win XP allora fu molto peggio, adesso lo usano tutti è ovvio che la tecnologia va avanti vojo vedere chi di voi x la fine dell'anno prox non avrà una VGA dx9 ed 2GB di RAM ma finiamola di dire stron.....
Byz io intanto aspetto questo Vista mi piacciono le novità qualunque esse siano e poi casomai dopo averlo provato dirò la mia

[fek]

Originariamente inviato da W4rfoX

Quello che non amo sono la supponenza e la saccenza, io non mi permetto di giudicare nessuno, ne per quello che e' ne per quello che scrive.

E allora perche' ti sei messo a fare il saccente andando alla ricerca dei vizi di forma ignorando il discorso generale? Si predica bene e si razzola male.
Chiudiamola qui va.

p.s. Non faccio il 3d programmer da 5 minuti.

[fek]

Originariamente inviato da W4rfoX

Infatti non ho mai messo in dubbio la tua competenza.
Tra l'altro il vizio di forma era su una cosa che esulava il discorso della scelta architetturale.

Problema risolto allora?

Abbracci e baci, la buttiamo a tarallucci e vino?

Mi e' piaciuta la tua frase sullo strumento di lavoro, e' quello che vado predicando da tempo: l'informatica e' una collezione di strumenti di lavoro per risolvere problemi.

[cdimauro]

Originariamente inviato da leoneazzurro

Dai, su, va bene la reazione, ma non eccedere neppure tu

Hai ragione: è che mi sono lasciato trascinare e ho esagerato UN POCHINO le cose... Scusatemi...

[^TiGeRShArK^]

Originariamente inviato da samslaves

Vi rimando a:

http://www.macitynet.it/macity/aA22226/index.shtml

cosi' apriamo un'altra bella parentesi su Areoglass. Leggete perche' e' interessante. Molto interessante...

.....ma hai almeno letto quello ke il povero fek sta cercando di dire da innumerevoli post???

[The Bear]

Vorrei solo rispondere ad un post nel quale si chiedeva se erano state implementate le icone vettoriali oppure no, in questa ultima beta di windows vista.

Purtroppo, non avendo la 9800 ora, non posso installarlo, ma cmq guardando screenshot e video vari mi sono accorto che, almeno per questa release, sono ancora delle semplici e caccolose icone in grafica bitmap.

Da cosa lo deduco? Se vedete lo screen di vista dove ci sono le icone in modalità anteprima, le vedete sgranate. C'è anche un video dove fanno vedere che le icone in anteprima, a grandezza variabile tramite uno slider, si sgranano da paura quando vanno ben oltre i 128/256 pixel di grandezza (se trovo il link lo posto, cmq qualsiasi utente con vista lo può verificare).

Se, con le prossime release, vista implementasse le icone vettoriali, dite che avranno un'estensione proprietaria oppure useranno il formato scalabile .svg?

Altra cosa: dite che oltre alle innovazioni grafiche (desktop con effetti 3d/frivolezze grafiche a carico della gpu), non c'è niente che vale la pena di testare delle nuove funzionalità grafiche/di interfaccia di vista?

Ho visto parecchi dettagli nelle finestre di esplora risorse, la cartella immagini con delle anteprime come dio comanda, lo strumento 'cerca' + completo, risorse del computer anche... Nessuno mi può fare una piccola panoramica?

Nessuno ha provato a usare reshacker con qualche dll di vista?
E i temi del desktop? Sono ancora .dll?

[fek]

Originariamente inviato da samslaves

Vi rimando a:

http://www.macitynet.it/macity/aA22226/index.shtml

cosi' apriamo un'altra bella parentesi su Areoglass. Leggete perche' e' interessante. Molto interessante...

Sarebbe molto interessante se... chi l'ha scritta avesse una pallida idea di cio' di cui sta cercando di parlare

[DevilsAdvocate]

Originariamente inviato da Mark75

Fregnacce 3d nel desktop? A che pro? Era l'unico momento dove la scheda video poteva riposare per non scaldare come un forno. Piuttosto mi sarebbe piaciuto avere un s.o. sicuro ...ma credo che neanche questa sarà la volta buona.

Invece potrebbe esserlo, da alcune foto circolate in rete pare ci sara' un sistema di gestione/installazione con ri-login per la password da amministratore (come
linux, con su,kdesu,gnomesu,gruppo wheel fa da almeno 5 anni). Questa feature
da sola migliorerebbe di svariati ordini di grandezza la sicurezza (nessuna
installazione senza la password di root...) e se ben implementata sarebbe un
bel colpo contro il diffondersi di svariati malware/trojan.

[DevilsAdvocate]

Originariamente inviato da W4rfoX

Peccato che due post piu' sotto scrivi: La GPU e' usata solo per il preview delle scene. Dimenticato apposta?
Ma lasciamo perdere, non e' questo il punto del contendere.


E' un vantaggio che non percepisco se non per i programmatori di giochi. Non vedo il vantaggio dell'uso esclusivo della GPU da parte di piu' programmi (anche se ad ogni modo deve essere uno share di risorse per definizione, a meno che Microsoft non abbia trovato la moltiplicazione dei chip) .
Un peggioramento delle prestazioni OGL c'e' aggiungendo uno strato software in piu' (le D3D), che l'ordine di grandezza sia del 50% o del 20%, non ne vedo comunque il motivo, se non un "disinteresse" di Microsoft nei confronti di OGL. (e dico anche giustamente, loro hanno le loro librerie grafiche e il sistema operativo e' il loro).


Io parlava del passato e non delle scelte a livello implementativo fatte per vista. Direi comunque che dopo qualche anno che fanno sistemi operativi, se ne sono finalmente accorti. Il problema e' che ne dovrebbero togliere altra di rumenta dal kernel per metterla in userspace, ma e' gia' un inizio.

Vista DOVRA' poter condividere la GPU tra piu' applicazioni, dato che una
delle applicazioni sara' proprio lo stesso sistema operativo. (L'utilita' del
desktop 3D e' dubbia anche a me, ma Fek sembra cosi' convinto che tanto
vale aspettare di vederlo prima di considerarlo solo un S.O. "giocattolo").
Il fatto che il 90% delle applicazioni professionali attuali di grafica 3d
usi preferenzialmente l'opengl (PER IL PREVIEW) non vuol dire che MS non
aiutera' il passaggio a direct3D, magari riuscendo ad "infilare" un po' di codice
suo nelle applicazioni di grafica professionale.
Il fatto che le applicazioni multipiattaforma (blender,wings3d tra tutte...)
avranno problemi a girare sotto Vista non e' un problema di MS stessa
(loro vendono un prodotto, se i professionisti della grafica non lo riterranno
all'altezza non lo compreranno....).Perdipiu' se troveranno un modo di bloccare
la corsa all'openoffice e all'open-source questo non fara' che renderli felici,ed
e' nel loro diritto di azienda privata.

[rocchellid]

OGL: parlano Carmack, Sekulic e Sweeney
Articolo Tom's hardware italia

[fek]

E comunque onestamente non riesco a vedere il vantaggio del lock da parte di una sola applicazione (Aero) della scheda video e l'eventuale possibilita' da parte di altri applicativi di prenderne il controllo. In qualche modo e' stato implementata una gestione dei lock e/o dello share della risorsa, quindi tecnicamente era possibile permettere a ogl di fare lo stesso. Per carita',hanno scelto questo approcio, e potevano farlo. Rimango scettico sui vantaggi, saro' tardo ma non li vedo.

Non e' un vantaggio o uno svantaggio il lock, e' una conseguenza. Tecnicamente era possibile supportare nativamente OpenGL, sarebbe stato necessario implementare piu' codice a livello kernel. Il vantaggio di non implementare piu' codice a livello kernel e' nella maggiore stabilita' e sicurezza, a discapito di una librerira usata dalla stragrande minoranza delle applicazioni grafiche.

E' una decisione tecnicamente ineccepibile.

Originariamente inviato da rocchellid

OGL: parlano Carmack, Sekulic e Sweeney
Articolo Tom's hardware italia

Non l'avevo letta. Bello che dicano esattamente quello che dico anch'io

[fek]

Originariamente inviato da W4rfoX

Mettiamola cosi'... ovviamente e' un puo parle', in quanti sicuramente ci sono degli svantaggi:
un layer di astrazione per il solo HW e D3d e OGl che si interfacciano con questo layer?
Un po' sullo stile DRI.
Il codice in kernel o che comunque gira a livello di kernel rimarrebbe il layer di astrazione. Il resto potrebbe girare in userspace.

E' quello che accade, il driver presenta un layer di astrazione minimale che e' mappato direttamente sulle D3D, per minimazzare l'overhead con questa libreria. Potrebbe presentare un secondo layer di astrazione mappato direttamente sulle chiamate OGL, ma significherebbe piu' codice in ring 0, con i problemi che ne derivano (quelli che si hanno oggi).

Potrebbero mappare OpenGL sull'HAL che e' mappato su D3D saltando un passaggio. Sarebbe una possibilita', ma WGF2.0 e' uno strato talmente sottile che non so questo quanto vantaggia prestazionale potrebbe dare a fronte di piu' codice. Immagino che avranno fatto dei test, ma qui siamo nel campo delle speculazioni.