Driver Catalyst per Windows 64bit

[Ikitt_Claw]

Originariamente inviato da cdimauro
Cosa?

So troppo poco degli internals di linux (e del processo di scrittura di driver in generale) per portare un'obiezione precisa.
Della situazione in windows non so nulla, per cui per ora non posso che darti ragione, fermo restando appunto che alcune cose non mi convincono.

[Ikitt_Claw]

Originariamente inviato da ^TiGeRShArK^
se hai bisogno di driver performanti devi NECESSARIAMENTE scrivere le parti critiche in linguaggio makkina....

Uhm... Esempio di parte critica?

e poi non te ne sei accorto usando linux???

Anche i device driver, in generale, sotto linux sono in C anziche` in ASM (e vorrei ben vedere...) eppure non mi pare affatto che le prestazioni ne risentano.

mi vuoi dire ke i driver video in linux sono scritti interamente in c e hanno le stesse prestazioni dei driver ottimizzati in linguaggio makkina???

Premesso che un driver video, specie con la complessita` delle schede video attuali, sara comunque scritto per la maggior parte in un linguaggio a piu` alto livello dell'assembly, sarebbe salutare un confronto, ma non conosco schede con driver che possano essere adatte allo scopo.

X me è QUI ke c'è qualcosa ke non mi convince nel tuo ragionamento...

Ci vorrebbe qualche numero per dirimere un bel po` di dubbi.
Queste famose "ottimizzazioni" dei driver sono fumose e vaghe come concetti (o mi son perso qualcosa io?)
Nella scena linux, e la cito perche` il sorgente e` a portata di mano, mica per altro, mi pare proprio che un'ottimizzazione del driver raramente si conretizzi nell'uso dell'ASM, men che mai in una riscrittura.

[Immortal]

ma non mi risp nessuno?

[cdimauro]

Originariamente inviato da Ikitt_Claw
So troppo poco degli internals di linux (e del processo di scrittura di driver in generale) per portare un'obiezione precisa.
Della situazione in windows non so nulla, per cui per ora non posso che darti ragione, fermo restando appunto che alcune cose non mi convincono.

Per quanto riguarda i driver possiamo parlare in generale, perché è una questione che riguarda un qualunque s.o.
E' pacifico che un'applicazione che richiede un particolare servizio, finisca per richiamare un driver per il suo espletamento. Succede con le API grafiche ma, per prendere un esempio completamente diverso, può succedere per implementare via software il RAID 0 (banale "fusione" di due hd per simularne uno più grande) o RAID 0+1 (non ricordo di preciso la sigla), che esegue la stessa operazione, ma con 3 HD, di cui uno contiene lo XOR degli altri due (quindi c'è più lavoro da fare).
Ora, è chiaro che se un driver si occupa di qualcosa per cui riceve un enorme carico di lavoro, più velocemente lo porta a compimento, meglio si comporta globalmente il sistema. Quindi si ha interesse a fargli perdere quanto meno tempo possibile.
A questo punto la differenza la fa il linguaggio: in C, per quanto buono possa essere il back-end del compilatore, il codice risulterà più lento di uno scritto in assembly da una persona competente. Codice più lento -> prestazioni inferiori.

Se il problema che hai sollevato sta nella percezione delle differenze, è chiaro che bisogna effettuare dei test: magari qualche decina di frame al secondo in più o in meno con un gioco come Quake non si possono apprezzare, dato l'elevato numero di essi che viene generato normalmente. Potrebbe essere maggiormente apprezzabile nel caso di giochi di nuova generazione, che utilizzano DirectX 8 o superiori (oppure ABR OpenGL equivalenti), per cui richiamare una funzionalità, per il driver equivale a programmare opportunamente i registri della GPU e/o trasferire informazioni tramite il bus AGP. O ancora, nel caso del RAID (0 oppure 0+1), sarà il maggior o il minor tempo impiegato nel caso del trasferimento di file ad essere "percepibile".
E' chiaro che, poi, le prestazioni possono essere comunque elevate, anche usando esclusivamente il C, per cui si può accontentare.

Quanto ai driver, è vero che in generale la maggior parte di essi sono scritti in C: non avrebbe senso utilizzare l'assembly per ogni loro parte. Soltanto le parti critiche, che svolgono un lavoro che incide particolarmente nelle prestazioni, sono passibili di eventuale scrittura in assembly.

Infine, le ottimizzazione non sono "fumose": il problema del miglioramento delle prestazioni del codice non riguarda esclusivamente il settore dei driver, ma qualunque software. Se ancora oggi un engine grafico utilizza l'assembly per le cosidette parti critiche, un motivo ci sarà.
Allo stesso modo, è possibile ottimizzare le parti di un driver che si ritiene possano apportare benefici.
Stiamo parlando si software: la differenza fra i due ambiti non comporta una distinzione delle cose.

x Immortal: esistono delle apposite sezioni in questo forum.

[ErPazzo74]

Il problema dei driver ottimizzati o no, sinceramente mi fa' 1 po' ridere. Cioe' se voi commercializzate una periferica sarebbe (secondo me) meglio prima uscire con dei driver in C, poi magari ottimizzarli man mano.
Per esempio i driver delle videocamere DragonFly erano lentissimi negli algoritmi x la ricostruzione delle immagini (occupazione di CPU al 100% con l'algo + pesante) alla versione successiva si passo' al 25% della CPU. Beh all'inizio era poco serio che una telecamerica da 2500 euro avesse dei driver lenti ma poco dopo (qualche mese) erano ben ottimizzati.
Aggiungo che io preferisco driver stabili a driver veloci ma con dei bug importanti.
Non metto in dubbio ovviamente che ottimizzare in assembly (come mi e' capitato di fare) direttamente sia + efficiente del codice in C anche se ben compilato. Ma mi ripeto non credo che ci sia questa estrema ricercatezza delle prestazione nei driver attuali delle periferiche.
Lo scetticismo e' dovuto al fatto visto quanto sono potenti i nostri computer sembrano pur sempre dei pachidermi rispetto ai tempi del C64.
Ciao Ciao

[cdimauro]

Beh, mi sembra normale che quando si sviluppa un driver (o qualunque altro programma), prima si utilizzi un linguaggio ad alto livello, e poi eventualmente se ne riscrivono le parti critiche in assembly.
Quest'ultimo è un percorso che, come ho già scritto, viene intrapreso se se ne evidenzia la necessità. E questo a prescindere dalla potenza disponibile per i nostri computer, perché:
1) la "massa" non ha disponibile il miglior hardware
2) l'aggiornamento è un'operazione che non viene eseguita spesso, anzi!
3) la potenza aumenta, ma iù vengono presentate applicazioni sempre più complesse e pesanti.

D'altra parte, ripeto, non è che si debba ottimizzare TUTTO il codice: solo per una piccola parte dev'essere fatto...

[dragunov]

sotto leggera pressione di bill credo!