PDA

Visualizza Versione Completa : Macpro e Lightwave 9.6



Solferinom
27-03-09, 20:22
Non vorrei affondare nell' OT, magari se vuoi approfondire apriamo un topic ad'hoc. Dunque, diciamo innanzi tutto che l'indirizzamento possibile in un sistema a 32bit sono poco più di 3Gb non 2, ...ma quello che reputo più importante è l'assegnazione del velore "segment memory limit", questo valore infatti dev'essere portato alla soglia minima per allocare un frame buffer tale che ti consenta di renderizzare in un'unica passata, senza frammentazioni, per accellerare i tempi di rendering. Portarlo a valori superiori, non solo non produce benefici in tal senso, ma addirittura è deletereo a quanto ne so, perchè sottrae di fatto delle risorse che portebbero esser sfruttate diversamente dal sistema.

Riguardo la Ram, non metto in dubbio la qualità della memoria di sistema fornita da Apple, ...ma per esperienza posso dirti che non esiste purtroppo un prodotto esente da problemi, congeniti o posticci che siano. Io un test lo farei in ogni caso, anche se non so indicartene uno adatto ai Mac, ma sono certo che qui qualsiasi altro utente della mela potrà fare meglio di me in questo senso. ;)

Spero tu risolva al più presto.
F.


Ciao Fire...ho proseguito qui la discussione per non "inquinare" quella relativa al "core".
Dunque...ma non era il contrario per il Memory limits? Ossia assegnando n valore basso allocava meno ram al rendering e quindi frammentava l'immagine in tanti pezzi che renderizza uno alla volta, mentre impostando un valore più alto per il memory limit l'immagine viene renderizzata in un unico passaggio...(almeno a me funziona così).

Non intendevo dire che la Ram Apple è esente da problemi. Volevo dire solo che, oltre ai 2GB di Ram Apple ho anche 8GB di Ram Kingston...che qiano quelli a creare problemi?
Vedo se riesco a trovare qualche test per la RAM online e vi faccio sapere...
Ciao, marcello.

Fire
27-03-09, 22:37
Ciao Fire...ho proseguito qui la discussione per non "inquinare" quella relativa al "core".
Dunque...ma non era il contrario per il Memory limits? Ossia assegnando n valore basso allocava meno ram al rendering e quindi frammentava l'immagine in tanti pezzi che renderizza uno alla volta, mentre impostando un valore più alto per il memory limit l'immagine viene renderizzata in un unico passaggio...(almeno a me funziona così).

Non intendevo dire che la Ram Apple è esente da problemi. Volevo dire solo che, oltre ai 2GB di Ram Apple ho anche 8GB di Ram Kingston...che qiano quelli a creare problemi?
Vedo se riesco a trovare qualche test per la RAM online e vi faccio sapere...
Ciao, marcello.
Ciao Marcè,
hai fatto bene a splittare l'argomento, così possiamo parlare con calma.
Dunque, riguardo alla "memoria segmentata" la risposta e ..."si e no", ...ma mi spiego meglio.

Da quanto ne so, questo valore indica al Sw quanta memoria allocare al frame buffer per renderizzare una determinata scena, quindi se indico ad esempio un valore inferiore al necessario, il Sw è costretto ad allocare più frame buffer (i vari "pezzi" in cui viene divisa l'immagine durante il rendering) per ovviare alla mancanza di Ram necessaria a visualizzare il rendering.

Il valore necessario per renderizzare in un'unica passata ovviamente cambia a seconda delle dimensioni dell'immagine impostate nei settaggi della camera. Quindi, per farmi capire meglio, se per esempio a 1024x768 avremo bisogno di allocare 150Mb di Ram e se per 2048x1536 ne dovremo occupare 300Mb, e invece ne lasciamo impostati 150Mb, in questo caso il Sw renderizzerà l'immagine in 2 pezzi ansichè in uno solo perchè abbiamo impostato la metà della Ram necessaria al rendering in singola passata. Se viceversa dobbiamo invece renderizzare, supponiamo, a 1024x768 e allochiamo 300Mb, tutto filerà liscio, il sistema renderizzerà in un'unica passata, perchè la Ram che gli abbiamo messo a disposizione eccede addirittura la sua necessità, ...ma è anche vero che avremo allocato 150Mb in più ...inutilmente!

Questo porta alla conclusione a cui volevo arrivare, ossia se volessimo ottimizzare il sistema, dovremo quindi impostare il valore minimo che consente a LW di poter renderizzare in un'unica passata l'immagine alla risoluzione impostata nei parametri di camera. Se renderizziamo a risoluzioni diverse e se volessimo lasciare al sistema tutta la Ram disponibile, dovremo ad ogni cambio di risoluzione, trovare il valore minimo necessario al rendering in singola passata per quella risoluzione.

Ecco perchè dico che è sbagliato impostare il valore piu alto che il sistema permette nel segment memory limit e scordarsene. Perchè un valore ad es. di 2Gb di Ram ti permetterà indubbiamente di renderizzare sempre in un unica passata, essendo spropositatamente alto, ...ma è anche vero che toglierà risorse che invece sarebbero servite ad altro.

Spero d'essermi riuscito a spiegare ...perchè sono un pò tortuoso nell'esprimermi. :D
Fabio.

DM67
27-03-09, 22:45
La mia scheda video è la NVIDIA GeForce 8800 GT 512 Mb di ram.

Comunque, visto che hai installato altro tipo di memoria, Fire potrebbe aver centrato il problema ... anche sull'allocazione della memoria che fai in LW, devi assegnarne lo stretto necessario.

In passato anch'io ho installato le Kingston, sul mac precedente, senza avere problemi, ma non si sa mai, i sistemi operativi evolvono, cambiano le CPU e le architetture, chi lo sa come si possono comportare certe componenti?

Tony

Solferinom
27-03-09, 22:59
Ecco perchè dico che è sbagliato impostare il valore piu alto che il sistema permette nel segment memory limit e scordarsene. Perchè un valore ad es. di 2Gb di Ram ti permetterà indubbiamente di renderizzare sempre in un unica passata, essendo spropositatamente alto, ...ma è anche vero che toglierà risorse che invece sarebbero servite ad altro.

Spero d'essermi riuscito a spiegare ...perchè sono un pò tortuoso nell'esprimermi. :D
Fabio.

Capito perfettamente.
ma quando dici "toglierà risorse che invece sarebbero servite ad altro" intendi che magari altri software avrebbero bisogno di un pò di Ram utilizzata da lightwave? Perchè se è questo non ci sono problemi...ammesso che Lightwave utilizzi tutti e 2 i GB di RAM assegnatagli, gli altri software hanno comunque altri 8GB restanti da utilizzare.
Ma non potrebbero i programmatori di Lightwave far si che il software utilizzi solo ed esclusivamente la RAM che al momento gli occorre senza rendere macchinoso e "manuale" questo procedimento?? ossia...per il rendering mi occorrono 200MB? Ne utilizzo 200MB...!!

xTony: Anche io ho la Geforce 8800GT 512MB. Sinceramente non ho mai avuto problemi con le RAM Kingston con il precedente Macpro "quad core"!! Ma un Test lo farei volentieri, a trovarlo!!

Fire
27-03-09, 23:30
ma quando dici "toglierà risorse che invece sarebbero servite ad altro" intendi che magari altri software avrebbero bisogno di un pò di Ram utilizzata da lightwave? Perchè se è questo non ci sono problemi...ammesso che Lightwave utilizzi tutti e 2 i GB di RAM assegnatagli, gli altri software hanno comunque altri 8GB restanti da utilizzare...
Con "toglierà risorse al sistema", intendevo a qualsiasi applicazione, (Lightwave stesso in primis, visto che è a 32bit) che ne avesse bisogno.


... Ma non potrebbero i programmatori di Lightwave far si che il software utilizzi solo ed esclusivamente la RAM che al momento gli occorre senza rendere macchinoso e "manuale" questo procedimento?? ossia...per il rendering mi occorrono 200MB? Ne utilizzo 200MB...!!
"L'automatismo", se così lo vogliamo chiamare, consiste per ora solo nell'auto-segmentazione dell'immagine durante il rendering in caso di valori impostati troppo bassi, (come quello di default che se ben ricordo è fermo ai valori della Ram di una volta, 32Mb se non erro, se nella 9.6 non è stato finalmente aggiornato), che consente al Sw di eseguire comunque il rendering, se pur a pezzi.

Certo come tu dici potrebbe esserci un'atomatismo più sofisticato che assegna il valore ottimale di memoria per il rendering single-pass a seconda della risoluzione di camera e che lasci comunque anche la possibilità d'impostazione manuale. Diciamo che ad oggi, con la migrazione verso i 64bit e con la Ram in perenne calo, questo valore ha perso un pò l'importanza che invece aveva una volta.

Riguardo la Ram, non starei li a gurdare la marca, Kingstone è certamente uno dei miglior produttori, ma di certo qualche "ciambella senza buco" può sempre esserci, (a me è successo anche con delle costosissime Corsair), ...ve lo dico da assemblatore, può capitare con qualsiasi OEM. Ovviamente le percentuali che succeda variano a seconda che si tratti di prodotti più o meno di marca, ma la marca di per se non rende esente da simili problemi.

Ragion per cui, un bel test e ci togliamo anche questo dubbio...
F.

skipintro
28-03-09, 10:25
Sinceramente non ho mai avuto problemi con le RAM Kingston con il precedente Macpro "quad core"!! Ma un Test lo farei volentieri, a trovarlo!![/QUOTE]

Ciao Solferinom non sò se questo ti sarà di aiuto
http://www.macupdate.com/info.php/id/15837

Fire
28-03-09, 11:36
Il "problema" di avere meno diffusione di applicazioni di "automedicazione" (:D) nel mondo Mac, (come possono esser considerati i test sulla Ram), è legato a diversi motivi, in primis senza dubbio la maggior qualità dei componenti e relative certificazioni di Apple, ma anche forse alla natura degli utenti che nel mondo dei PC compatibili sono un pò più abituati a far da sè e ad utilizzare di meno i service, dico questo in virtù dell'esperienza e dell'amicizia che mi lega ad un concessionario Apple locale.

Dunque, a prescindere dalla validità del test che ha cortesemente segnalato Skipintro, (:rolleyes: che a quanto m'è parso di capire più che altro fornisce di una GUI un comando di sistema), ...quello che si potrebbe fare in mancanza d'altro e disponendo della quantità di Ram di cui dispone Solferinom, sarebbe quello di identificare preventivamente un'operazione che, in modo sistematico (e non estemporaneo, ...è importante), mandi in crash il sistema e poi, con la santa pazienza :D, testare i banchi individualmente o al limite, magari a coppie di 2, in modo da individuare quelli che eventualmente fanno "il doppio gioco".

E' certamente un modo più rognoso di risolvere ma ...a estremi mali... :)

F.

Solferinom
28-03-09, 13:10
Skypintro...avevo scaricato qualcosa del genere (almeno il test mi pare lo stesso), ma funzionante da terminale, senza quindi "interfaccia" come questo e tra l'altro era a pagamento (anche se solo 1,39$)...si tratta di "Memtest"...e i "controlli" sono praticamente gli stessi che vedo nel "resoconto" del Rember...

Il processo mi pare comunque molto lento...ma molto lento.
Ad esempio quando calcola gli "Stuck Address" parte da 1/16 e fa (1/16 - 2/16 ......16/16) ma per passare ad esempio da 1/16 a 2/16 non impiega certo 1 secondo!!! quindi è lentissimo...
Immaginate poi quando comincia a calcolare 1/64, 1/256, 1/512.....spero non voglia arrivare sino a 10.000MB facendo 1/10.000 altrimenti è da suicidio!!!

facendo fare un solo ciclo con rember pare sia più veloce perchè fa solo il 1/16.
Ho allocato prima 2GB ed il risultato e nella prima fase del test (poi cominciano i "solid nits" 1/64, ecc..) non risulta nulla di strano, se non che mi dice "Ram Avaiable 9015MB....e non 10.000!!!

trascrivo la prima parte del test effettuata su 2GB:

Memtest version 4.2 (64-bit)
Copyright (C) 2004 Charles Cazabon
Copyright (C) 2004, 2005, 2006 Tony Scaminaci (Macintosh ports)
Licensed under the GNU General Public License version 2 only

Mac OS X 10.5.6 (9G55) running in single user mode
Memory Page Size: 4096
System has 8 Intel processor(s) with SSE
Requested memory: 2000MB (2097152000 bytes)
Available memory: 9015MB (9452920832 bytes)
Allocated memory: 2000MB (2097152000 bytes) at local address 0x0000000101000000
Attempting memory lock... locked successfully
Partitioning memory into 2 comparison buffers...
Buffer A: 1000MB (1048576000 bytes) starts at local address 0x0000000101000000
Buffer B: 1000MB (1048576000 bytes) starts at local address 0x000000013f800000

Running 1 test sequence... (CTRL-C to quit)

Test sequence 1 of 1:

Running tests on full 2000MB region...
Stuck Address : setting 1 of 16setting 1 of 16ok
Running comparison tests using 1000MB buffers...
Random Value : \ ok
Compare XOR :  ok
Compare SUB :  ok
Compare MUL :  ok
Compare DIV :  ok
Compare OR :  ok
Compare AND :  ok
Sequential Increment:  ok


Vedete dove dice "Attempting memory lock... locked successfully"?...Bene...quando alloco tutta la RAM o comunque 10GB...in quella riga accade questo:


Memtest version 4.2 (64-bit)
Copyright (C) 2004 Charles Cazabon
Copyright (C) 2004, 2005, 2006 Tony Scaminaci (Macintosh ports)
Licensed under the GNU General Public License version 2 only

Mac OS X 10.5.6 (9G55) running in single user mode
Memory Page Size: 4096
System has 8 Intel processor(s) with SSE
Requested memory: 9017MB (9455239168 bytes)
Available memory: 9017MB (9455239168 bytes)
NOTE: Memory request is too large, reducing to acceptable value...
Allocated memory: 8764MB (9190492416 bytes) at local address 0x0000000101000000
Attempting memory lock... WARNING: Testing with unlocked memory may be slower and less reliable

ERROR: Memory lock failed - reason unknown.

Partitioning memory into 2 comparison buffers...
Buffer A: 4382MB (4595246208 bytes) starts at local address 0x0000000101000000
Buffer B: 4382MB (4595246208 bytes) starts at local address 0x0000000212e5e480

Running 1 test sequence... (CTRL-C to quit)

Test sequence 1 of 1:

Running tests on full 8764MB region...
Stuck Address : setting 1 of 16



mi riferisco a questo:

"Attempting memory lock... WARNING: Testing with unlocked memory may be slower and less reliable

ERROR: Memory lock failed - reason unknown."

ERROR!!!!! Ora...quale sarà dei 6 banchi quello/i che non va/vanno?

Fire
28-03-09, 15:01
Il fatto che il test non riesca a bloccare la Ram non vuol dire però implicitamente che ci sia qualcosa che non va nei moduli, (anche se è possibile). Credo che a questo punto, valga la pena di far le prove come ti avevo consigliato nel post precedente, ossia installando uno o due moduli per volta e riprovando. Se al posto del test hai un'applicativo che sistematicamente fallisce, è ancor meglio, perchè ti sbrighi prima.

F.

Solferinom
28-03-09, 15:06
no, non è una cosa "sistematica", nel senso che me lo ha fatto qualche volta con lightwave e con scene che necessitano di un quantitativo di Ram superiore. ma non ho riscontrato questo difetto con altri software.
il test è quasi finito....ma ci sta impiegando (settato su un solo ciclo e per tutta la RAM) quasi 3 o 4 ore!!! Se devo farlo per ogni coppia di moduli da testare...stiamo freschi.:)

Solferinom
28-03-09, 15:19
Risultato del test sulla RAM:


"Test Results

All tests passed!

Total built-in memory: 10 GB


This is the total amount of physical memory that the computer has installed. If this figure is not showing the correct amount of memory there may be a problem with one or more installed DIMMS.

Available memory: 9017 MB

Available memory is the amount of physical memory that is currently not in use by any other processes. All available memory will be used for testing when the "All" option is selected. To increase the amount of available memory, you can restart your computer before testing. If you are familiar with the command line (CLI), you can run memtest (the core of Rember) in single-user mode. See Rember help, or http://www.memtestosx.org for more information.

Requested amount: All MB

The total amount of memory requested for testing by the Rember application. Not all requested memory can be allocated for testing. See information on "Available memory" for more information.

Memory allocated for testing: 8764 MB

This is the total amount of memory that memtest was able to allocate for testing. See "Available memory" section for more information.

-------

Loops selected: 1

Total loops selected by user for testing. All loops should complete when testing is successful. Test failure when the "Continue on Error" preference is selected will cancel tests before this number of loops has been completed. Users can also cancel testing before this number is reached.

Loops completed: 1

Total loops completed by memtest. Note that the Rember is not always able to identify how many loops ran. If there are discrepancies between this and the loops selected, the log should be examined to determine exactly how many loops were performed.
-------

Total execution time: 7332 seconds

This is the total amount of time that it took to execute the selected tests. Execution time may vary from system to system, and is provided as a guide for determining how long users can expect tests to run based on the amount of memory installed on the system.

Testing start time: 2009-03-28 13:09:46 +0100

Testing end time: 2009-03-28 15:12:02 +0100
"



mi sbagliavo, ha impiegato circa 2 ore...
Strano che non abbia allocato tutti e 10 i GB di RAm per il test!!
In ogni caso sembra aver avuto successo...a meno che la falla non stia proprio in quella Ram che NON ha considerato..:) (che culo!!)..:)

Fire
28-03-09, 15:22
Si ...infatti, sarebbe improponibile :rolleyes:. Mi sa che a questo punto tocca aspettare di trovare un test più serio, ...nel senso di velocità ed affidabilità.

Nel frattempo sarebbe opportuno trovare il valore minimo di memoria con cui LW ti renderizza in un'unica passata la risoluzione che usi più di frequente, ...magari così avendo più Ram a disposizione del sistema e di LW, può esser che non ti si pianta più, (...sempre ammessa "l'innocenza" dei moduli Ram :D).

F.

***Edit:
...abbiamo postato in contemporanea, ma visto gli aggiornamenti, ...credo proprio serva un'altro Test.