Quote:
Originariamente inviato da UltimateBou
[b]ah x erpazzo, beh si infatti come dicevo io al massimo può servire a chi lavora con 14" 15" o chi sul 17" non vuole andare a 60hz, ma per il resto chi gioca tranquillamente a 1280*1024 o 1600*1200 raramente andrà ad utilizzare questa funzione; tra l'altro, almeno fino ad ora, ho potuto constatare (sulla mia R8500, per le schede Nvidia che dicono gestisce molto meglio l'antialiasing, non so e quindi non mi esprimo) che un 800*600 (e molto spesso anche 640*480) con antialiasing al max (6x per le ati) e messi su quality, è abbastanza + lento di un 1280*1024 che si vede meglio (infatti non so se avete mai notato l'effetto "sfumatura" tipico delle basse risoluzioni, e corretto in qualche modo dall'antialiasing). Certo, ancora per quanto riguarda questa matrox non si può dire niente, ma per quanto possa essere rivoluzionaria, penso (magari il tempo mi smentirà) che bene o male si comporterà un pò come tutte le schede 3d hanno fatto fino ad ora... (parlo sempre della gestione dell'antialiasing con rapporto qualità/prestazioni). Quindi il succo del discorso è che è vero: ben venga una scheda che ti da qualità di 1600*1200 a 800*600, speriamo solo che lo faccia (a parità di dettagli, che io setto sempre al massimo possibile) ad una velocità adeguata... bye
|
Per chiarire il discorso, direttamente da ExtremeTech.
Per quanto riguarda (in parte) le performance:
ET: What kind of vertex/triangle throughput performance can we expect from Parhelia?
DW: With four 128-bit DirectX9.0 vertex shaders operating in parallel, the Parhelia is capable of very high programmable vertex throughput. Most of the instructions in the DX9.0 vertex shader 2.0 spec run on the Parhelia's ALUs in one clock. The raw vertex throughput for simple vertex operations is >100M vert/sec. The drawn triangle throughput is 37M front facing triangles per second. The reason for this discrepancy is that we have found that most apps are not actually T&L limited by the number of drawn triangles, but rather become T&L limited when long vertex shader programs are applied. So--like for many other aspects of the Parhelia--the focus is on sustaining performance for the complex case rather than simply bragging about large numbers in a simple, low-complexity case that won't actually be used. A more impressive triangle rate is that the Parhelia is capable of sustaining ~ 10 Mtri/sec in the case of 90- instruction-long programmable vertex shaders.
Questo è solo un esempio di come la potenza sarà sfrutta per migliorare la qualità dei giochi. Il Parhelia e' un'architettura che ingloba tante altre feature che hanno l'obiettivo di ottimizzare l'utilizzo delle risorse e sfruttare la potenza disponibile dove realmente serve.
Per quanto riguarda quanto dicevi sopra (risoluzioni e AA), questo dovrebbe chiarire qualunque dubbio in merito:
ET: Fragment Antialiasing is a different approach than FSAA to the problem of how to compensate insufficient pixel sample rate. Tell us what the important differences are, why you opted to go this route, what you gain, and what you lose.
DW: We're really excited about Fragment Anti-aliasing 16x (FAA16x), which we see as a unique approach to anti- aliasing. FAA16x operates on the principle that only pixels on the edge of a triangle need to be anti-aliased. The algorithm recognizes these pixels and treats them differently then interior pixels of a triangle. Our hardware actually looks at every pixel being rendered and checks to see if the pixel fully covers an entire raster element. If the raster element is fully covered, then the pixel is written to the back buffer as usual. If however, the raster element is only partially covered (which is typically the case on a polygon edge) than the level of coverage is calculated by the chip down to a 1/16th sub- pixel fragment, and this fragment value is written into a special fragment heap that is stored in local memory. As soon as another fragment is created that can be combined with the first to fully cover the raster element, the fragments are combined together to produce the correct result. This approach has the benefit that enabling 16x fragment anti- aliasing is typically only costing about 20-25% performance versus no anti-aliasing.
The other benefit is that very high resolutions can be anti- aliased without producing memory overflow problems. In particular, a 1600x1200 screen would require 3200x2400 32it pixels, or ~ 30MB of scratch buffer to perform traditional 4x supersampled anti-aliasing. But with only 10% of the pixels needing anti-aliasing, our FAA-16x may only require a few MB to perform higher quality anti-aliasing. Note also that for any given scene, the ratio of edge pixels to interior pixels decreases as the resolution increases. This means that the cost of FAA-16x goes down the higher the resolution, while the cost of other algorithms increases dramatically!
ET: Given that FAA operates on only 5-10% of pixels in a given scene, what kind of performance hit can we reasonably expect to see, particularly at high resolutions like 1600x1200 using say, 16X FAA?
DW: Our own internal tests have yielded performance hits of about 25% on average with FAA-16X enabled versus no anti- aliasing. This is compared to other vendors whose maximum quality anti-aliasing (only 4x) takes an average performance hit of around 60% at 1280x1024. I would like to point out that it would be fairly unnecessary to actually run 1600x1200 plus our FAA16x. The usual reason that people run apps at very high res is to get rid of the jaggies on edge pixels. The only other reason to run at high res is to achieve finer texture sampling, but the difference in texture detail between resolutions is fairly minor and hard for the untrained eye to notice--especially given that most content today does not provide textures greater than 1024x1024 in size. So, running at high resolutions like 1600x1200 is usually motivated primarily by jaggie reduction.
To look at effective jaggie-reduction, I like to think in terms of edge equivalent resolution (call it the EER since we're in an acronym filled industry) which is defined as the screen resolution multiplied by the anti-aliasing factor, and it represents the apples to apples comparison of edge anti- aliased samples. So, using FAA-16x at 1600x1200 produces an EER of 6400x4800 and this is probably overkill. Running at 1024x768 plus FAA-16x produces an EER of 4096x3072 which is actually greater than that produced by running other cards at 1600x1200 with 4X anti-aliasing (which gives an EER of only 3200x2400). So by running Parhelia at 1024x768 with FAA-16x you would produce better visual quality than running a different solution at 1600x1200 with 4X AA, and the Parhelia would absolutely demolish the competitor in terms of performance.
Penso che sia abbastanza eloquente.
P.S. Comunque, a parte i dati tecnici nudi e crudi sopra riportati (che parlano da sé), leggendo attentamente quanto riportato dal Corsini si poteva capire qual è l'obiettivo che si sono prefissi alla Matrox con il Parhelia...
P.P.S. Per GundamXYZ: per iniziare il quoting devi mettere una parentesi quadra aperta, poi la scritta QUOTE (anche in minuscolo dovrebbe funzionare se si tratta di qualcosa di simile ad HTML) e poi quella chiusa; per finire il quote devi fare lo stesso, ma anteporre a "QUOTE" il carattere slash (la barra di divisione). Allo stesso modo, se vuoi il testo in grassetto, anziché QUOTE usa B, se vuoi il corsivo usa I, ecc.
Saluti
-->Dio<--