Link alla notizia: http://news.hwupgrade.it/12468.html

ATI rilascia una versione beta, sprovvista di supporto tecnico, dei propri driver Catalyst per schede video Radeon, adatti all'utilizzo con sistema operativo Windows XP a 64bit

Click sul link per visualizzare la notizia.

Certo... il sistema operativo di Microstroz debuttera' non appena INTEL gli dira': " DEBUTTA " :D

Originariamente inviato da Scezzy
Certo... il sistema operativo di Microstroz debuttera' non appena INTEL gli dira': " DEBUTTA " :D

non vedo come possa essere il contrario dato che Intel detiene gran parte del mercato...

A me è arrivata la versione di prova dalla microsoft, ho installato i driver Nvidia e sembra tutto ok.. anche se non ho trovato i driver per il modem conexant pci

Originariamente inviato da terrys3
non vedo come possa essere il contrario dato che Intel detiene gran parte del mercato...
Forse perché il 99.9% del mercato putroppo lo detiene micro$oft??? :muro:

Correggetemi se sbaglio esistono anche gli Hyperion a 64bit sul sito via giusto?
Eppoi mi pare che i driver nvidia x linux esistano anche a 64bit.
I 64Bit non li ha inventati microzozz e sara' solo l'ultima ad usarli, visto che contrariamente a quanto sostengono, sicuramente la microsoft non e' avanguardia, IMHO ovv.
Ciao

x terrys3: se fosse vero quanto affermi Intel sarebbe da denuncia penale per comportamento MONOPOLISTICO.
E tutto sommato non mi dispiacerebbe affatto :D

oppure più semplicemente microsoft aspetta che il più grande produttore, per volumi e fatturato, del mondo di cpu testi adeguatamente le nuove soluzioni. Sarebbe da stupidi fare il contrario.

E' la solita vecchia legge "non scritta" : IL più forte detta le regole........

Originariamente inviato da sslazio
x terrys3: se fosse vero quanto affermi Intel sarebbe da denuncia penale per comportamento MONOPOLISTICO.
E tutto sommato non mi dispiacerebbe affatto :D

scusa ma perchè non è vero quello che ho detto? Non credo che la mia fosse un'opinione personale, quanto un dato di fatto...
E' ovvio che se Intel controlla l'80% del mercato, Microsoft rilascerà Win64bit solo quando Intel introdurrà CPU a 64bit....

E' chiaro che Microsoft sia "costretta" ad attendere lo sviluppo dei 64bit. Io ho un athlon64 3200+ ed ho testato la versione beta di WindowxXp 64bit extended Edition. Sembra davvero ottima. Il problema è chiaramente la carenza di software ma soprattutto di drivers. Sarebbe un errore rilasciare un sistema operativo che non può funzionare se non con un minimo di periferiche. L'utenza a 64bit aspettava con ansia la release dei Catalyst-64bit, ed è un'ottima notizia, visto che Ati aveva dichiarato che non li avrebbe pubblicati prima della release finale dell'OS. Significa che il WinXp 64bit è maturo e presto sarà sul mercato. Io per primo lo spero.

Originariamente inviato da Lo ZiO NightFall
oppure più semplicemente microsoft aspetta che il più grande produttore, per volumi e fatturato, del mondo di cpu testi adeguatamente le nuove soluzioni. Sarebbe da stupidi fare il contrario.
Quoto, tranne il fatto che sarebbe da equi fare il contratio ;), ma si sa' che gli affari non son equi (e solidali) :(.

Aspetta, ma se è pronto perchè aspettare? così si danneggia un'altra ditta che spende $$$ in R&S.
Sarebbero solo copie vendute in più.

scusate, ma Windows 64bit supporta sia Opteron che Itanium?

Originariamente inviato da Opteranium
scusate, ma Windows 64bit supporta sia Opteron che Itanium?


no.Esistono due sistemi operativi M$ dedicati all'uno e all'altro e sono incompatibili.

Originariamente inviato da NemesisQ3A
E' chiaro che Microsoft sia "costretta" ad attendere lo sviluppo dei 64bit. Io ho un athlon64 3200+ ed ho testato la versione beta di WindowxXp 64bit extended Edition. Sembra davvero ottima. Il problema è chiaramente la carenza di software ma soprattutto di drivers. Sarebbe un errore rilasciare un sistema operativo che non può funzionare se non con un minimo di periferiche. L'utenza a 64bit aspettava con ansia la release dei Catalyst-64bit, ed è un'ottima notizia, visto che Ati aveva dichiarato che non li avrebbe pubblicati prima della release finale dell'OS. Significa che il WinXp 64bit è maturo e presto sarà sul mercato. Io per primo lo spero.
Guarda che x ricompilare i driver non ci vuole mica 1 anno? A - che abbiano programmato utilizzando assunzioni sulla dimensione dei dati e and, or o xor bit a bit. Cmq il codice a 32bit dovrebbe girare....quindi anche i vecchi driver.

Originariamente inviato da Opteranium
scusate, ma Windows 64bit supporta sia Opteron che Itanium?

Si tratta di due versioni distinte.
Windows XP 64Bit Edition. -> IA64 Intel (Itanium)
Windows Xp 64Bit Extended Edition -> x86_64 AMD (Athlon64/FX/Opteron)

Originariamente inviato da ErPazzo74
Guarda che x ricompilare i driver non ci vuole mica 1 anno? A - che abbiano programmato utilizzando assunzioni sulla dimensione dei dati e and, or o xor bit a bit. Cmq il codice a 32bit dovrebbe girare....quindi anche i vecchi driver.

Spiacente, ma non si parla di ricompilazione. I driver a 32bit non funzionano in nessun modo sui sistemi con sistema operativo a 64Bit. Ed il lavoro è lungo visto che occorre riscrivere completamente il driver per indirizzare i 64bit.

Drivers tutti nuovi quindi. E tempo di sviluppo lungo per le ditte.

A chi interessasse consiglio di fare una vistita su www.planetamd64.com per vedere ad oggi quali siano le periferiche supportate da questo sistema operativo.
(al massimo una 15 purtroppo :mc: )

Originariamente inviato da terrys3
scusa ma perchè non è vero quello che ho detto? Non credo che la mia fosse un'opinione personale, quanto un dato di fatto...
E' ovvio che se Intel controlla l'80% del mercato, Microsoft rilascerà Win64bit solo quando Intel introdurrà CPU a 64bit....

85% del mercato. Intel e Microzozz sono legati da 2 fili inidiretti. L'utente comune Non può concepire i nomi Pentium e Windows separati, perciò se Microzozz divorsia da intel o Intel da Microzzoz tutte e 2 ci perderebbero tantissimo e sarebbe la fine di 2 monopoli.

Originariamente inviato da KAISERWOOD
85% del mercato. Intel e Microzozz sono legati da 2 fili inidiretti. L'utente comune Non può concepire i nomi Pentium e Windows separati, perciò se Microzozz divorsia da intel o Intel da Microzzoz tutte e 2 ci perderebbero tantissimo e sarebbe la fine di 2 monopoli.

appunto - è quello che ho cercato di far capire prima ma, a quanto pare, la cosa è stata fraintesa da alcuni...

A me sti 64 bit fanno un po' paura.. ricordate quando uscì windows 95 (e successivi) gli enormi problemi derivanti dal fatto che parte del SO girava a 16 bit e parte a 32 ?
Ora sembra che abbiano risolto con 2000 e XP facendo dei sistemi operativi interamente a 32 bit, ma ce ne hanno messo di tempo...
SPero che non capiti la stssa cosa coi 64 bit o si ricomincia di nuovo con gli schermi blu ogni 2 ore -.-

Originariamente inviato da NemesisQ3A
Spiacente, ma non si parla di ricompilazione. I driver a 32bit non funzionano in nessun modo sui sistemi con sistema operativo a 64Bit. Ed il lavoro è lungo visto che occorre riscrivere completamente il driver per indirizzare i 64bit.

Drivers tutti nuovi quindi. E tempo di sviluppo lungo per le ditte.

A chi interessasse consiglio di fare una vistita su www.planetamd64.com per vedere ad oggi quali siano le periferiche supportate da questo sistema operativo.
(al massimo una 15 purtroppo :mc: )
Allora come mai linux funziona a 64Bit? Hanno riscritto tutti i moduli?
Penso che la microzozz avra' avuto esemplari 1 po' prima della comunita' OS?

Originariamente inviato da BigPincer
A me sti 64 bit fanno un po' paura.. ricordate quando uscì windows 95 (e successivi) gli enormi problemi derivanti dal fatto che parte del SO girava a 16 bit e parte a 32 ?
Ora sembra che abbiano risolto con 2000 e XP facendo dei sistemi operativi interamente a 32 bit, ma ce ne hanno messo di tempo...
SPero che non capiti la stssa cosa coi 64 bit o si ricomincia di nuovo con gli schermi blu ogni 2 ore -.-
Quello dipendeva dal fatto che era tutta una pezza e nn un OS vero e proprio, insomma un'accozaglia di roba....

I driver avendo gli stessi privilegi del kernel dell'xp, devono girare nella stessa modalità, non possono girare il kernel a 64 bit e i driver a 32 bit....
inoltre non è questione di compilare i driver, perchè i driver NON si compilano.
I driver sono forse l'unica cosa ke al giorno d'oggi viene scritta prevalentemente in linguaggio macchina ....
o meglio le ottimizzazioni che sono fatte sui driver in linguaggio macchina non hanno uguali rispetto alle ottimizzazioni fate su altri programmi generici.
Questo perchè è dai driver ke dipende l'efficienza di una periferica, anche scrivendo i driver completamente in c si perderebbe molto in prestazioni, in quanto il codice verrà generato secondo le scelte del compilatore, e non è detto ke queste scelte siano corrette x una determinata periferica, da qui la necessità di ottimizzare a mano i driver...

Ma bip bip bip ATI ... adesso che ho venduto la 9800pro per la 6800ultra mi fa uscire i driver per win64 ... Uff!!! :muro:

Originariamente inviato da ^TiGeRShArK^
...non è questione di compilare i driver, perchè i driver NON si compilano.
I driver sono forse l'unica cosa ke al giorno d'oggi viene scritta prevalentemente in linguaggio macchina ....

Esattamente...
Anche io ho venduto la 9600Pro per una Fx5900XT...
Proprio perchè ATI ha atteso fino ad oggi ha fare una release di driver completi.
Non voglio entrare nel merito della cosa, scegliere di aspettare la maturità e la commercializzazione del Sistema Operativo è una scelta lecita sotto ogni punto di vista, ma resta il fatto che una fetta di mercato, come me per esempio, ha preferito acquistare una scheda NVIDIA, che da tempo ha rilasciato versioni preliminari dei ForceWare, e vendere la ATI, solo per soddisfare il proprio spirito "pioneristico" nella corsa ai 64Bit. :)

Originariamente inviato da ^TiGeRShArK^
I driver avendo gli stessi privilegi del kernel dell'xp, devono girare nella stessa modalità, non possono girare il kernel a 64 bit e i driver a 32 bit....
inoltre non è questione di compilare i driver, perchè i driver NON si compilano.
I driver sono forse l'unica cosa ke al giorno d'oggi viene scritta prevalentemente in linguaggio macchina ....
o meglio le ottimizzazioni che sono fatte sui driver in linguaggio macchina non hanno uguali rispetto alle ottimizzazioni fate su altri programmi generici.
Questo perchè è dai driver ke dipende l'efficienza di una periferica, anche scrivendo i driver completamente in c si perderebbe molto in prestazioni, in quanto il codice verrà generato secondo le scelte del compilatore, e non è detto ke queste scelte siano corrette x una determinata periferica, da qui la necessità di ottimizzare a mano i driver...
Forse qualche anno fa' era cosi' oggi non credo, pure perche' ho letto personalmente il codice di alcune cosette in linux e non e' assembly.
La potenza ad oggi non manca e nn e' + il tempo del C64.
I fatti sono che Suse Linux x gli Opteron (e quindi non x giocare) e' pronto da 1 anno al- e la microzozz? Gli mancano i driver? Ma non era il difetto di Linux?
L'ho detto e lo ripeto il capitalismo rallenta l'evoluzione.
Ciao

ATI Catalyst Beta 1 AMD64 Driver Performance :

http://www.amdzone.com/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=26&page=1

ATI MOBILITY RADEON 9600/9700 Athlon 64 3000+, VIA K8T800 chipset, 512MB DDR33

3DMARK2003

64bit 1571
32bit 2440

Final Fantasy XI benchmark

64bit low Detail 2434
32bit low Datail 3681

64bit High Detail 3252
32bit High Detail 5598

Halo 1024x768

64bit 35.18fps
32bit 45.41fps

UT2004 Assault 1024x768

64bit 32fps
32bit 38fps

UT2004 Flyby 1024x768

64bit 76fps
32bit 80fps

Come vedete , il rilascio di XP 64 può avere un senso solo con driver stabili e soprattutto performanti....
Mi preme farvi capire che , oltre ai driver per schede grafiche , c'è da rendere disponibili( e in seguito ottimizzare) una marea di altri driver , per tutte le periferiche dell'universo PC-windows!

P.S. copia incolla dal mio post in un altra notizia

E' vero, il S.O. da solo non garantisce un bel niente! Per vedere le reali prestazioni del xp-64bit bisognera' aspettare che i drivers siano ottimizzati.
Che vergogna pero' che windows sia pappa e ciccia con Intel! Come ho detto in uno dei miei precedenti commenti, AMD e Linux hanno perso una grande opportunita'! Se ci fosse stata una versione Lindows-64bit o Red hat-64bit o magari perche' no, una versione Suse64bit per desktop, alla Microsoft oggi avrebbero tutti i drivers pronti! Mi sarebbe proprio piaciuto vedere fino a che punto Microsoft sarebbe stata in grado di ritardare il rilascio! Peccato. Vuol dire che ci tocchera' aspettare: si, aspettare che Intel si metta al passo con AMD!!! Come gira il mondo eh?!

To BigPincer:
per correttezza c'è da dire che i primi sistemi scritti interamente a 32 bit furono i Windows NT la cui prima versione era la 3.51, ma la prima degna di nota per diffusione la 4.0.

In effetti anche io ho un pò il timore che WinXP 64 EE sia un appezzottamento a 64 bit di Win XP. E quindi dire che: Win 95 : 32 = WinXP 64 EE : 64

Al contrario WinXP 64 è nativo sui 64 bit di Intel

Per la parte di codice scritta in C, ovviamente non c'è problema: basta ricompilare ed è tutto ok. Il problema è che le parti critiche dei driver vengono ancora scritti in assembly, e questo richiede un bel po' di tempo per adattare e ottimizzare questo codice alla nuova architettura.
Per quanto riguarda Linux, i problemi dovrebbero essere gli stessi: di tutte le periferiche supportate dalle versioni a 32 bit, non so quanto driver siano stati riscritti (o quanto meno "risistemati") per farli girare nel nuovo ambiete a 64 bit.

Originariamente inviato da ErPazzo74
Allora come mai linux funziona a 64Bit? Hanno riscritto tutti i moduli?


Piu` o meno... Linux da tempo gira anche su architetture a 64 bit, e il codice dipendente dalla macchina (e quindi anche dalla dimensione dei registri...) e` il piu` ridotto possibile, anche nei driver.

Originariamente inviato da ^TiGeRShArK^
Questo perchè è dai driver ke dipende l'efficienza di una periferica, anche scrivendo i driver completamente in c si perderebbe molto in prestazioni

Usando Linux non me ne sono mai accorto...

Originariamente inviato da xaviers2002
Red hat-64bit

C'e` da qualche mese (Fedora Core 1 e 2)

o magari perche' no, una versione Suse64bit per desktop

C'e` da quasi un'anno.

Era ora che ati rilasciasse sti driver. Però da quel che ho letto sono ancora molto acerbi. Meno male che si diceva che stava aspettando per farne una uscire una versione ottimizzata e con pochi bug. Invece se ne sono venuti fuori con una versione buggata come quella di nvida ma con 3 mesi di ritardo. VERGOGNA!

Originariamente inviato da Ikitt_Claw
Usando Linux non me ne sono mai accorto...
Dipende dai driver: certamente le parti critiche di un driver video, dato l'enorme carico di lavoro a cui sono soggette le chiamate, sarebbe bene realizzarle in assembly (possibilmente ottimizzato per ogni tipo di processore), piuttosto che lasciarle in C...

Originariamente inviato da cdimauro
certamente le parti critiche di un driver video, dato l'enorme carico di lavoro a cui sono soggette le chiamate, sarebbe bene realizzarle in assembly (possibilmente ottimizzato per ogni tipo di processore), piuttosto che lasciarle in C...

Registro la considerazione, ma ci sono un po` di cose che non mi convincono.

raga vedo ke lo vostra discussione è molto teorica e solo in poki parlavano di bench e di test...
ebbene io ho provato i driver e ho un problema ke è un po difficile da descrivere...avviando vari giochi mi accorgo ke li vedo "al rallentatore" ovvero le immagini scorrono molto + lentamente di quanto dovrebbero...ma non xke scattano ma proprio sono rallentate...ke è? come risolvo il problema?

ho un amd64 3200+, ati 9700, 2x512mb ddr pc3200, asus k8v deluxe

Originariamente inviato da Ikitt_Claw
Registro la considerazione, ma ci sono un po` di cose che non mi convincono.
Cosa?

infatti cosa nn ti è kiaro???cdimauro ha spiegato perfettamente quello ke intendevo...
se hai bisogno di driver performanti devi NECESSARIAMENTE scrivere le parti critiche in linguaggio makkina....
e poi non te ne sei accorto usando linux??? 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???
X me è QUI ke c'è qualcosa ke non mi convince nel tuo ragionamento...

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.

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.

ma non mi risp nessuno?

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.

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

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... ;)

sotto leggera pressione di bill credo!