High Dynamic Range su 9800pro

[Eraser|85]

Salve a tutti.

Leggevo proprio oggi una news sull'imminente rilascio di Lost Coast, ovvero quella specie di mappa-espansione per hl2, con supporto all'HDR (high dynamic range appunto).

Visto che non ero sicuro del supporto di tale feature sulla 9800pro, ho dato un occhiata su web. Da quanto ho capito la 9800pro supporta il floating point solo a 24bit, mentre il formato OpenEXR utilizzato per gestire l'HDR fa ricorso al FP16.

Su FarCry questo vieta di poter usare l'HDR sulle schede ati precedenti alla serie X, e se si attiva cmq l'hdr viene usato una specie di "approssimazione" che aggiunge un effetto di bloom alle luci e aumenta leggermente la luminosità.

Su hl2 c'è una specie di "hack" per abilitare l'hdr ma a quanto ho potuto notare è un semplice effetto bloom, proprio come a FarCry o World Of Warcraft.

La domanda è, ne sapete di più su questa storia dell'hdr?

[fek]

Originariamente inviato da Eraser|85

Salve a tutti.

Leggevo proprio oggi una news sull'imminente rilascio di Lost Coast, ovvero quella specie di mappa-espansione per hl2, con supporto all'HDR (high dynamic range appunto).

L'HDR e' abilitato (a meno di sorprese) solo su 6800. Se e' anche abilitato su GPU ATI vuol dire che non e' HDR in senso stretto, ma solo un'operazione di marketing.

Visto che non ero sicuro del supporto di tale feature sulla 9800pro, ho dato un occhiata su web. Da quanto ho capito la 9800pro supporta il floating point solo a 24bit, mentre il formato OpenEXR utilizzato per gestire l'HDR fa ricorso al FP16.

Quando si parla di fp24 ci si riferisce alla precisione dei calcoli usata nel motore di esecuzione degli shader (all'interno delle pipeline) il cui risultato di solito e' scritto su superfici con 8 bit per canale (ARGB).

Quando si parla di HDR che necessita' il pieno supporto allo standard fp16 si parla di supporto al rendering verso superfici con 16 bit per canale (sempre ARGB).

Purtroppo c'e' molta confusione a riguardo e i due concetti vengono spesso confusi fra di loro.

A confondere ulteriormente le idee, l'R3X0 e' in grado di renderizzare verso superfici fp16, ma non e' in grado di effettuarci sopra le operazioni di alpha blending, cosa che rende l'implementazione di rendering HDR teoricamente possibile, ma molto molto costosa, e di fatto non possibile in tempo reale su scene che non siano molto molto semplici.

La serie NV4X supporta il rendering verso superfici fp16 e le operazioni di alpha blending su di esse.
Sembra che l'R520 supportera' pienamente il rendering verso superfici fp16.

Per superfici si intende anche il framebuffer che non e' altro che l'immagine renderizzata che poi andra' sullo schermo.

[ATi7500]

Originariamente inviato da fek

A confondere ulteriormente le idee, l'R3X0 e' in grado di renderizzare verso superfici fp16, ma non e' in grado di effettuarci sopra le operazioni di alpha blending, cosa che rende l'implementazione di rendering HDR teoricamente possibile, ma molto molto costosa, e di fatto non possibile in tempo reale su scene che non siano molto molto semplici.

La serie NV4X supporta il rendering verso superfici fp16 e le operazioni di alpha blending su di esse.
Sembra che l'R520 supportera' pienamente il rendering verso superfici fp16.

Per superfici si intende anche il framebuffer che non e' altro che l'immagine renderizzata che poi andra' sullo schermo.

forse è una domanda stupida, ma R3x0 è capace di fare alpha blending su superfici fp24?

bYeZ!

[fek]

Originariamente inviato da ATi7500

forse è una domanda stupida, ma R3x0 è capace di fare alpha blending su superfici fp24?

bYeZ!

Ne' ATI ne' NVIDIA supportano il rendering verso superfici fp24 (solo fp16 e fp32), quindi non supportano il blending.

[ATi7500]

Originariamente inviato da fek

Ne' ATI ne' NVIDIA supportano il rendering verso superfici fp24 (solo fp16 e fp32), quindi non supportano il blending.

ecco la confusione di cui parlavi prima..confondevo la precisione usata per gli shader con quella per le superfici grazie del chiarimento

bYeZ!

[Eraser|85]

però scusa, 8bit per canale (in un rendering con RGBA ci sono 4 canali) corrisponderebbe a 32bit totali..

se si parla di FP16 con 16 bit per canale equivarrebbe a 64bit totali e FP32 a 128bit totali?

Quindi non sarebbe più opportuno chiamarlo FP8?? ovvero 8bit per canale -> 32bit totali (come nelle tga con alpha channel)


Inoltre, l'FP16 delle ati è quindi una cosa incompleta? Cioè che senso ha 16bit per canale se poi non puoi sfruttare il canale di trasparenza per farci l'alpha blending? A cosa potrebbe servire questo canale quindi?

Ogni tanto mi diletto nella programmazione OpenGL ma ancora non sono arrivato a concetti del genere.. mi limito semplicemente a usare texture a 8bit/canale (RGBA) e qualche effetto di trasparenza spicciola...

[fek]

Originariamente inviato da Eraser|85

però scusa, 8bit per canale (in un rendering con RGBA ci sono 4 canali) corrisponderebbe a 32bit totali..

se si parla di FP16 con 16 bit per canale equivarrebbe a 64bit totali e FP32 a 128bit totali?

Si'.

[quote]
Quindi non sarebbe più opportuno chiamarlo FP8?? ovvero 8bit per canale -> 32bit totali (come nelle tga con alpha channel)[quote]

Si chiama FX8 perche' non e' un formato in floating point, ma in fixed point a 8 bit per canale.

Inoltre, l'FP16 delle ati è quindi una cosa incompleta? Cioè che senso ha 16bit per canale se poi non puoi sfruttare il canale di trasparenza per farci l'alpha blending? A cosa potrebbe servire questo canale quindi?

Si' puo' essere considerata incompleta, in realta' lo scopo di questa implementazione non era fare HDR, ma fornire un render target ad alta precisione per cose come il calcolo della fisica all'interno della GPU.

Il canale alpha non e' solo usato per la trasparenza, e' semplicemente un'informazione in piu' che puo' essere associata ad ogni frammento; il suo significato dipende dall'applicazione.
Ad esempio noi usiamo spesso il canale alpha per indicare se un determinato frammento dev'essere processato dal filtro di blooming ed in quale misura.