Newsgroup: it.comp.os.dibattiti
Titolo: Velocita' della grafica: X e NT

Xwindows contro Windows NT, ancora piu' velocizzato nella grafica
passando dalla versione 3.x alla versione 4.x, da quando hanno portato
le chiamate alla grafica da livello ambiente a livello executive, pur
aprendo una maggiore possibilita' di instabilita' o crash.
A me sembra nettamente superiore NT, e a voi?
E' meglio usare un cad o applicazioni di animazione su X o su NT?
Qualcuno sa come influenzano la velocita' le estensioni dga dei servers
grafici o altre cose affini in un certo senso alle directx di microsoft,
o l'uso di shared libraries specifiche per l'uso di schede 3d o 3dfx? In
generale, come pensano di risolvere i limiti in modo da rendere piu'
competitivo X in tutti gli aspetti relativi all'utilizzo avanzato della
grafica?
bye G.L.
--
  Antispamming: metti "sole" in luogo di "maps"
  Antispamming: replace "maps" with "sole"
--

 grafica?
Se parli di linux e xfree ti do ragione e il problema e' da risolvere.
Adesso la sgi si sta buttando dentro quindi ne vedremo dele belle.
Ciao ... Dino

 Su linux praticamente non ce ne sono o cmq sono difficili da reperire.
Su linux ho letto qualche post in merito e qualche applicazioncina ci dovrebbe
essere. Il superbo Cad Bentley MicroStation e' nato su solaris/sunos e poi
portato su altre piattaforme.


 Idem. Ma considerando xfree.
Aggiundo: visto che entrambi i sistemi hanno base client-server, mi chiedo se
e' piu' rapido, teoricamente e praticamente, il modello client-server di winNT
col suo protocollo proprietario ed i suoi sottosistemi di ambiente oppure il
modello client server di X basato sul tcp/ip, lasciando perdere  i display in
rete ma considerando solo le connessioni tcp/ip in loopback, vale a dire
client e server sulla stessa macchina.
bye G.L.

 
Se sei nella stessa macchina (e quindi in genere la variabile DISPLAY
e' settata a ":0.0") tutti i server X moderni (anche Xfree) non usano
tcp/ip in loopback ma memoria condivisa (che e' molto piu' veloce)
Ciao
-- 
Mario Giammarco 
giam...@cs.unibo.it
mgiam...@racine.ra.it
 
mgiam...@libero.it
Via Calamandrei, 5 -48022 Lugo (RA) 0545/22965-ITALY

 tcp/ip in loopback ma memoria condivisa (che e' molto piu' veloce)
E difatti mi chiedevo perche' in sco open server host system funziona l'X senza
avere configurata in rete nessuna interfaccia e tantomeno l'interfaccia loopback...


 bye G.L.
Perché forse le cose che avevi scritto prima le avevi lette in un libro
stampato nell'anno del signore 1975 :))
-- 
Ciao ....
           Massimiliano ADAMO
         E-mail: 
maxa...@tin.it
http://web.tiscalinet.it/maxadamo/index.htm

 stampato nell'anno del signore 1975 :))
Sarcasmo a parte, un po' piu' tardi... (1982-1985). E' comunque molto probabile, dal
momento che ho studiato i principi del client-server in tcp/ip ma non specificatamente
del protocollo su cui e' basato X.
Adesso pero' sarebbe interessante sapere se esistono dei benchmarks che consentono di
valutare le prestazioni dei due sistemi (X e NT). Forse (intendiamoci, non sono esperto
di cad), ad esempio, valutando a parita'di hardware le prestazioni di bentley
microstation su X e poi su NT...
bye G.L.

 a dire client e server sulla stessa macchina.
Se non sbaglio X non richiede necessariamente tcp ma solo un generico
protocollo ipc. E corretto? Per cui non sarebbe proprio necessario
affidarsi a connessioni tcp in loopback.
--
Fabrizio Di Giuseppe
Real email address: fabrizio@_REMOVEME_iride.com
http://www.iride.com/fabrizio
Sent via Deja.com 
http://www.deja.com/
Before you buy.


Non lo so... ma finora ho visto che tutti i protocolli ad alto livello
sono incapsulati in datagrammi udp o tcp (transport layer), i quali a
loro volta sono incapsulati in pacchetti ip (link layer, + o -
incapsulati, da cui tcp/ip per denominare correttamente il protocollo di
internet). E so che il server X utilizza in ascolto una (o piu'?)
determinata porta di protocollo tcp. Quindi non ti so dire a quale
livello venga trasportato ipc. In /etc/services non ho trovato nulla. Mi
hanno comunque risposto negli altri post che viene usata memoria
condivisa nelle connessioni locali, per cui $DISPLAY non e'
necessariamente 127.0.0.1:0.0 o localhost:0.0, ma semplicemente :0.0.
Come si comporti poi il SO per le applicazioni client quando aprono dei
sockets per connettersi ad un Xserver locale, perche' venga utilizzata
shared memory, e come invece si comporta per i client che si connettono
ad un Xserver remoto, e' un meccanismo di cui spero qualcuno ci renda
piu' edotti, sebbene OT o parzialmente OT. La shared memory in locale e'
poi utilizzata solo per i client X od in generale per tutti i client
tcp/ip di qualunque natura?


necessariamente 127.0.0.1:0.0 o localhost:0.0, ma semplicemente :0.0.
:0.0 significa solo che il client si colleghera` al server tramite un
socket unix domain piuttosto che uno TCP. X11 non usa UDP.
La shared memory e` usata solo da alcuni tipi di client, per esempio i
giochi, che necessitano di molta banda.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | "You're one of those condescending Unix computer users!"
      | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

 giochi, che necessitano di molta banda.
Cioe', e' il client case-sensitive? Decide il client il tipo si socket da
aprire sulla base del contenuto di $DISPLAY, ed e' lui che richiede l'utilizzo
dello memoria condivisa? Che poi il service di X non usasse udp, ma solo il
tcp mi sembra sulla porta 6000, gia' lo sapevo, solo una parte dei services
vengono "duplicati" su udp. Poi volevo continuare il thread riproponendo la
domanda: la grafica su NT e' una componente indispensabile ed integrata
dell'interfaccia, mentre in unix no. Che differenze prestazionali, se
quantificabili, si potrebbero avere?


quantificabili, si potrebbero avere?
Nella pratica, X e` comunque sufficientemente veloce.


affidarsi a connessioni tcp in loopback.
Confermo che e' quanto ricordo anche io.
Bisognerebbe chiedere a Marco per sicurezza... :)
Saluti.

Nella pratica, X e` comunque sufficientemente veloce.
Be si se devi solo far girare netscape si. Come ho già detto in un
altro post (xfree nel kernel) molta gente tra cui gli ingegneri che
lavorano alla NVIDIA sostengono che meglio avere il server grafico a
ring0 come in NT. Con tutto ripetto per Marco, che giudico una persona
molto competente quando si parla di networking, per quanto riguarda la
grafica credo maggiormente alla gente che lavora in NVIDIA. Le
diffrenze le noti con applicazioni grafiche spinte come CAD e Giochi.
Una nota sul cad molta gente lavora su cad 2d per il quale una
qualsiasi scheda da 50KLire è + che sufficiente

 ring0 come in NT.
E' certamente come dici.
NT 3.51 aveva il sottosistema grafico (stabilissimo) a ring3, con la 4.0
hanno compiuto il grande passo proprio perchè NT, nei piani di Microsoft,
tendeva già allora (1995) a diventare la loro piattaforma principale (se non
l'unica), quindi le prestazioni grafiche erano importanti.
La 3.51 era un buon server, e basta.
Saluti performanti

ring0 come in NT. Con tutto ripetto per Marco, che giudico una persona
Da quando la gente di NVIDIA e` una autorita` in fatto di X server?
Finche` non proveranno le loro affermazioni con dei dati per quanto mi
riguarda scrivono cazzate come gli altri.


 quantificabili, si potrebbero avere?
Mi dispiace dovere un'altra volta esprimere un parere molto crudo, ma
avere la grafica a ring 0 e' una grossa cazzata. Ovvio che si guadagna 
in prestazioni ma si perde in stabilita': un bug nel driver della
scheda grafica puo' compromettere l'instabilita' del kernel. E che non 
mi facciano ridere alla Microsoft con l'idea dei driver "certificati"; 
cosa vuol dire "certificato", che _sicuramente_ non ha bug? 
E' per quello che sono stati inventati i microkernel, meno cose metti
a ring 0 piu' stabile e' il sistema. NT all'inizio era cosi', poi
tutti dissero che era lento, allora Microsoft corse ai ripari, non
ottimizzando il codice ma mettendo tutta la grafica a ring 0 che si fa 
prima. Ecco perche' mi fa schifo NT, perche' e' "marketing
driven". Prima vanno di moda il microkernel e la sicurezza? Oh, NT e'
microkernel con addirittura l'HAL. Ed e' certificato C2. Poi la gente
vuole la grafica veloce e i giochi? Oh beh, mettiamo tutto nel
kernel. Non e' piu' micro? Fa niente tanto non va piu' di moda! E la
sicurezza con le DirectX? Beh, tanto la certificazione C2 valeva solo
per uso stand-alone...
Morale della favola: per avere la grafica veloce bisogna avere
inanzitutto del codice grafico ottimizzato, poi (altrettanto
importante) un canale di comunicazione veloce fra programma che fa
richieste grafiche(client)->codice che le esegue(server) ->sist.operativo+hardware.
E si puo' fare senza mettere tutto nel kernel.


 E si puo' fare senza mettere tutto nel kernel.
Ma se si ottimizza e si mette nel kernel viene più veloce.
saluti a ring0

 grafica credo maggiormente alla gente che lavora in NVIDIA. Le
Vedi mio post precedente, in piu' aggiungo: se vuoi avere una grafica
ancora piu' veloce allora puoi saltare il sistema operativo e andare
direttamente sull'hardware, addirittura fai a meno del sistema
operativo ("working on the metal" si diceva una volta). Non c'e'
qualche cosa di sbagliato in tutto questo ragionamento? Tanto per far
capire che non sono di parte, X che cosa fa? Per girare il server
richiede i privilegi di root. Perche'? Cosi' puo' accedere
direttamente alla memoria della scheda video senza dover dire niente
al kernel. Nonostante questo e' una soluzione piu' stabile di NT
perche' almeno il server X e' un processo. Se si inchioda lo puoi
killare e far ripartire, se c'e' un bug che fa si che un puntatore
impazzito scriva a caso in memoria gli altri processi e il kernel sono 
comunque protetti in scrittura e quindi al massimo fa del danno a se stesso.


 al kernel.
Vuoi dire che accede alle risorse hw in user mode, sia pure coi privilegi di
root?
Saluti introflessi

root?
Certo.
Tutto quello che non sta nel kernel gira in user mode (strano, eh... :-) ).


 Tutto quello che non sta nel kernel gira in user mode (strano, eh...
:-) ).
Strano per nulla, strano che un processo che gira in user mode possa
accedere all'hw; se non mi sbaglio linux si puņ configurare in modo che un
processo utente non possa accedere alle risorse hw, in tal caso X non
girerebbe?
Saluti dubbiosi


X gira perche` essendo root puo` scrivere in /dev/mem /dev/port ecc
Bello eh?
Sotto NT avrei dovuto avere un VXD a ring 0 per fare la stessa cosa...
Morale: l'approcio *nix e` *elegante* e *sicuro*.
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(per rispondere via email fai un rot13 dell'indirizzo)
(apply a rot13 to reply)

accedere all'hw; se non mi sbaglio linux si puņ configurare in modo che un
Non se gira come root.


 Non se gira come root.
Quindi vuoi dire che l'architettura di linux consente comunque l'accesso
diretto all'harware in user mode, se il processo ha i diritti di root?
Saluti hal

Probabilmente c'incastra poco ma...
kswapd e kflushd sono processi di root che girano in user mode?
Ciao	
	Antonio
-- 
"La disumanita' del computer sta nel fatto che,
una volta programmato e messo in funzione,
si comporta in maniera perfettamente onesta"
                                 Isaac Asimov

diretto all'harware in user mode, se il processo ha i diritti di root?
Certo. root puo` tutto, salvo limitazioni esplicite autoimposte.


kswapd e kflushd sono processi di root che girano in user mode?
No, sono kernel thread.


Sotto NT avrei dovuto avere un VXD a ring 0
I VXD non girano sotto NT.
(sotto NT) Esistono programmi non ufficiali per far accedere ad alcune
istruzioni privilegiate i programmi user. (vedi sito Papero, molto
nascosto pero').
Comunque se Linux permette a programmi in User mode di accedere
all'hardware, solo perche' sono root, allora per me Linux fa la cosa
sbagliata.
Dopo avere rotto le scatole per la grafica che gira in modo kernel su
NT, adesso vengo a scoprire che un programma root fatto male mi puo'
seccare l'intero PC? Bella roba, ma se puoi accedere all'harware fai
tutto.
Se faccio un programmino che altera l'RTC Linux me lo permette solo
perche' sono root? Contenti voi.
--
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

 perche' sono root? Contenti voi.
Scusa, ma se volessi modificare l'RTC come dovrei fare?
Usare un driver in kernel?
E chi lo installa, il driver, se non root?
Allora installare il driver od usare un programma come root e`
la stessa cosa, no?
bye,
--
  Piergiorgio Sartor

perche' sono root? Contenti voi.
Se sei root puoi spaccare il sistema in mille modi molto piu` semplici,
non ha senso cercare di limitarti in quelli complessi.


 perche' sono root? Contenti voi.
Scusa, ma se volessi modificare l'RTC come dovrei fare?








Piergiorgio Sartor <sar...@sony.de.REMOVE.THIS> wrote in message
38842219...@sony.de.REMOVE.THIS...
Wow, 5 copie, vedo che Netscape col tempo migliora ;-)
Ciao
Francesco


Sai com'e', volendo fare concorrenza a Outlook tenta di assimilare tutte le
caratteristiche del prodotto concorrente...
Ed anche in questo caso, evidentemente, e' risultato migliore.


 Ed anche in questo caso, evidentemente, e' risultato migliore.
Sti cazzi... strano pero' che non mi sia mai capitato. Magari e' colpa
della versione 4.5?
Ciao ... Dino

 Wow, 5 copie, vedo che Netscape col tempo migliora ;-)
In realta` e` il mio stupido newsserver, che ogni tanto
fa finta di non capire e rivuole 5 o 6 vlte lo stesso
post, salvo poi mandarli tutti... :-)
bye,
--
  Piergiorgio Sartor


No no no no no qui c'e' un errore. Se tu fai un girare un programma come
root questo rimane sempre un processo come gli altri, per accedere
direttamente alla memoria o all'hardware deve comunque fare delle
chiamate di sistema che il kernel gli permette perche' e' root. Se salta
un puntatore crolla solo il processo  e non il kernel. La grafica di NT
e' invece parte integrante del kernel quindi se c'e' un errore salta
tutto (kernel compreso)

 perche' sono root? Contenti voi.
E' per questo che hanno inventato il SUID. X Windows parte anche se lo
lancia un utente normale, ma dopo che il server e' partito il kernel lo
riconosce come quelli marcati SUID e quindi lo fa diventare root.

 Saluti hal
bye G.L.
--
  Antispamming: metti "sole" in luogo di "maps"
  Antispamming: replace "maps" with "sole"

 (si suppone che ci siano i drivers necessari).
Quindi, a quel che dici, mi sembra di capire che solo al kernel, e a ciň che
gira a livello kernel, ovvero i device drivers a ring0, sia possibile
accedere all'hardware attraverso i consueti meccanismi di indirizzamento.
Quindi, nel caso di X, č corretto affermare (come d'altronde dovrebbe
essere) che gira completamente in user mode al di fuori del kernel, ed ogni
accesso alla scheda video comporta un passaggio ring3<->ring0.
E questo giustificherebbe la sua robustezza e le sue prestazioni.
Saluti usermode

 Saluti usermode
Si, non conosco approfonditamente la materia degli X servers, ma ho notato
qualcosa che mi fa supporre/dedurre determinate cose:
1) Innanzitutto non mi sembra che ci siano driver che interessano la grafica di
specifici chipsets nel kernel, questo sia per linux che per unix. Forse, posso
dire fesserie, i framebuffers interessano qualcosa per il controllo del video,
ma dev'essere un'altro discorso.
2) Ogni X-server e' specifico per un certo insieme di chipsets, e non disponendo
il kernel di drivers specifici deve pilotare in qualche modo il device: come fa
a ring 3 e con modalita' di indirizzamento non reale e protetta, non potendo
accedere ai registri di i/o e alla memoria video?
3) Esistono dei device in /dev (/dev/mem, /dev/kmem, /dev/rom?) che sono
accessibili solo da root, attraverso i quali suppongo che si possa manipolare
memoria ram/rom e registri mappati nello spazio di indirizzamento, oppure
suppongo determinati device che riguardano semplicemente solo lo spazio di
indirizzamento di ram rom/ i/o comune a tutte le schede video.
4) Attraverso questi, ma appunto solo con i diritti di root (eseguibile suidato
con "s" per gli utenti normali) suppongo che il server X possa manipolare il
chipset di qualunque tipo di scheda prevista, senza necessitare di un
particolare driver del kernel.
5) Se e' cosi', allora l'X server e' secondo me anche piu' rapido ed efficiente
rispetto ad un modello che faccia utilizzo di un driver nel kernel col relativo
file device, dato che pilota il chipset quasi direttamente, tramite una
"finestra" allo spazio di indirizzamento della memoria e dei registri di i/o.
Nt, si dice, e' un po' piu' efficiente solo perche' la grafica gira a ring 0
sull'executive anziche' a ring 3 sul livello dei sistemi soprastanti
l'executive, con tutti i rischi che i bugs possono comportare (intendiamoci,
secondo me anche un X server che pilota male la scheda grafica a ring 3 puo' in
casi estremi portare indirettamente ad un blocco del sistema, per essere sicuro
di quel che dico ho telnettato... ed era morto, ma e' sempre una soluzione piu'
stabile e sicura)
6) Ho pero' un dubbio su tutto cio' che ho detto: sarei curioso di sapere a
grandi linee che intervento ha il kernel nella gestione del video senza avere
drivers specifici, specialmene per cio' che riguarda la multiscreen,  la
gestione della memoria video e degli screen con Xservers attivi e con programmi
attivi che usano grafica con le librerie svga.
7) potrei aver detto in parte o del tutto fesserie... i piu' esperti
intervengano.


 casi estremi portare indirettamente ad un blocco del sistema
Anche in user mode, il codice eseguibile che abbia diritti di accesso
all'hardware, può mandare in palla, per esempio, il bus PCI.
Cosa che accadeva coi primi driver matrox millennium per NT4, in alcuni casi
(rari per la verità): per spremere fino all'ultimo megapixel/sec, il driver
malmenava il pci a tal punto che la coesistenza con altre periferiche
diventava problematica.
Saluti educati

 Saluti educati
A risentirci, G.L.


 trattati in modo "grezzo".
Giusto, qui non ci piove.
A questo punto, la differenza sarebbe che le funzioni avanzate dell'hardware
(3d, opengl) vengono gestite dal driver a ring3, e solo attraverso il device
file si comunica con l'hw, a questo punto con un salto di stato.
Mentre sotto NT4, sia il driver che il sottosistema grafico fanno parte del
kernel; un errore qualunque del driver può impallare tutto il sistema, ma
tutta la grafica gira senza salti di stato.
Saluti dubbiosi

 E si puo' fare senza mettere tutto nel kernel.
Ancora pienamente d'accordo. Non sono accettabili compromessi o trucchi per ottenere
prestazioni e snaturare in tal modo il sistema.
bye G.L.

 Saluti dubbiosi
Ricambio con tanta incertezza... bye G.L.


a giudicare dal numero pid, vengono attivati dopo init? E' l'unico modo di
far girare del codice a ring 0 piu' o meno come se fosse un processo? Sono
incorporati nel Kernel e attivati successivamente o vengono lanciati come
processi particolari thread-del-kernel?
ignorantamente G.L.

 al dos 2.0, pur essendo multiutente con 256k di ram e pochi mega di swap!
Beh, unix sco mi permetteva di usare tre terminali su un 286 con un mega di
ram, bello e compatto con qualche limite, è anche vero che faceva meno cose.
D'altronde il confine tra kernel mode e user mode si stabilisce (per ogni
s.o.) a seconda della stabilità del codice che dovrà girare nell'uno e
nell'altro contesto.
All'uscita di NT 4 la cosa lascio tutti (me compreso) a bocca amara, ma devo
anche dire che, una volta stabilizzata la situazione dei drivers, guai non
ce ne sono stati.
Saluti nostalgici

NT (le famose microsoft foundation class) è scarsa, microsoft non ha certo
<pedantic mode on>
Le MFC non sono le API di NT, sono robaccia ad alto livello che copre
altra robaccia a basso livello, le API appunto.
<pedantic mode off>
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(per rispondere via email fai un rot13 dell'indirizzo)
(apply a rot13 to reply)

processi particolari thread-del-kernel?
Nell'ordine: no, si, si.
