Eila capo, non ti preoccupare, ho letto tutto... ;)
Sto un po' incasinato col lavoro... quanto prima faccio un post riassuntivo... :D

Ciao.

certo che usano la gpu, è fatto apposta :)
diciamo che la gpu aiuta la cpu nelle operazioni.
non l'ho mai usato quando avevo la x1900GT, ma usavo xp x64 che non supporta avivo converter, ma è un ottimo tool per chi ha queste vga.

Le informazioni che ho trovato girovagando per la Rete dicono l'esatto contrario, tanto è vero che taluni furbetti hanno sbloccato una versione per farla funzionare su qualsiasi sistema. Pare che il tool faccia un semplice check della GPU, ma poi usi solo la CPU. Potrei portarti decine di link a riguardo: tu riesci a portarmene uno solo che avvalori la tua tesi (che sarei ben felice di sposare)? :fagiano:

http://www.news3d.eu/index.php?PHPSE...s;art=990;pg=6

http://babgvant.com/blogs/andyvt/arc...-to-WMVHD.aspx

"I checked my GPU temp while running an AVIVO conversion of a wmv file to mpeg 4, it doesn't budge, stays at my standard idle temp of 65degs C so I am pretty certain this is NOT using the GPU, also my CPU was 100% use by CLI.exe during the conversion. All in all I am highly dissappointed by this misleading convertor."
"ATI has stated in interviews that the Avivo transcoder utility currently does NOT use the GPU and that future version will use the GPU for hardware assist.
In other words, its 100% software and CPU (plus X1000 series GPU even though it is not used and stands as an artificial limitation) for now and X1000 assisted later.
This point was illustrated clearly by a hacked and leaked version of the ATI AvivoXCode utility that would work on any system regardless of GPU,…. nVidia or ATI (X1000 series not needed)."

Da http://www.rage3d.com/board/archive/...-33848376.html

Potrei continuare all'infinito... :fagiano:

Infatti so anch'io che questo avivo video converter era una bufala, la gpu in realtà non veniva toccata.

http://www.tomshw.it/graphic.php?gui...o_purevideo-12
Ce n'è per tutti i gusti... :muro:

beh, tom's e' parecchio di parte... :rolleyes:

Ciao, da quanto ne so io l'AA di R100 e R200 è sostanzialmente lo stesso, e questo quindi implica che:
-) sono entrambi realizzati tramite super-sampling (e questo lo si sa :D)
-) la modalità qualità di entrambi filtra maggiormente le texture (tramite filtro anisotropico).
Una differenza sostanziale, però, è data da come i due chip scelgono il livello di dettaglio (mipmap) da applicare agli oggetti: date un'occhiata al link http://www.techreport.com/articles.x/3266/7

A proposito delle speculazioni circa l'utilizzo (o meno) dell'unità di blending, ricordo anch'io di aver letto quell'articolo di sharky extreme ma penso che il redattore abbia preso un abbaglio: in modalità supersampling, i 4 subpixel che vengono generati sono in realtà pixel veri e propri che solo in un secondo tempo saranno mescolati in un solo pixel; quindi, se quello che dice il redattore è vero, le TMU e l'unita di AB di una singola pipeline di R100 dovrebbero essere in grado di lavorare su 4 pixel diversi contemporaneamente. Mi pare difficile...
Allora, qui possiamo avere le seguenti modalità:
-) disabilitato (o application select): le texture vengono filtrate con filtro bilineare e, se richiesto dall'applicativo, con quello trilineare e/o anisotropico;
-) modalità performance: l'anisotropico viene applicato ignorando le eventuali richieste di filtraggio trilineari da parte dell'applicazione (in pratica, il chip calcola aniso+bilinear forzandolo su tutti i layer di texture);
-) modalità quality: l'anisotropico viene applicato ignorando le eventuali richiesta di filtraggio trilineari da parte dell'applicazione tranne che per il primo layer, dove viene usato il filtro trilineare (in pratica, il chip calcola aniso+trilinear sul primo layer e aniso+bilinear forzandolo su tutti i rimanenti layer di texture);

Da questo si evince che la migliore qualità possibile la si raggiunge lasciando impostare il filtro anisotropico all'applicazione. ;)

Novità? :fagiano:

Domani ho l'intera giornata libera :D Piuttosto con il discorso TNT, al quale invece mi sono dedicato, non c'è stato verso.

Cioè? Non parte il fill-rate tester? Se è per l'errore relativo alle DX9, è probabile che il bench funzioni solo sotto win2000/XP (con le DX9 installate).
Tu l'hai provato sotto Win98, vero?

Ciao.

Inizialmente no, sotto a Xp.

Beh, dimentichi lo sparse grid sampling programmabile di R200 e derivati, che consente una qualità superiore rispetto all'ordered grid fisso di R100. Tra l'altro, per R100 sono disponibili solo le modalità 2X e 4X, mentre per R200 sono selezionabili 2X, 3X, 4X, 5X e 6X.

Se è come dici, il tutto non tocca l'ottimizzazione dipendente dall'angolo della superficie interessata, che probabilmente è hardwired: mi sa che gli ingegneri ATI hanno introdotto una modalità angle independent solo in R520 e derivati.

Può essere, ma la CPU al 100% e la GPU "fredda" sono dati oggettivi, riscontrati da più parti.

senza dubbio, sul fatto che il converter NON usi la gpu siamo tutti d'accordo. su quel sito pero' c'e' comunque parecchia roba che non mi torna.

No, non lo dimentico: il fatto è che la millantata programmabilità dell'AA di R200 non si è mai contretizzata e non è mai stata esposta via driver.
As esempio, il TemporaryAA (che usa proprio la programmabilità del motore AA) non è mai stata attivato su R200 ma solo su R300 e derivati.

Riguardo alle modalità intermedie (3X, 5X e 6X), il punto è che cambiava solo la risoluzione a cui l'immagine veniva inizialmente renderizzata, nulla di più... per esempio, ricordo che in origine anche il GF256 DDR con driver detonator 5.22 permetteva di scegliere queste modalità intermedie, che poi sono scomparse con altre versioni di driver.

Ciao. :)

Infatti è proprio così: la dipendeza dall'angolazione rimaneva costante con tutte le modalità di AF (anche con quella "super" attivabile via tweaker e che forzava il driver a usare sempre il aniso+trilinear). Tempo fa su Beyond3D si ipotizzava che tale scelta potesse essere stata fatta per risparmare transistor sul chip e non tanto per migliorare le prestazioni (e infatti R520 non perde poi molto con l'AF HighQuality).

Ciao. :)

Ma sei sicuro? Questo è quanto dichiara ATI nel suo documento ufficiale circa la prima implementazione di Smoothvision (R200):

"ATI’s implementation of anti-aliasing provides a substantial improvement over other forms of anti-aliasing found in other GPUs. Instead of shifting every pixel in the same direction, groups of pixels can be individually shifted in different directions. This technique can be used to generate a more random distribution of pixel samples, leading to higher quality anti-aliased images.
SMOOTHVISION™ uses a large group of 16-sample blocks that cover a variable number of pixels, which is determined by the level of anti-aliasing being implemented. Each pixel within every group of 16 samples has their actual sample positions selected from a pre-programmed 8-sample jitter table.
As the level of anti-aliasing is increased, each 16-sample block will cover a smaller number of pixels. For example in the 2x anti-aliasing case, a total of 8 pixels are covered by the 16 sample group, and in the 4x case, a total of 4 pixels are sampled 4 times each.
A non-ordered pixel sampling approach provides the optimal solution, since the eye has a much harder time seeing artifacts in the resulting anti-aliased image, being less sensitive to non-ordered sampling patterns.
High-Quality SMOOTHVISION™ anti-aliasing uses a different texture color per sample, providing superior image quality compared to other competing anti-aliasing techniques, as a greater amount of color data is used to create the final anti-aliased image. Combined with superior sampling pattern of SMOOTHVISION™, the High-Quality SMOOTHVISION™ provides users with an unparalleled anti-aliasing solution.
High-Performance SMOOTHVISION™ anti-aliasing uses a jittered sample pattern for high-quality jagged edge removal, combined with an advanced sample blending and filtering algorithm. This advanced algorithm allows SMOOTHVISION™ to take fewer samples per pixel by blending in samples from other outside pixels. This results in a High-Performance anti-aliasing setting, while maintaining a level of image quality very similar to competing anti-aliasing solutions."

Ricordo anch'io che tale processo non era impiegato nelle prime versioni di driver, ma poi mi sembrava che la cosa fosse stata corretta. Magari non avranno sfruttato tale "jittered sampling pattern" per implementare anche il temporal AA (comunque inutile su tale fascia di prodotto, troppo lento oltre che superato), però la differenza rispetto a R100 (che, secondo me, usa un classico supersampling AA di tipo ordered grid) dovrebbe comunque sussistere.
Per questo mi chiedevo se le considerazioni che ATI illustra circa la differenza tra le due modalità di AA (qualità vs. prestazioni) per R200 potessero essere valide anche per R100 o meno, con le dovute proporzioni e differenze.
Per tagliare la testa al toro, domani metto alla prova la mia 7500 e la mia 9250 con SS:SE e le varie modalità di AA: se la seconda filtra meglio della prima, dovrei essere in grado di accorgermene.
Onestamente, infine, questo abbinamento che fai tra AA e AF non l'ho mai sentito prima (del resto, per l'AF c'è l'apposita voce nel pannello): dove lo hai beccato? :stordita: