Efficient HDR Pipeline implementation for NV4X GPUs

Started by
7 comments, last by LtJax 17 years, 8 months ago
I'm currently working on an HDR implementation for NV4X/G70 GPUs, and I was wondering what would the fastest way to do it be. I'm using Reinhard's tonemapping operator (as explained in the DX9 tutorial FarCry presentation). So far, I was thinking of doing the following: Render 64-bit image (heh, no questions there, FBO) Calculate log(luminosity) from it into an R16F texture (In Reinhard's first equation, I can only calculate log(delta+Lw), then do the multiplication by 1/n only once on the 1x1 texture, right?) use glGenerateMipmapsEXT() on that texture to get the 1x1 version Get LumAvg by getting exp(1x1oftexture) <--- HOW? shall I render a point and sample the texture and do an exp() in the shadeR? //////OPTIONAL based on LumAvg,do a bright pass to use for bloom and streaks. //////END OPTIONAL Tonemapping pass (how will I pass LumAvg to this? shall I sample it AT EVERY PIXEL? NVSDK has a DX sample with VTF, but I can't understand what it's doing,as I'm not into D3D. I'd appreciate any replies regarding this issue or more efficient approaches. I don't need to support anything other than the NV4X/G70 platform, so feel free to use any architecture-specific features :). TIA [Edited by - Starfox on August 9, 2006 11:46:36 PM]
Holy crap I started a blog - http://unobvious.typepad.com/
Advertisement
bump
Holy crap I started a blog - http://unobvious.typepad.com/
Try HDR Pipeline demo form Microsoft DirectX SDK. It has everything explained. Translating the shaders to OpenGL is not difficult.
if (time() == $) { $ = 0; }
That demo is made to run on the bare minimum dx9 class H/W (not taking advantage of NV4X), and there's more to it than just the shaders. I have the bloom and light streak shaders running, it's the API use I'm after (ex, use PBOs to async read ast frame LumAvg? keep LumAvg on card and pass DeltaTime to shader?) etc.

In short, No, that demo WON'T cut it, I'm afraid.
Holy crap I started a blog - http://unobvious.typepad.com/
I'm not so sure that glGenerateMipmapsEXT is the best way to do the downsampling. For one it is potentially slower since it only uses a 2x2 box filter to generate the whole mipmap chain and not a 4x4 or even bigger one.
Of course this needs to be benchmark'ed to prove the idea.
The second reason is that it could skip a quite big amount of your screen if in the final value if your screen size is not a power of two. I don't actually have proof that it does that, but I seem to remember that the spec says that sizes are rounded down - so a 3x4 could eventually be rounded down to a 1x2 in the next level and you omit a third of your pixels for the final average. Experiments I've done with this also seem to indicate that this is in fact the case.
Can anyone confirm this?!
Holy crap I started a blog - http://unobvious.typepad.com/
well, the spec on FBOs says that manual mipmap generation will generate the same data as automatich mipmap generation.
and the gl2 spec says:
"The contents of the derived arrays are computed by repeated, filtered reduction
of the levelbase array. No particular filter algorithm is required, though a box filter is recommended as the default filter"

so it seems there's no guarantee that it's an average. from my own implementation, the values I generated with manual mipmap generation were also slightly different from those I generated by downsampling myself.
How different? what was the difference in the value of the 1x1 texture?
Holy crap I started a blog - http://unobvious.typepad.com/
Quote:Original post by Starfox
How different? what was the difference in the value of the 1x1 texture?

usually around 5-10% of the value - probably because the downsampling was missing parts of the image.


This topic is closed to new replies.

Advertisement