Newsgroup: it.comp.hardware.video-3d
Titolo: R520 e' realmente una scheda shader model 3.0?

A quanto pare non supporta il vertex texturing.
"one element of Vertex Shader 3.0 compliance is the capability for vertex 
texturing, yet there appears to be an absence of any texture lookup 
capabilities from ATI's diagrams above"
http://www.beyond3d.com/reviews/ati/r520/index.php?p=02
bye bye displacement mapping:-) 

 
http://www.beyond3d.com/reviews/ati/r520/index.php?p=02
leggi bene:
ATI's statement is that to engineer Vertex Texturing in a non-unified 
architecture to a point were it is actually usable and beneficial would 
require so much die for extra texture caching and other associated elements 
that it would be very costly for the frequency that it is likely to be used, 
and that cost would have inevitably come at the detriment to something else; 
instead ATI are looking to leverage the pixel pipeline more for such vertex 
operations.
traduzione:
realizzazre il vertex texturing in una architettura senza shaders unificati 
in maniera che sia utilizzabile avrebbe richiesto troppo spazio per l'extra 
memorizzazione delle texture e per gli elementi associati che sarebbe molto 
penalizzante per la frequenza alla quale queste cose accadrebbero se il vs 
venisse usato
e questo costo in performance inevitabilmente andrebbe a scapito di 
qualcos'altro
in pratica dicono che se non ci son gli shader unificati, sarebbe solo uno 
spreco di prestazioni, un pò come quando dicevano che nv40 era troppo lento 
per avvantaggiarsi degli sm 3.0 con soluzioni come l'hdr e che prima che gli 
sm 3.0 venissero sfruttati minimamente, sarebbe passato nv40 e sarebbero 
arrivate le schede ati sm 3.0
guarda te se han mai raccontato frottole

 ha scritto nel messaggio 
news:43458560$0$29543$4faf...@reader1.news.tin.it...
ma guarda, proseguendo nella lettura si scoprono cose interessanti:
"Part of the point of vertex texturing is to be able to expose pixel format 
data to the vertex shader, and as somewhat of an alternative to Vertex 
Texturing ATI will be promoting the use of a new extension to DirectX known 
as Render to Vertex Buffer. As the name implies Render to Vertex Buffer 
(R2VB) allows all of the operations within the pixel shader to be utilised, 
but rather than rendering to a displayable surface or texture the results 
are rendered to a buffer in memory that can be directly read as an input to 
the vertex shader. "
quindi non è che non supporta il vertex texturing, semplicemente lo fanno in 
una maniera diversa, invece di fare il rendering direttamente sulla texture 
(che come hanno spiegato prima è sconsigliato su architetture non shaders 
unificati per l'extra texture caching), fanno il render in un buffer che poi 
può essere letto direttamente da un vertex shaders
altro che non farlo, lo fanno in una maniera migliore tramite una estensione 
delle directx chiamata "render to vertex buffer"
"The upshot of this process is that an application can have access to the 
capabilities of the Pixel Shader which can then be fed back into the 
geometry processing pipeline, which should result in a superset of 
capabilities of vertex texturing and should actually perform better than 
current vertex texturing schemes because the pixel pipelines are inherently 
built to better cope with the latencies of texturing."
la cosa graziosa di questo metodo è che l'applicazione può avere accesso 
alle capacità del pixel shader il quale può mandare l'output alle pipeline 
di elaborazione geometrica, tutto questo risulta in un super set di capacità 
di vertex texturing ed attualmente performerebbe MEGLIO dell'attuale vertex 
texturing perchè le pixel pipelines son costruite per fronteggiare meglio 
con le latenze del texturing
evvai, un altra soluzione geniale da ati, si vede che si son dati un gran da 
fare per progettare una signora gpu :)

 delle directx chiamata "render to vertex buffer"
C'è un inconveniente non trascurabile: a differenza di OpenGL, in 
DirectX non sono supportate le estensioni proprietarie, quindi 
l'implementazione del Render To Vertex Buffer richiede l'intervento di 
Microsoft con una nuova versione di DirectX.
Ciao,
Jena

 ha scritto nel messaggio 
news:LCx1f.17959$133....@tornado.fastwebnet.it...

se anche fosse, tra qualche mese (q1 2006) rilasceranno le nuove
anche se non so se render to vertex buffer non sia un estensione già 
supportata
in ogni caso non esistono giochi che usino il vertex texturing e non ce ne 
saranno per un grosso periodo di tempo
quindi che inconveniente sarebbe?
quando ci saranno i giochi che lo useranno, ci son già le gpu per sfruttarlo 
nel modo migliore 

Giusto per completezza di informazione, c'è un'altra feature 
interessante di NV4X che manca nelle R5X0: il filtering sulle texture 
floating point.
http://www.beyond3d.com/reviews/ati/r520/index.php?p=03
At present ATI see the primary use of float texture sampling as being 
for lookup data, which only requires point sampling, and so at present 
haven't put floating point texture filtering in place, instead relying 
on filtering in the shader if required - at present the developer has to 
code this, however if they have a demand for it they may roll it up into 
the driver.
Attualmente nessuno sviluppatore ha ancora mai usato texture FP (l'unica 
applicazione che le usa, se non sbaglio, è ShaderMark nei test con HDR), 
per cui la necessità di operare su dati FP è limitata al riutilizzo di 
dati già elaborati, per i quali è sufficiente un normale campionamento 
senza filtraggio.
La soluzione di backup prevista da Ati in caso di necessità è quella di 
fare il filtraggio nei pixel shader (con un prevedibile grosso calo di 
prestazioni), ma per il momento il compito di implementare tale 
soluzione è lasciato agli sviluppatori. In caso di bisogno, Ati 
implementarà il filtraggio tramite pixel shader direttamente nei driver.
Come paragone, tutte le NV4X operano su texture floating point allo 
stesso modo in cui operano su texture normali (point sampling, bilinear, 
trilinear, anisotropic). Questo dipende dal fatto che le ALU che si 
occupano del filtering sono condivise con quelle dei pixel shader, per 
cui sono già tutte floating point.
Ciao,
Jena

 however if they have a demand for it they may roll it up into the driver.
se un domani dovesse esserci richiesta, questo può essere incluso nei driver 

 magari senza traducendo meglio, si capisce anche meglio, no?
              ^^^^
typo:
come dovrebbe essere chiaro, togliere il "senza" residuo di un cut and paste


Lo avevo notato, grazie comunque per la conferma.
http://groups.google.it/group/it.comp.hardware.video-3d/msg/be8f094c93fdafb2
Sono slide commerciali attentamente studiati a tavolino dove niente viene 
lasciato al caso.

 allego una traduzione più precisa, e meno fluorviante:
Ok, ma non credo che la mia traduzione "libera" fosse tanto fuorviante.
Ciao,
Jena