ARGOMENTO:

Vai ATI

Dimostra a tutti che fai cose vere e non marketing!

gabi.2437 ha scritto:

Vai ATI

Dimostra a tutti che fai cose vere e non marketing!

hai dimenticato KICKASS

per la cronaca: anche nvidia ha fatto uscire driver sperimentali con supporto OpenCL, non distribuibili al pubblico per ora. Bisogna vedere quanto impiegheranno per renderli pubblici, ma probabilmente l'uscita di ATi di ieri velocizzerà le loro mosse

cenit ha scritto:

per la cronaca: anche nvidia ha fatto uscire driver sperimentali con supporto OpenCL, non distribuibili al pubblico per ora. Bisogna vedere quanto impiegheranno per renderli pubblici, ma probabilmente l'uscita di ATi di ieri velocizzerà le loro mosse

[OT]
quanto mi piacerebbe vedere Rosetta che gira su GPU.....
Ma temo resterà un bel sperare, hanno specificato varie volte che l'overhead di lavoro sarebbe troppo...In teoria bisognerebbe fare un fork del codice, uno per la CPU e uno per la GPU (da scrivere quasi da zero) con due team distinti che se ne occupino (e due team pure su Ralph!!!) e che ogni tanto confrontino i risultati!! Un pò troppo per un progetto che cambia spesso codice e versione dell'applicativo.
[/OT]

Anche a me piacerebbe vedere rosetta su gpu, ma purtroppo è come hai detto tu...

Che opencl aiuti anche loro, però?

Non crediate che con openCL sia facile veder applicazioni sulla gpu

Riporto un passaggio di slicker (responsabile di collatz):

1. Requires x86 CPU with SSE3 support to run the apps. Does anyone besides me run Collatz on old hardware?

2. It also requires Visual Studio 2008 Professional in order to compile the apps. Prices range from $600-$750 USD. (That's the cost of 2 HD5870 cards!)

3. It doesn't support nearly as many cards as the ATI CAL libraries. HD 4600 or higher is the minimum from the looks of it.

4. BOINC doesn't support the "OpenCL" coprocessor class and since there are no OpenCL projects yet, it is probably pretty low on the priority list of things to add.

edit, nn me ne sono reso conto

Mi pare che tu abbia sbagliato thread =P

Dopo che la 6.10.14 è uscita, contenente molte novità, velocemente siamo passati alla 6.10.15 che contiene qualche bugfix in più.
Qui come sempre trovate tutte le applicazioni beta compilate:
boinc.berkeley.edu/dl/?C=M;O=D

Change log for 6.10.14

Rom 7 October 2009
- MGR: Fix the Statistics page Save/Restore project display feature.

Charlie 8 October 2009
- MGR: If aborting multiple tasks, ask "Are you sure?" only once.

Rom 16 October 2009
- client: Fix crash that was introduced 7 months ago. (From Nicolás Alvarez)

- client: remove redundant 0s in job log

- client: add --unsigned_apps_ok cmdline option and <unsigned_apps_ok> config option. This tells the client to allow unsigned apps. For testing. No file xfers or other network traffic will be allowed if set.

- client: add <exit_after_finish> option (same as cmdline flag)

- client: add <skip_cpu_benchmarks> option (same as cmdline flag)

- client: print message if abort past-deadline unstarted job

- client: improve message when have NVIDIA drivers but no GPU

- client: if anonymous platform description (app_info.xml) doesn't specify FLOPS for a GPU app, assume that it runs at CPU peak speed rather than GPU peak speed. Better to be conservative, otherwise job might be aborted due to time limit exceeded.

- client: on startup, if a coproc needed by a job is missing, set a "coproc_missing" flag rather than aborting the job. If use removes a GPU board while there's a large queue of GPU jobs, they'll stay queued (until their deadline passes).

Note: this doesn't fix the situation where user connects via Remote Desktop while GPU jobs are running or queued. We should check for Remote Desktop every minute or so, and stop GPU jobs.

- client: the get_all_projects_list() RPC doesn't require auth

- client: don't multiply checkpoint interval (i.e., "disk interval" pref) by # processors.

- actually, make it "Tasks checkpoint to disk at most every ..." and change it in the advanced prefs dialog too

- LIB: Make the is_remote_desktop compilable for all VS versions and SKUs.

- MGR: Fix initial first connection problem on startup. I'm not sure why it was only happening at startup, there might have been a few crashes because of this issue as well. The basic problem is that wxWidgets had an exception handler around the initial frame creation and when the first GUI RPC was issued to detect whether or not we were atached to an account manager during menu creation the GUI thread would go about doing idle processing while waiting for the GUI RPC thread to initialize. During this time the frame pointer is NULL and was getting dereferenced which would halt window construction and stay there until some other event was fired.

- MGR: Initial dose of code cleanup and shuffling. Order the menu functions in the order in which they are displayed in the menu.

- client: address the situation where GPUs become unusable for certain periods (e.g. when Remote Desktop is used on Win).

* add is_usable() member function to COPROC.

Currently this just calls the respective (CUDA or CAL) initialization function. We need to check whether this works and/or causes problems.

* in enforce_schedule(), check whether usability has changed for each GPU type.

If we've gone from usable to unusable, flag all jobs for that GPU as coproc_missing (so they won't get run, and will quit if they're running). If we've gone from unusable to usable, clear the flag.

This should deal with all cases except where the client is started up with GPUs unusable.

- client: bug fixes to the above. Don't fetch work for an unable resource.

- update cal.h to current ATI code

- client/scheduler: standardize the FLOPS estimate between NVIDIA and ATI. Make them both peak FLOPS, according to the formula supplied by the manufacturer.

The impact on the client is minor:

* the startup message describing the GPU
* the weight of the resource type in computing long-term debt

On the server, I changed the example app_plan() function to assume that app FLOPS is 20% of peak FLOPS (that's about what it is for SETI@home).

- client: the weight of GPU debt in computing total debt should be (estimated throughput of all GPUs)/(estimated throughput of all CPUs) rather than the ratio of 1 GPU to 1 CPU. This change will hopefully cause ratios of granted credit to more closely match resource shares.

- client: multi-thread jobs were being given too high priority; in particular, they were preempting jobs in the middle of time slice.

Solution:
1) don't use MT in the sort order defined by more_important().
2) add a 2nd reordering in which MT jobs are moved ahead of non-MT jobs, but only if #CPUs used is < #CPUs (see promote_multi_thread_jobs())

- client: the seqno of jobs in progress but not selected was being set to zero. It should be runnable_jobs.size(). This could potentially cause wrong scheduling decisions.

Tag for 6.10.14 release, all platforms boinc_core_release_6_10_14

Charlie 16 October 2009
- MGR: Fix build break on Mac

Changelog for 6.10.15
Major fixes for this release are:

1. Startup problems on reboot should be fixed. Everybody should reboot at least once and verify that the manager can start the client at logon.

2. The introduction of a limbo state when the GPU disappears. Task instances should error out if they go past deadline.

3. We introduced some code to detect Remote Desktop and to move GPU jobs into limbo until the user signs back into the console. The original detection code is where the .13 client was crashing, the new code doesn't appear to work correctly. If I can figure out what is going wrong I'll do another release for that.

Please give items 1 and 2 a few tries. Changing driver versions and that should trigger #2.

---

Riassumendo, tutte le novità principali riguardano la rilevazione dello status di Remote Desktop e di aggiornamento driver, condizioni che una volta causavano l'annullamento di migliaia di task per chi teneva grosse cache e che ora si vorrebbero risolvere: mentre il problema legato alla "scomparsa" della gpu durante un aggiornamento driver non dovrebbe più dar problemi, purtroppo il codice che rileva il remote desktop non funziona come si vorrebbe. Chiunque avesse suggerimenti è pregato di farsi avanti

E' uscita la Release Candidate 6.10.17. Se non sorgeranno gravi problemi, venerdì sarà pubblicata per tutti e diventerà la nuova versione consigliata. Risolti pochi piccoli problemi legati all'accessibilità per gli utenti con handicap e disabilitata definitivamente la retrocompatibilità con Windows 9x.

Tutti quanti possono fare l'upgrade sono invitati a farlo e a segnalare tutti i problemi riscontrati.

Ecco tutte le versioni:
Windows 32bit
Windows 64bit
Linux 32bit
Linux 64bit
Mac OS X Universal

cenit ha scritto:

Tutti quanti possono fare l'upgrade sono invitati a farlo e a segnalare tutti i problemi riscontrati...

no grazie, questa volta sto' ad aspettare che i problemi vengano risolti

OT on

bax ma per natale un pensierino ad una HD 5870 lo fai?

almeno superi quota 500k...

OT off

io sto provando la 6.10.17 e mi funziona bene come la 6.10.16...

Io ho la 6.10.7 e non la cambierò per un bel pò

cenit ha scritto:

Note: this doesn't fix the situation where user connects via Remote Desktop while GPU jobs are running or queued. We should check for Remote Desktop every minute or so, and stop GPU jobs.
[...]
- LIB: Make the is_remote_desktop compilable for all VS versions and SKUs.
[...]
- client: address the situation where GPUs become unusable for certain periods (e.g. when Remote Desktop is used on Win).
[...]
3. We introduced some code to detect Remote Desktop and to move GPU jobs into limbo until the user signs back into the console. The original detection code is where the .13 client was crashing, the new code doesn't appear to work correctly. If I can figure out what is going wrong I'll do another release for that.

Please give items 1 and 2 a few tries. Changing driver versions and that should trigger #2.

---

Riassumendo, tutte le novità principali riguardano la rilevazione dello status di Remote Desktop e di aggiornamento driver, condizioni che una volta causavano l'annullamento di migliaia di task per chi teneva grosse cache e che ora si vorrebbero risolvere: mentre il problema legato alla "scomparsa" della gpu durante un aggiornamento driver non dovrebbe più dar problemi, purtroppo il codice che rileva il remote desktop non funziona come si vorrebbe. Chiunque avesse suggerimenti è pregato di farsi avanti

Non ho ben capito da dove nasce il problema con il remote desktop, so che mi ci sono appena imbattuto con il mio nuovo eco-criceto che non ha ancora il monitor e contavo di pilotarlo dal vecchio criceto PIII tanto che mi ero sbattuto a scaricare remote desktop client per win2000.
Risultato: appena effettuo la connessione il carico della GPU va a zero e il log mi mostra il messaggio:
"ATI GPU has become unusable; disabling tasks"
la cosa ansiogena é che questo stato permane anche dopo un reset, bisogna proprio spegnere il PC e staccare la spina per ripristinare il tutto. Per un attimo ho pensato che si fosse fusa la ATI

Domanda: ho la 6.10.18, questo problema é stato risolto su versioni di sviluppo più recenti ?

Ri-domanda: é un problema generealizzato, cioé non risolvo neanche con VNC, o ci posso provare ?

astroale ha scritto:

Domanda: ho la 6.10.18, questo problema é stato risolto su versioni di sviluppo più recenti ?

Ri-domanda: é un problema generealizzato, cioé non risolvo neanche con VNC, o ci posso provare ?

io ho la 6.10.18 su XP32 e VISTA64 e piloto tranquilamente PC con CUDA e ATI in remoto, attraverso LogMeIn

non ho provato con altri software

astroale ha scritto:

cenit ha scritto:

Note: this doesn't fix the situation where user connects via Remote Desktop while GPU jobs are running or queued. We should check for Remote Desktop every minute or so, and stop GPU jobs.
[...]
- LIB: Make the is_remote_desktop compilable for all VS versions and SKUs.
[...]
- client: address the situation where GPUs become unusable for certain periods (e.g. when Remote Desktop is used on Win).
[...]
3. We introduced some code to detect Remote Desktop and to move GPU jobs into limbo until the user signs back into the console. The original detection code is where the .13 client was crashing, the new code doesn't appear to work correctly. If I can figure out what is going wrong I'll do another release for that.

Please give items 1 and 2 a few tries. Changing driver versions and that should trigger #2.

---

Riassumendo, tutte le novità principali riguardano la rilevazione dello status di Remote Desktop e di aggiornamento driver, condizioni che una volta causavano l'annullamento di migliaia di task per chi teneva grosse cache e che ora si vorrebbero risolvere: mentre il problema legato alla "scomparsa" della gpu durante un aggiornamento driver non dovrebbe più dar problemi, purtroppo il codice che rileva il remote desktop non funziona come si vorrebbe. Chiunque avesse suggerimenti è pregato di farsi avanti

Non ho ben capito da dove nasce il problema con il remote desktop, so che mi ci sono appena imbattuto con il mio nuovo eco-criceto che non ha ancora il monitor e contavo di pilotarlo dal vecchio criceto PIII tanto che mi ero sbattuto a scaricare remote desktop client per win2000.
Risultato: appena effettuo la connessione il carico della GPU va a zero e il log mi mostra il messaggio:
"ATI GPU has become unusable; disabling tasks"
la cosa ansiogena é che questo stato permane anche dopo un reset, bisogna proprio spegnere il PC e staccare la spina per ripristinare il tutto. Per un attimo ho pensato che si fosse fusa la ATI

Domanda: ho la 6.10.18, questo problema é stato risolto su versioni di sviluppo più recenti ?

Ri-domanda: é un problema generealizzato, cioé non risolvo neanche con VNC, o ci posso provare ?

devi solo aspettare qualche minuto, ogni tanto boinc riproverà a vedere se la scheda sarà tornata disponibile. Evidentemente il reboot a freddo fa impiegare tempo a sufficienza per il registro di boinc da far partire un nuovo scan.

Per evitare il problema, devi usare un remote desktop che non sostituisca il driver video in uso (come fa il remote desktop standard microsoft), ma ne faccia il mirror (è un metodo MOLTO meno efficiente dal punto di vista latenza e banda occupata, però compatibile con cuda/stream). Ci sono vari VNC, oppure Windows Live Mesh (che utilizza una versione modificata del remote desktop Microsoft in grado di sfruttare il mirror e con la quale mi trovo molto bene)

cenit ha scritto:

Per evitare il problema, devi usare un remote desktop che non sostituisca il driver video in uso (come fa il remote desktop standard microsoft), ma ne faccia il mirror (è un metodo MOLTO meno efficiente dal punto di vista latenza e banda occupata, però compatibile con cuda/stream). Ci sono vari VNC

provate ultravnc oppure teamviewer !

è uscito ATi Stream SDK v2.0
pieno supporto ad OpenCL 1.0 negli strumenti di sviluppo ATi (e nei driver 9.12-hotfix).

Prima di diventare perfetto, mancano qualche libreria (un migliore supporto ad ACML su tutti) e il supporto alla doppia precisione come estensione ufficiale di OpenCL 1.0 (per ora supportata solo in via sperimentale, naturalmente solo sulle schede che la supportano)

Per ora, si conferma che le uniche schede che vanno a velocità dignitose con OpenCL sono quelle della serie 5xxx

cenit ha scritto:

è uscito ATi Stream SDK v2.0
pieno supporto ad OpenCL 1.0 negli strumenti di sviluppo ATi (e nei driver 9.12-hotfix).

Prima di diventare perfetto, mancano qualche libreria (un migliore supporto ad ACML su tutti) e il supporto alla doppia precisione come estensione ufficiale di OpenCL 1.0 (per ora supportata solo in via sperimentale, naturalmente solo sulle schede che la supportano)

Per ora, si conferma che le uniche schede che vanno a velocità dignitose con OpenCL sono quelle della serie 5xxx

Da fan Ati dico: speremuz!!

cenit ha scritto:

è uscito ATi Stream SDK v2.0
pieno supporto ad OpenCL 1.0 negli strumenti di sviluppo ATi (e nei driver 9.12-hotfix).

Prima di diventare perfetto, mancano qualche libreria (un migliore supporto ad ACML su tutti) e il supporto alla doppia precisione come estensione ufficiale di OpenCL 1.0 (per ora supportata solo in via sperimentale, naturalmente solo sulle schede che la supportano)

Per ora, si conferma che le uniche schede che vanno a velocità dignitose con OpenCL sono quelle della serie 5xxx

Ottimo!!

cenit, visto che sei molto documentato su questo argomento, che ne dici di scrivere qualcosa da pubblicare sul portale?

cenit ha scritto:

Per ora, si conferma che le uniche schede che vanno a velocità dignitose con OpenCL sono quelle della serie 5xxx

Si accontentano di poco eh?

Cmq sono contento che il supporto si estenda, spero anche a schede ati meno potenti, così posso mettere al lavoro anche altre schede, qualora fossero supportate da progetti che mi piacciono, e spero che questo porti a una maggiore integrazione tra lo sfruttamento delle risorse del pc in modo che tutti i progetti possano sfruttare indipendentemente cpu e/o gpu (è così vero?)...