Link alla notizia: http://www.hwupgrade.it/news/skvideo/radeon-hd-serie-4000-e-problemi-con-opencl_31167.html

Il non pieno supporto in hardware di alcune funzionalità OpenCL è alla base di prestazioni non all'altezza delle aspettative con schede Radeon HD della serie 4000

Click sul link per visualizzare la notizia.

Ma sto openCL è usato da qualche applicativo ora come ora?:confused:

Dai miei test con G92 su 9800 GT e DirectCompute Benchmark 0.35 (che supporta anche OpenCL come API) non ho visto problemi.....potreste pensare di adottarlo (quando magari sarà sufficientemente maturo) nelle recensioni (dico a voi, redattori di HWUpgrade :D).

Il driver OpenCL dovrebbe cmq passare per il driver CUDA (infatti basta confrontare la dimensione delle due librerie, la prima è 70 KB, la seconda quasi 4 MB) facendo una specie di tunneling/wrapping delle API, ma su questo devo informarmi bene: se fosse così quindi non ci sarabbero problemi di performance legate all'OpenCL su tutti i chip NVidia > G80.

Infine ricordiamoci anche questo: http://www.nvidia.com/object/cuda_opencl.html

In partnership with NVIDIA, OpenCL was submitted to Khronos by Apple in the summer of 2008 with the goal of forging a cross platform environment for GPU computing. NVIDIA chairs the OpenCL working group with direct support from NVIDIA’s SW engineering team.

mi sa tanto di discorso fatto solo per incitare tutti i clienti enthusiast che non sono passati ad hd5xxx a farlo, e spero vivamente che nessuno si faccia abbindolare da tutto questo, la mia 4850 non mi ha mai fatto notare questa pecca nella gestione dell'openCL e prima che openCL sia perfettamente radicato al punto da reputarsi uno standard di base, allora credo che saremo già passati alla hd6xxx e diremo che hd5xxx fa schifo...
cosa non si fa per vendere...

non è una novità, comunque sia è da un po' che seguo sia CUDA che OpenCL e resto molto interessato alla vicenda, anche se il primo è un boccone amaro per quello che riguarda la scrittura di codice seppur vi siano guide e esempi.

Chissà quando applicazioni ad hoc che non siano i convertitori video, arriveranno tra il pubblico permettendo un po a tutti di poter usare queste tecnologie e non solo sentirne parlare...

Che poi non si capisce perchè una scheda basata su rv770/rv790 dovrebbe avere problemi mentre una 5750/5770 no quando l'architettura praticamente è la medesima ed il chip pure :D
Mi sa tanto di mossa di marketing

mi sa tanto di discorso fatto solo per incitare tutti i clienti enthusiast che non sono passati ad hd5xxx a farlo, e spero vivamente che nessuno si faccia abbindolare da tutto questo, la mia 4850 non mi ha mai fatto notare questa pecca nella gestione dell'openCL e prima che openCL sia perfettamente radicato al punto da reputarsi uno standard di base, allora credo che saremo già passati alla hd6xxx e diremo che hd5xxx fa schifo...
cosa non si fa per vendere...

quoto per utenti come noi che cambiano spesso vga, ma altri tengono la scheda video per un paio d'anni e più...

Come faccio a testare la mia 4850 con le OpenCL?
Sia GPU Caps Viewer, sia DirectCompute Benchmark dicono che la mia GPU non è compatibile con le OpenCL...:boh:

Come faccio a testare la mia 4850 con le OpenCL?
Sia GPU Caps Viewer, sia DirectCompute Benchmark dicono che la mia GPU non è compatibile con le OpenCL...:boh:

allora non capisco quale possa essere la novità nell'apprendere che le open cl sono castrate sulle 4000. Se sono incompatibili dalla nascita amen... lo scoprono ora?

Il titolo della news non mi pare azzeccato, ma anche la news spiega poco dove sia effettivamente il problema, sembra + uno slogan contro ATI.

Su Tom's Hw spiegano dove sia principalmente il problema andate a leggervi quell'articolo che è di lunedi :asd:

http://www.tomshw.it/cont/news/le-radeon-hd-4000-non-digeriscono-opencl/23362/1.html

il problema è a livello hardware, forse sarà risolvibile con un paio di aggiornamenti

Il titolo della news non mi pare azzeccato, ma anche la news spiega poco dove sia effettivamente il problema, sembra + uno slogan contro ATI.

Su Tom's Hw spiegano dove sia principalmente il problema andate a leggervi quell'articolo che è di lunedi :asd:

http://www.tomshw.it/cont/news/le-radeon-hd-4000-non-digeriscono-opencl/23362/1.html

il problema è a livello hardware, forse sarà risolvibile con un paio di aggiornamenti

se è tale, non credo sia risolvibile con "aggiornamenti"....

qui ci vuole il mitico yossarian :D

Come faccio a testare la mia 4850 con le OpenCL?
Sia GPU Caps Viewer, sia DirectCompute Benchmark dicono che la mia GPU non è compatibile con le OpenCL...:boh:

Hai installato il catalyst 9.12 hotfix e ati stream sdk ?

Il titolo della news non mi pare azzeccato, ma anche la news spiega poco dove sia effettivamente il problema, sembra + uno slogan contro ATI.

Su Tom's Hw spiegano dove sia principalmente il problema andate a leggervi quell'articolo che è di lunedi :asd:

http://www.tomshw.it/cont/news/le-radeon-hd-4000-non-digeriscono-opencl/23362/1.html

il problema è a livello hardware, forse sarà risolvibile con un paio di aggiornamentiMeglio non commenti le news perchè poi verrei sicuramente ripreso ;-)
Chi più spende...

Cmq aggiungerei anche un bel chissene frega perchè, allo stato attuale, software opencl non ce ne sono e tra un paio d'anni difficile che qualcuno abbia ancora le ati serie 4000.
Ovviamente in casa amd non si concentreranno minimamente sul miglioramento delle prestazioni con rv770/790 per incentivare la vendita della serie 5000

la mia 4850 non mi ha mai fatto notare questa pecca nella gestione dell'openCL

ah sì? e che software hai scritto in OpenCL?

Che poi non si capisce perchè una scheda basata su rv770/rv790 dovrebbe avere problemi mentre una 5750/5770 no quando l'architettura praticamente è la medesima ed il chip pure :D
Mi sa tanto di mossa di marketing

non è vero. Parecchie cose sono cambiate a livello hardware, anche se sono solo ottimizzazioni erano in realtà indispensabili per la piena compatibilità ad OpenCL 1.0.
La feature principale che manca sulla serie HD4xxx è la memoria LOCALE che risponda alle specifiche OCL1.0, una sorta di cache velocissima per ciascun cluster di shader ma accessibile anche agli altri shader. Non essendo possibile questa cosa in queste schede, la memoria locale viene emulata dai driver nella RAM della GPU, che però è molto più lenta. Per questo motivo, programmi che sfruttano molto la memoria locale hanno prestazioni molto ridotte (pietose, direi) sulle schede HD4xxx.

Che poi, dico io, il fatto che giri openCL su queste schede "vecchie" è tutto grasso che cola (come si dice dalle mie parti)... Nessuno si lamenta che una scheda vecchia di un anno e mezzo non funzioni con le nuovissime DirectX 11, ad esempio... Qui è la stessa cosa, di grazia che anche se lentamente almeno giri!

ps: nvidia non ha di questi problemi perché i suoi chip, fin dal G80, hanno la memoria locale strutturata in modo compatibile con OpenCL 1.0. Bravi loro ad aver anticipato i tempi!

Ma chissenefrega.

ah sì? e che software hai scritto in OpenCL?



non è vero. Parecchie cose sono cambiate a livello hardware, anche se sono solo ottimizzazioni erano in realtà indispensabili per la piena compatibilità ad OpenCL 1.0.
La feature principale che manca sulla serie HD4xxx è la memoria LOCALE che risponda alle specifiche OCL1.0, una sorta di cache velocissima per ciascun cluster di shader ma accessibile anche agli altri shader. Non essendo possibile questa cosa in queste schede, la memoria locale viene emulata dai driver nella RAM della GPU, che però è molto più lenta. Per questo motivo, programmi che sfruttano molto la memoria locale hanno prestazioni molto ridotte (pietose, direi) sulle schede HD4xxx.

Che poi, dico io, il fatto che giri openCL su queste schede "vecchie" è tutto grasso che cola (come si dice dalle mie parti)... Nessuno si lamenta che una scheda vecchia di un anno e mezzo non funzioni con le nuovissime DirectX 11, ad esempio... Qui è la stessa cosa, di grazia che anche se lentamente almeno giri!

ps: nvidia non ha di questi problemi perché i suoi chip, fin dal G80, hanno la memoria locale strutturata in modo compatibile con OpenCL 1.0. Bravi loro ad aver anticipato i tempi!

alla faccia di quanti sostenevano il vantaggio tecnologico dei chip Ati su quelli Nvidia :D :D (in realtà quelli Ati come sappiamo supportavano le dx10.1 molto prima di quelli Nvidia, i conti si pareggiano )

ah sì? e che software hai scritto in OpenCL?


io? mai nessuno e secondo te io che compro una hd4850/70/x2 la uso per programmare in openCL? credo che sia una percentuale molto ma molto esigua quella dei proprietari di questa serie di schede video che veramente di possono dirsi svantagiati, personalmente la uso per i videogame e per Maya e non mi ha mai dato alcun problema e ribadisco che questa è solo una mera tattica per provare a spingere la hd5xxx.

Il titolo della news non mi pare azzeccato, ma anche la news spiega poco dove sia effettivamente il problema, sembra + uno slogan contro ATI.

Su Tom's Hw spiegano dove sia principalmente il problema andate a leggervi quell'articolo che è di lunedi :asd:

http://www.tomshw.it/cont/news/le-radeon-hd-4000-non-digeriscono-opencl/23362/1.html

il problema è a livello hardware, forse sarà risolvibile con un paio di aggiornamenti

se ti riferisci a questo

http://www.tomshw.it/cont/news/le-radeon-hd-4000-non-digeriscono-opencl/23362/1.html

qui parla di utilizzo della memoria locale e globale. La cosa è alquanto strana perchè sulla serie 4x00 c'è una cache L2 che può essere utilizzata proprio per lo scambio di dati in locale
http://www.ixbt.com/video3/images/rv770/rv770_memory2.png

da notare che la L1 è solo texture cache, mentre la L2 è di tipo GP.

ah sì? e che software hai scritto in OpenCL?



non è vero. Parecchie cose sono cambiate a livello hardware, anche se sono solo ottimizzazioni erano in realtà indispensabili per la piena compatibilità ad OpenCL 1.0.
La feature principale che manca sulla serie HD4xxx è la memoria LOCALE che risponda alle specifiche OCL1.0, una sorta di cache velocissima per ciascun cluster di shader ma accessibile anche agli altri shader. Non essendo possibile questa cosa in queste schede, la memoria locale viene emulata dai driver nella RAM della GPU, che però è molto più lenta. Per questo motivo, programmi che sfruttano molto la memoria locale hanno prestazioni molto ridotte (pietose, direi) sulle schede HD4xxx.

Che poi, dico io, il fatto che giri openCL su queste schede "vecchie" è tutto grasso che cola (come si dice dalle mie parti)... Nessuno si lamenta che una scheda vecchia di un anno e mezzo non funzioni con le nuovissime DirectX 11, ad esempio... Qui è la stessa cosa, di grazia che anche se lentamente almeno giri!

ps: nvidia non ha di questi problemi perché i suoi chip, fin dal G80, hanno la memoria locale strutturata in modo compatibile con OpenCL 1.0. Bravi loro ad aver anticipato i tempi!

la serie 4xxx non ha cache dedicata ad ogni singolo cluster. Però c'è una cache L2 di tipo GP, accessibile a tutti i cluster (anche se non dedicata) che può essere usata a tale scopo, invece di accedere alla vram.
I chip nVidia non hanno una cache velocissima accessibie a tutti i cluster di shader. Hanno una local memory per singolo thread, una shared memory per singolo cluster ovvero condivisa tra i thread dello stesso cluster (entrambe interne al chip) e una global memory, accessibile a tutti i cluster, che si trova nella vram.La memoria condivisa tra tutti i cluster per le atomic ops è una prerogativa dei compute shader 5.0 (ce l'ha rv870 e l'avrà fermi) ed è una feature non presente neppure sui chip nVidia serie 8, 9 e gt200 (anzi rv770 ha, almeno, una cache L2 interna accessibile tramite crossbar a tutti i cluster)

Considerando che OpenCL è stato fortemente voluto da Apple in primis e la stessa Apple monta su molte macchine proprio grafica basata su HD4xxx (gli iMac e i MacPro) proprio per sfruttare OpenCL a livello di kernel in SnowLeopard (http://www.apple.com/it/macosx/technology/#opencl), dubito che la notizia sia vera. Senza dubbio la serie HD5xxx è più ottimizzata, ma lo è in tutte le sue funzionalità (altrimenti che serie nuova sarebbe stata).

Hai installato il catalyst 9.12 hotfix e ati stream sdk ?

Ok problema risolto..:)
Ho reinstallato l' Ati Stream 2.0 e adesso GPU Caps Viewer vede il mio sistema come OpenCL ready...

http://www.pctunerup.com/up/results/_200912/20091230122427_ScreenHunter_126.jpg

Una 4850 vecchia? Quanti colpi che gli darei!
Io come altri qui sul forum ce l'hanno e magari comprata da nemmeno 12 mesi sempre in garanzia!

Le parole che sputano questi "market-man" vanno sempre prese con le pinze. Magari il vantaggio sarà dello 0% nella stragrande maggioranza delle applicazioni e del 10% in quelle incriminate.

Comprate le nuove 5xxx...comprate le nuove 5xxx... Comprate le nuove 5xxx...

Comprate le nuove 5xxx...comprate le nuove 5xxx... Comprate le nuove 5xxx...

infatti; si trattava di una cosa nota da tempo. Nessun chip, tranne quelli dx11, hanno una memoria interna condivisa da tutti i cluster di alu; questo semplicemente perchè i compute shader 4.0 e 4.1 non prevedono questa feature.
Sospetto il fatto che la cosa sia venuta fuori solo ora.

ci fosse 1 sola volta che non abbiano problemi, figurati. :O

ci fosse 1 sola volta che non abbiano problemi, figurati.

Questo è un NON-PROBLEMA.

Non riesco a far funzionare il mio Celeron@500Mhz a 64bit! Come mai? Azzz...vuoi vedere che manca la parte 'hardware' per far questo?

Nella news (ed in altri siti) si spiega il fatto che OpenCL e GPU R7xx sono state progettate in tempi diversi: e mentre le prime sono solo 'software' le seconde, una volta 'andate in stampa', non si possono mica cambiare più di tanto, e quindi si fa quello che si può sul lato driver.
E questo significa (e significherà in futuro...) che ci potranno essere applicazioni OpenCL OTTIMIZZATE per GPU AMD e per GPU Nvidia.
Guarda caso Apple - che è il principale sponsor di OpenCL - ha voluto a tutti i costi bypassare uno scenario del genere proprio per evitare di dover ri-scrivere parti del proprio SO a seconda della GPU usata.

Nel caso in esame la serie HD4x00 è nata prima della definizione dello standard, per cui c'è poco da fare, e di sicuro non è colpa dei designer di AMD (che molto probabilmente NON pensavano ad un utilizzo in ambito diverso da quello grafico delle proprie GPU).
Nvidia ha avuto solo 'culo' nell'aver già in cantiere un progetto con memoria locale per ogni singola ALU. Tutto qui.

A dirla tutta è molto probabile che a livello di design tutte le prossime GPU (di AMD, di Nvidia o di Intel) avranno tutte le medesime caratteristiche tecniche per rispettare gli standard OpenCL 1.0 - cambieranno le velocità e pochi altri parametri.
A meno che ovviamente qualcuno non voglia spingere (=dare mazzette) per uno standard OpenCL 1.2 con caratteristiche che avvantaggino solo una parte: anche in questo caso le applicazioni saranno SEMPRE scritte per la versione 1.0 proprio per quanto detto su Apple.

E' palese poi che AMD spinga a vendere le attuali schede, sarebbe stupido il contrario...

PS: posseggo una vecchia GeForce 6600 - quindi io CUda/OpenGL e quant'altro me lo scordo.

se è tale, non credo sia risolvibile con "aggiornamenti"....

qui ci vuole il mitico yossarian :D

ops, questa mi era sfuggita. :D
Spero che quel "mitico" sia ironico :D

Comunque, battute a parte, se il problema è quello dell'impossibilità di condividere i dati tra i thread di più cluster, la soluzione è l'utilizzo della cache L2 posizionata vicino ai MC di RV770.
Diciamo che le specifiche dei compute shader 4.0 e 4.1 non prevedono la condivisione dei dati tra thread di differenti cluster e, infatti, nessun chip non dx11 è dotato di memoria interna condivisa tra più SP. G80 e GT200 hanno un'organizzazione che prevede 3 livelli di cache, una local memory per singolo thread (quindi dedicata alla singola alu) una shared memory dedicata al singolo cluster (quindi condivisa tra le alu di uno stesso SP) e una global memory condivisa da tutti i cluster ma posizionata nella vram.
Per non fare confusione sui termini, quando dico SP intendo un cluster di 16 (g80) e 24 alu (gt200) e non la singola alu. :D

IMHO è una non notizia uscita in tempi sospetti (leggi per spingere le vendite delle 5770 rispetto alle 4870/4890)

Questo è un NON-PROBLEMA. Non riesco a far funzionare il mio Celeron@500Mhz a 64bit! Come mai? Azzz...vuoi vedere che manca la parte 'hardware' per far questo?


E questo lo riporto xkè dovrebbe essere chiaro.


Nvidia ha avuto solo 'culo' nell'aver già in cantiere un progetto con memoria locale per ogni singola ALU. Tutto qui.


nVidia mi sta antipatica proprio xkè ha troppo culo.


PS: posseggo una vecchia GeForce 6600 - quindi io CUda/OpenGL e quant'altro me lo scordo.

Ma aldilà di tutto, si dicevano paroloni approposito di video encoding H264 tramite scheda video, povray, raytracing tutto renderizzato tramite GPU. Per H264 è stato fatto badaboom che tra l'altro è pessimo e la qualità di codifica è penosa, e per le altre cose?

CUDA lo vedo sfruttato solo da quei programmi "@home". Fine. OpenCL per ora vedo solo dei benchmark otrettutto BETA, nessuna applicazione realmente utile. Tutta quà l'evoluzione?

Non nascondo che mi hanno proprio rotto il ka....o con questi chiari inviti a foraggiarli, ne ho le pa...e piene di questo mondo hardware votato esclusivamente al profitto, penso che anche voi siate un pò stanchi ormai........ho una 4870x2 pagata a caro prezzo e di sicuro non la svenderò per 200 euro solo perchè devo vedere features come la tesselation che già esistevano da tempo e che vengono riproposte come meraviglie tecnologiche.........mai più veramente che sia Ati o Nvidia......farò beneficenza di quei soldi.......Open Cl ma vaff....

Quoto Killer, 40000 notizie (tra l'altro buttate al vento date le non-fonti) riguardo nVidia e ben poche riguardo ATI e a volte buttate la come se avessero dei grossi problemi

Quoto anche Degac, QUESTO è UN NON PROBLEMA, anzi non è proprio un problema, queste schede video le compra chi ci vuol giocare su PC (quindi DX), in ambito Home l'OpenCL è ben poco usato, chi le usa per ste cose (tipo programmatori) s'informa prima di comprare una scheda video e di certo non ne compra di sto genere.

la serie 4xxx non ha cache dedicata ad ogni singolo cluster. Però c'è una cache L2 di tipo GP, accessibile a tutti i cluster (anche se non dedicata) che può essere usata a tale scopo, invece di accedere alla vram.
I chip nVidia non hanno una cache velocissima accessibie a tutti i cluster di shader. Hanno una local memory per singolo thread, una shared memory per singolo cluster ovvero condivisa tra i thread dello stesso cluster (entrambe interne al chip) e una global memory, accessibile a tutti i cluster, che si trova nella vram.La memoria condivisa tra tutti i cluster per le atomic ops è una prerogativa dei compute shader 5.0 (ce l'ha rv870 e l'avrà fermi) ed è una feature non presente neppure sui chip nVidia serie 8, 9 e gt200 (anzi rv770 ha, almeno, una cache L2 interna accessibile tramite crossbar a tutti i cluster)

il Corsini ha fatto uno slogan velatamente pro nvidia :asd:
questa parte è assurda :
"Resta da capire se una limitazione di questo tipo possa riguardare anche la prima generazione di schede video NVIDIA basate su architettura DirectX 10, famiglia GeForce 8000 e 9000, mentre per le soluzioni basate sulla successiva architettura GT200 sembra non vi siano limitazioni prestazionali evidenziatesi sino ad ora"

News ripeto assurda

Secondo me questo notizia è venuta fuori per spingere le vendite della HD 5000 series in confronto della HD 4000 series e francamente reputo che sia una cavolata bella e buona da parte di AMD.

La tessellation c'era già sulle HD2xxx, HD3xxx e HD4xxx, chiedi a Microsoft perché non è mai entrata nelle specifiche DX10 come doveva. La risposta ti divertirà...

avrebbe solo affossato ulteriormente le prestazioni già scarse delle Dx10 nel 2007. Ora l'hardware è più maturo, ma non è che l'implementazione del tessellatore sia indolore in termini di frame rate.

Non nascondo che mi hanno proprio rotto il ka....o con questi chiari inviti a foraggiarli, ne ho le pa...e piene di questo mondo hardware votato esclusivamente al profitto, penso che anche voi siate un pò stanchi ormai........ho una 4870x2 pagata a caro prezzo e di sicuro non la svenderò per 200 euro solo perchè devo vedere features come la tesselation che già esistevano da tempo e che vengono riproposte come meraviglie tecnologiche.........mai più veramente che sia Ati o Nvidia......farò beneficenza di quei soldi.......Open Cl ma vaff....


Quoto, anche perchè se le "meravigliose DX11" sono come in Dirt2:mc: :mc:
Non capisco come la gente ha voglia di cambiare una signora scheda come la tua o simile con una nuova scheda DX11:confused: :confused:

Chi ha una 48xx può anche tenersela e aspettare, ma se trovi l'occasione di venderla a buon prezzo meglio oggi che domani! Io ho venduto la mia 48xx ed ho aggiunto solo 45€ per prendermi la 5850 a prezzo umano appena uscita.

Se posso aggiungo un mia piccola esperienza: sono passato da un Q6600 e 4890 ad un Q9550 e 5850, oltre all'aumento di prestazione e temperature decisamente + basse ho risparimato in quest'ultimi due mesi 25€ di corrente e vi assicuro che erano mesi che pagavo sempre + o - quella cifra!! il PC resta acceso mediamente 4/5 giorni a settimana 24h su 24h

Lo so non centra un caiser con la notizia ma volevo raccontare questa piccola parentesi :)

Che poi non si capisce perchè una scheda basata su rv770/rv790 dovrebbe avere problemi mentre una 5750/5770 no quando l'architettura praticamente è la medesima ed il chip pure :D
Mi sa tanto di mossa di marketing

Ti sa MALE.

Tanto per fare un esempio la shared memory che sulle 5xxx è nativa, sulle 4xxx è emulata, e è per questo che le prestazioni in opencl dove serve la shared memory precipitano.

Dove serve? GPUGRID. Ohibò, ma forse si e no lo 0.1% di possessori delle ATI macina su gpugrid se non meno, però qua ne viene fatto un dramma


Peccato che non si dica mai che in cuda vs cal le ATI battono nvidia su ogni fronte :rolleyes: Però su opencl subito a criticare, uao :fagiano:

Non nascondo che mi hanno proprio rotto il ka....o con questi chiari inviti a foraggiarli, ne ho le pa...e piene di questo mondo hardware votato esclusivamente al profitto, penso che anche voi siate un pò stanchi ormai........ho una 4870x2 pagata a caro prezzo e di sicuro non la svenderò per 200 euro solo perchè devo vedere features come la tesselation che già esistevano da tempo e che vengono riproposte come meraviglie tecnologiche.........mai più veramente che sia Ati o Nvidia......farò beneficenza di quei soldi.......Open Cl ma vaff....

Prego? La shared memory SERVE, se non sai di cosa si parla evita di insultare opencl GRAZIE. Perchè magari chi ha bisogno di queste tecnologie e le usa che so, si può anche sentire offeso

è GL non CL

bè allora se non ha sto supporto che cambia? :S

la serie 4xxx non ha cache dedicata ad ogni singolo cluster. Però c'è una cache L2 di tipo GP, accessibile a tutti i cluster (anche se non dedicata) che può essere usata a tale scopo, invece di accedere alla vram.


Quoto.
Ma infatti quell'articolo su Tomshw non rivela niente di nuovo.
Potrei sempre, attraverso la crossbar delle 48x0 nella L2, seppur dislocata, condividere i dati ad uso generico di tutti gli SPU di ogni cluster.
Poi grazie a sto ciufolo che una memoria interna e quindi più veloce sarebbe meglio.... ma vaaa. :asd:

Non si è mai preteso di eguagliare prestazioni complessive della serie 5xxx, ma solo di avere il supporto ottimizzato per quanto sia possibile fare con la precedente generazione; se poi non vogliono procedere nella scrittura del codice adeguato e ottimizzato in quelle librerie è un altro discorso.
Se ATI ritiene di avere a cuore la propria clientela e pensa che questo sia un modo per non farla spazientire, dovrebbe supportare queste schede, anche perché sono tuttora sul mercato e a prezzi anche High-End.
Queste schede non saranno state progettate pure per OpenCL, ma sono in grado assolutamente di accollarsene il carico.

è GL non CL

OpenGL è una cosa e OpenCL un'altra.

Il supporto ce l'ha, solo prestazioni inferiori :)

e l'open cl chi lo usa?

e l'open cl chi lo usa?

Bah! Per adesso non c'è niente, si parlava in prospettiva futura.
Non so, se lo staff tecnico AMD/ATi sta procedendo allo sviluppo di quelle librerie lì, qualche cavolata in mente ce l'avranno...
Dici che è tutto fumo e niente arrosto?

Per ora nulla :>

Bah! Per adesso non c'è niente, si parlava in prospettiva futura.
Non so, se lo staff tecnico AMD/ATi sta procedendo allo sviluppo di quelle librerie lì, qualche cavolata in mente ce l'avranno...
Dici che è tutto fumo e niente arrosto?

han dato solo pane per i fanboy nvidia allora... :sofico:

Per ora nulla :>

Bah! Per adesso non c'è niente, si parlava in prospettiva futura.
Non so, se lo staff tecnico AMD/ATi sta procedendo allo sviluppo di quelle librerie lì, qualche cavolata in mente ce l'avranno...
Dici che è tutto fumo e niente arrosto?

GPUGRID

Se non sapete le cose, tacete, opencl è usato.

Peccato che non si dica mai che in cuda vs cal le ATI battono nvidia su ogni fronte :rolleyes: Però su opencl subito a criticare, uao :fagiano:



Ma questo è avvenuto perché effettivamente sul lato GPGPU ATi finora ha offerto poca carne al fuoco rispetto a Nvidia.
Tanti colpi rimasti in canna, Nvidia ha perlomeno tentato di spararne qualcuno.
PhysX, per quanto odioso, è uscito, ATI per scuotersi un po' ha voluto vedere i risultati prima, o forse non ci ha creduto subito.

Comunque io non ci giurerei tanto sul fatto che all'atto pratico ATI Stream sarebbe sempre migliore di CUDA, almeno non in tutti i casi.

Ci sarebbero delle differenze.

I CUDA Cores sono entità con cache dedicata e che viaggiano indipendenti rispetto agli Streams Processor ATI.
Mentre ATI da un teorico di 800 SP (in rif. alla serie 48x0), potrebbe largamente precipitare fino 160 SP effettivi per la natura di incapsulamento e di interconnessione di ciascuna SPU, Nvidia disporrebbe sempre della sua capacità massima di Threading, e nella serie GT200 queste differenze strutturali si farebbero sentire poiché nessun modello mostra meno di 192 cores.
A seconda del tipo di istruzione da impartire al cluster, con ATI esiste lo scenario e la possibilità in cui andrebbero sprecati ALU riducendo così la parallelizzazione massima teorica consentita, con Nvidia invece avresti sempre a disposizione il valore nominale dei CUDA cores previsti per quel taglio.

Per cui se ATI ha certamente, sulla carta, un potenziale maggiore a Nvidia, non è detto che questo possa manifestarsi sempre. :)

Contro una 9800 GTX+ sarebbe più facile averla vinta. ;)

Sono approcci differenti, e la faccenda non è così facile da liquidare.
Avessimo un ATI Stream allo stadio di CUDA potremmo dilettarci a vedere chi picchierebbe più duro.

Ratatosk
Hai capito? Se le cose non le sai, devi tacere, shhhh :O :asd:
:p :sofico:

la serie 4xxx non ha cache dedicata ad ogni singolo cluster. Però c'è una cache L2 di tipo GP, accessibile a tutti i cluster (anche se non dedicata) che può essere usata a tale scopo, invece di accedere alla vram.
I chip nVidia non hanno una cache velocissima accessibie a tutti i cluster di shader. Hanno una local memory per singolo thread, una shared memory per singolo cluster ovvero condivisa tra i thread dello stesso cluster (entrambe interne al chip) e una global memory, accessibile a tutti i cluster, che si trova nella vram.La memoria condivisa tra tutti i cluster per le atomic ops è una prerogativa dei compute shader 5.0 (ce l'ha rv870 e l'avrà fermi) ed è una feature non presente neppure sui chip nVidia serie 8, 9 e gt200 (anzi rv770 ha, almeno, una cache L2 interna accessibile tramite crossbar a tutti i cluster)

Ciao Yossarian,
premesso che si suppone che il supporto AMD sappia quello che dice, da quanto vedo in questa pagina RV770 ha sia LDS che GDS:
http://www.anandtech.com/video/showdoc.aspx?i=3341&p=3

In pratica l'articolo di anandtech conferma quello che hai scritto anche tu.
Si sa nulla sulla dimensione di queste cache? Magari il problema è tutto lì (un utente, sul forum di Techreport, accennava al fatto che anche G80/GT200 è in difficoltà in questi ambiti in quanto la LDS è di soli 16KB).

EDIT: mi rispondo da solo... nell'articolo linkato sopra, è riportato che LDS e GDS di RV770 sono di 16KB ciascuna.

Ciao.

GPUGRID

Se non sapete le cose, tacete, opencl è usato.

mmm e al di fuori di boinc?

Ti sa MALE.
Tanto per fare un esempio la shared memory che sulle 5xxx è nativa, sulle 4xxx è emulata, e è per questo che le prestazioni in opencl dove serve la shared memory precipitano.

Dove serve? GPUGRID. Ohibò, ma forse si e no lo 0.1% di possessori delle ATI macina su gpugrid se non meno, però qua ne viene fatto un dramma


Peccato che non si dica mai che in cuda vs cal le ATI battono nvidia su ogni fronte :rolleyes: Però su opencl subito a criticare, uao :fagiano:


Zio guarda che ho una 4890 in arrivo, prima ho avuto una 4850, poi ancora prima (a parte una parentesi con 8800GTS) una x800, una 9800pro, 9600 pro, 8500 e radeon di prima generazione.
Se cercavi il fanboy nvidia hai sbagliato persona.
Ciò non toglie che questa sia solo una mossa di marketing per spingere le vendite della serie 5000, perchè se leggi gli interventi di Yossarian potrebbero ottenere buoni risultati (o comunque miglior di quelli attuali) anche con la serie 4000 con una buona ottimizzazione, pur logicamente minori rispetto alla serie 5000, ma non gliene frega niente.

Ciao Yossarian,
premesso che si suppone che il supporto AMD sappia quello che dice, da quanto vedo in questa pagina RV770 ha sia LDS che GDS:
http://www.anandtech.com/video/showdoc.aspx?i=3341&p=3

In pratica l'articolo di anandtech conferma quello che hai scritto anche tu.
Si sa nulla sulla dimensione di queste cache? Magari il problema è tutto lì (un utente, sul forum di Techreport, accennava al fatto che anche G80/GT200 è in difficoltà in questi ambiti in quanto la LDS è di soli 16KB).

EDIT: mi rispondo da solo... nell'articolo linkato sopra, è riportato che LDS e GDS di RV770 sono di 16KB ciascuna.

Ciao.

sono tutte di 16 KB che è la misura prevista dai co pute shader 4.0 e 4.1. ATi ha in più, oltre alle cache locali dedicate al singolo thread e al singolo cluster (o SP che dir si voglia) anche una cache, posizionata a livello di Mc, di 5 MB, utilizzabile come frame buffer locale (tipo eDRAM di XBOX, per intenderci).

Quindi, come ho detto, IMO si tratta di una non notizia.

Potresti spiegarmi perché una x1900XTX non è DirectX10 compliant?

Dopo che avrai dato questa risposta saprai anche perché le HD4000 hanno il "problema" descritto ;)

Perchè R500 non è nato per essere dx10 compliant, ti sei dato la risposta da solo :D
Invece RV770 è opencl compliant, altrimenti non funzionerebbe proprio. Mi suona anche strano il fatto che a proporlo e volerlo fortemente sia stata Apple, che guardacaso usa schede ati 4000 sui mac più potenti.
Poi per carità, personalmente dell'opencl come si dice a Roma "nun me ne pò fregà de meno" però perchè non ottimizzarlo sulla serie 4000 quando si potrebbe ?

Esatto. Esattamente come RV770 non è nato per essere OpenCL compliant, per un motivo molto semplice, le specifiche OpenCL sono state finalizzate non dopo il tapeout, ma addirittura dopo la commercializzazione dei prodotti basati su questo chip.

Ho capito, quello che voglio dire è che pure se le 4000 non sono state progettate appositamente per l'opencl, questo ci gira lo stesso e ci sono anche margini per farlo funzionare meglio di ora. Però in casa AMD dicono espressamente che non è un loro obiettivo.
Ma perchè ? Per far cacciare altri 150 euro a chi è interessato ?

Comunque buona parte dei commenti sono ridicoli.
Una notizia per spingere le vendite delle hd5xxx? Ma stiamo scherzando? c'è un thread tecnico sull'AMD developers forum (con link presente nell'articolo) e tanto di discussione (di cui Ratatosk ha citato un pezzo fondamentale, vedi sotto) e si riescono ad insinuare anche che ci siano "uomini del marketing" dietro...

Cito di nuovo il pezzo di discussione citato. Colui che scrive è Micah Villmow, dipendente di AMD:

"I wouldn't say that it is a turkey, it just has to be programmed differently than the 5XXX series to get performance because of the lack of proper hardware local support. It is possible to get good performance, just not with a direct port from Cuda."

dove si dice che le schede 4xxx non sono "tacchini" (in senso ironico), ma vanno semplicemente programmate in modo differente dalle 5xxx per avere buone performance a causa della mancanza del supporto hardware per la memoria locale. Inoltre è possibile ottenere delle buone performance, ma non va bene fare un port diretto da codice Cuda (come ha fatto l'autore del thread sul developers forum, ndr).

Comunque buona parte dei commenti sono ridicoli.
Una notizia per spingere le vendite delle hd5xxx? Ma stiamo scherzando? c'è un thread tecnico sull'AMD developers forum (con link presente nell'articolo) e tanto di discussione (di cui Ratatosk ha citato un pezzo fondamentale, vedi sotto) e si riescono ad insinuare anche che ci siano "uomini del marketing" dietro...

Cito di nuovo il pezzo di discussione citato. Colui che scrive è Micah Villmow, dipendente di AMD:

"I wouldn't say that it is a turkey, it just has to be programmed differently than the 5XXX series to get performance because of the lack of proper hardware local support. It is possible to get good performance, just not with a direct port from Cuda."

dove si dice che le schede 4xxx non sono "tacchini" (in senso ironico), ma vanno semplicemente programmate in modo differente dalle 5xxx per avere buone performance a causa della mancanza del supporto hardware per la memoria locale. Inoltre è possibile ottenere delle buone performance, ma non va bene fare un port diretto da codice Cuda (come ha fatto l'autore del thread sul developers forum, ndr).

infatti vanno programmate diversamente perchè si deve mappare la cache L2 per utilizzarla come fbuffer per le atomic ops, mentre le gpu dx11 hanno già una cache dedicata condivisa tra tutti i cluster del chip. Non è un'operazione semplicissima ma non è neppure impossibile. Ovvio, poi, che non si possa fare un porting diretto da CUDA: i chip nVidia non hanno la possibilità di usare cache interne per fare eseguire questo task, poichè la global cache è allocata nella vram. Quindi CUDA prevede l'uso di una porzione della vram individuata come global cache (accessibile da tutti gli SO della GPU e dalla CPU) con un notevole degrado delle prestazioni, mentre l'utilizzo di una cache interna pemetterebbe di velocizzarle notevolmente (riduci i tempi di accesso di un ordine di grandezza circa).
Quello che dice Villmow e che è stato riportato da Ratatosk è vero: RV770 non ha una global cache dedicata alle operazioni di data sharing tra thread di cluster differenti, nè nella vram nè all'interno del chip e ne deve essere inizializzata e mappata una appositamente (la L2 è meglio di una porzione delle vram a questo scopo, agendo a basso livello con i tool messi a disposizione da CAL)

infatti vanno programmate diversamente perchè si deve mappare la cache L2 per utilizzarla come fbuffer per le atomic ops, mentre le gpu dx11 hanno già una cache dedicata condivisa tra tutti i cluster del chip. Non è un'operazione semplicissima ma non è neppure impossibile. Ovvio, poi, che non si possa fare un porting diretto da CUDA: i chip nVidia non hanno la possibilità di usare cache interne per fare eseguire questo task, poichè la global cache è allocata nella vram. Quindi CUDA prevede l'uso di una porzione della vram individuata come global cache (accessibile da tutti gli SO della GPU e dalla CPU) con un notevole degrado delle prestazioni, mentre l'utilizzo di una cache interna pemetterebbe di velocizzarle notevolmente (riduci i tempi di accesso di un ordine di grandezza circa).
Quello che dice Villmow e che è stato riportato da Ratatosk è vero: RV770 non ha una global cache dedicata alle operazioni di data sharing tra thread di cluster differenti, nè nella vram nè all'interno del chip e ne deve essere inizializzata e mappata una appositamente (la L2 è meglio di una porzione delle vram a questo scopo, agendo a basso livello con i tool messi a disposizione da CAL)

Ciao,
ho il dubbio che qualcosa non mi quadri... :confused:

Da questa immagine si vede chiaramente che RV770 ha una GDS on-chip:
http://images.anandtech.com/reviews/video/ATI/4800/DPPA.png

Mentre qui si vede la LDS propria di ciascun SIMD array:
http://www.xbitlabs.com/misc/picture/?src=/images/video/ati-radeon-hd4850/rv770_simd_large.gif&1=1

E qui c'è la famosa L2 di cui parlavi (dietro il controller crossbar)
http://www.xbitlabs.com/images/video/ati-radeon-hd4850/rv770_cache.gif
Tra l'altro, nel thread linkato al forum di AMD, anche il supporto da lo stesso consiglio che hai dato tu: usare la cache L2 per operazioni di GDS.

A questo punto la domanda è: il problema evidenziato dal dipendente AMD si riduce al fatto che, pur avendo RV770 una GDS on-chip, questa non è utilizzabile per le operazioni atomiche?
Oppure, semplicemente, la GDS di cui sopra non è utilizzabile come memoria ma solo come cache (e quindi non è direttamente controllabile dal programmatore)?
Altra opzione: la GDS è troppo piccola (16KB) per quello specifico caso?

Ciao. :)

Ciao,
ho il dubbio che qualcosa non mi quadri... :confused:

Da questa immagine si vede chiaramente che RV770 ha una GDS on-chip:
http://images.anandtech.com/reviews/video/ATI/4800/DPPA.png

Mentre qui si vede la LDS propria di ciascun SIMD array:
http://www.xbitlabs.com/misc/picture/?src=/images/video/ati-radeon-hd4850/rv770_simd_large.gif&1=1

E qui c'è la famosa L2 di cui parlavi (dietro il controller crossbar)
http://www.xbitlabs.com/images/video/ati-radeon-hd4850/rv770_cache.gif
Tra l'altro, nel thread linkato al forum di AMD, anche il supporto da lo stesso consiglio che hai dato tu: usare la cache L2 per operazioni di GDS.

A questo punto la domanda è: il problema evidenziato dal dipendente AMD si riduce al fatto che, pur avendo RV770 una GDS on-chip, questa non è utilizzabile per le operazioni atomiche?
Oppure, semplicemente, la GDS di cui sopra non è utilizzabile come memoria ma solo come cache (e quindi non è direttamente controllabile dal programmatore)?
Altra opzione: la GDS è troppo piccola (16KB) per quello specifico caso?

Ciao. :)

la GDS è una memoria di tipo cache

http://ati.amd.com/technology/streamcomputing/images/47039A_OpenCLMemoryModel_375W.jpg

questa è la gerarchia della memoria prevista dalle opencl.

Ogni cluster ha una memoria privata a disposizione della singola alu, una memoria locale a disposizione di tutte le alu dello SP e una memoria globale di tipo cached on chip. In più c'è una memoria globale esterna nella vram. I chip ATi hanno rispettano questa gerarchia mentre in quelli nVidia, fino a Gt200 compreso, manca la GDS di tipo cache
Sia RV870 che RV770 (e anche RV670) rispettano questo schema. Quello che è stato aggiunto in RV870 non inficia la compatibilità delle precedenti serie rispetto alle specifiche opencl. Il fatto che sia stata quadruplicata la GDS e ne sia stato velocizzato l'accesso la rende solo più "usabile"

Se questo è vero allora ottimo visto che io stesso avevo detto precedentemente non avevo escluso che AMD lo facesse per spingere le HD 5000 series.

la GDS è una memoria di tipo cache

http://ati.amd.com/technology/streamcomputing/images/47039A_OpenCLMemoryModel_375W.jpg

questa è la gerarchia della memoria prevista dalle opencl.

Ogni cluster ha una memoria privata a disposizione della singola alu, una memoria locale a disposizione di tutte le alu dello SP e una memoria globale di tipo cached on chip. In più c'è una memoria globale esterna nella vram. I chip ATi hanno rispettano questa gerarchia mentre in quelli nVidia, fino a Gt200 compreso, manca la GDS di tipo cache
Sia RV870 che RV770 (e anche RV670) rispettano questo schema. Quello che è stato aggiunto in RV870 non inficia la compatibilità delle precedenti serie rispetto alle specifiche opencl. Il fatto che sia stata quadruplicata la GDS e ne sia stato velocizzato l'accesso la rende solo più "usabile"

Benissimo, allora non avevo frainteso io le slide postate sopra (che si adattano alla perfezione all'immagine da te riportata).

Il punto è che alla luce di queste informazioni, non capisco la risposta del dipendente AMD:
"For example, if you are using local memory, they are all currently emulated in global memory. So it is possible you are going out to main memory twice as often as you do on NVidia. This can cause a fairly large performance hit if the application is memory bound. On the HD5XXX series, local memory is mapped to hardware local and thus is many times faster than the HD4XXX series."

Lui dice che la memoria locale è emulata nella memoria globale (VRAM), mentre dalle slide riportate si evince (come confermi anche tu) che RV770 _ha_ memoria locale e quindi non dovrebbe essere necessario emulare nulla.
Secondo me il problema nasce dal fatto che il tizio sta cercando di caricare nella memoria locale troppi dati, e questi vengono rimappati nella VRAM.

Sbaglio? :p

Benissimo, allora non avevo frainteso io le slide postate sopra (che si adattano alla perfezione all'immagine da te riportata).

Il punto è che alla luce di queste informazioni, non capisco la risposta del dipendente AMD:
"For example, if you are using local memory, they are all currently emulated in global memory. So it is possible you are going out to main memory twice as often as you do on NVidia. This can cause a fairly large performance hit if the application is memory bound. On the HD5XXX series, local memory is mapped to hardware local and thus is many times faster than the HD4XXX series."

Lui dice che la memoria locale è emulata nella memoria globale (VRAM), mentre dalle slide riportate si evince (come confermi anche tu) che RV770 _ha_ memoria locale e quindi non dovrebbe essere necessario emulare nulla.
Secondo me il problema nasce dal fatto che il tizio sta cercando di caricare nella memoria locale troppi dati, e questi vengono rimappati nella VRAM.

Sbaglio? :p

fa riferimento alla local memory, quindi tutti i discorsi fatti sulla GDS non hanno ragion d'essere. Ora, poichè la local memory è sicuramente presente all'interno del chip, dal momento che si parla di emulazione è evidente che il problema non è una mancanza di hardware dedicato ma un problema di hardware non utilizzato (leggi problema software). La local memory è quella condivisa dalle alu di uno stesso cluster. Ovvio che, a questo punto, neanche la GDS è utilizzata, quindi si tratta semplicemente di riscrivere il codice in modo che si faccia uso di queste memorie interne.
Tra l'altro, se fosse una "mancanza" di tipo hardware, non si risolverebbe con qualche aggiornamento software

Beh!
C'è da premettere che quando uscì il kit di sviluppo 2.0 di ATI Stream, leggendo sulle release note ricordo che, mentre per i chip RV8xx (serie 5000) il supporto e lo stato di conformità era definito già completo, per i chip RV7xx (serie 4000) no, era, ed è tuttora, in beta provvisorio e incompleto.

L'utente che ha manifestato il disappunto sul forum AMD ha rivelato di usare quella versione del kit.

Io non so, fin dalle prime battute MicahVillmow lascia pensare che non ci saranno ulteriori processi atti a ottimizzare i chip della generazione precedente per quel che riguarda la gestione della memoria locale, continuando a leggere poi però quasi lascia spiragli di speranza nel caso l'utenza, in futuro, lo riterrebbe necessario.
C'è inoltre da considerare un'altra cosa.
L'attuale livello di astrazione delle librerie non è così raffinato dal ben considerare le differenze tra serie 4xxx e 5xxx. Lo sviluppatore, quando scrive il codice, deve ancora farsi carico di troppi dettagli che interessano il paradigma OpenCL e le complessità derivanti tra hardware relativamente differenti, con le conseguenze di notevole impatto sulle prestazioni. Bisognerà aspettare che il compilatore maturi per queste ottimizzazioni specifiche e per poter scrivere una volta sola il codice ed avere garanzie di ottenere le massime prestazioni permesse tra adattatori video di famiglia differente.

E' troppo presto per uccidere il maiale, ancora non è ingrassato abbastanza.

ma si..anno nuovo abitudine vecchia..8 articoli su vaporware nVidia, i articolo su problemi ati..
per poco non ridevo leggendo l'articolo su quei 8 stream processor disativati su "alcune" sapphire..

mmm... temo non riuscirò a prendere sonno la notte per la frustrazione a causa di questa incompatibilità.

lol, come devo interpretare questi numeri?


ATI MOBILITY Radeon HD 4650 @ 550 MHz (1002 / 9480 / 3637103C)
AMD Turion(tm) II Ultra Dual-Core Mobile M600 (2 logical CPUs)

Benchmark version: v0.45
DirectCompute: N/A
OpenCL: C547.1
CPU: M12.7

ATI Radeon Kernel Mode Driver
atikmdag 8.01.01.984
Windows 7 x64 Home Premium Edition (build 7600)

fa riferimento alla local memory, quindi tutti i discorsi fatti sulla GDS non hanno ragion d'essere. Ora, poichè la local memory è sicuramente presente all'interno del chip, dal momento che si parla di emulazione è evidente che il problema non è una mancanza di hardware dedicato ma un problema di hardware non utilizzato (leggi problema software). La local memory è quella condivisa dalle alu di uno stesso cluster. Ovvio che, a questo punto, neanche la GDS è utilizzata, quindi si tratta semplicemente di riscrivere il codice in modo che si faccia uso di queste memorie interne.
Tra l'altro, se fosse una "mancanza" di tipo hardware, non si risolverebbe con qualche aggiornamento software

Ciao Yoss,
ti ringrazio... allora è confermato che è un non-problema... ;)

Ciao. :)