Mixed NV3xpath doesnt support HDR in HL2?Who knows?

engall

Newcomer
Mixed NV3xpath doesnt support HDR in halflife2?Who knows?

The increased range that the full floating point precision DirectX9 pipeline required was utilised for the high dynamic range, which shows more “bloomingâ€￾ effects as bright light streams through openings, and surfaces that display different reflective properties giving them a more realistic look. As floating point precision is required for the HDR effects, architectures that have a mixed integer and floating point path will be at a disadvantage as only the floating point path can be utilised for these effects, and architectures that were designed to be fully float will be more efficient. High Dynamic Range will be enabled in the DirectX9 path of the game, however it requires floating point render target support so that DirectX9 graphics boards that do not have this enabled in the drivers will not be able to reproduce these photorealistic effects.

Only DirectX9 path of the game can support this feature?????
 
IIRC, the FX series can't do this in any mode at all. Could be wrong there, however. Someone more knowledgeable about this issue can confirm/deny that.
 
My understanding is as Pauls.

I thought that the FX hardware is able to do it but it has not yet been exposed in the drivers, so even running on the DX9 path the FX will not do HDR. As to whether it will ever be implemented in the mixed mode path (assuming that, if im correct, drivers do eventually support it.) I think its unlikley as it would only hurt FX performance even more (all IMHO)
 
PaulS said:
IIRC, the FX series can't do this in any mode at all.
AFAIK the FX series has this functionality (FP render targets), but there is currently no driver available that exposes this functionality.

As HalfLife 2 has FP render targets as a requirement for it's HDR rendering, the FX-series can not do this in any mode (DX9 or MixedMode) with currently available drivers.

There have been rumours that the hardware functionality may be broken (atleast in NV30) because it has been a long time since availability of the NV30, and the driver writers should have had enough time to implement it.

On this note:
Are the Det. 50s going to expose FP render targets?
 
mr said:
PaulS said:
IIRC, the FX series can't do this in any mode at all.
AFAIK the FX series has this functionality (FP render targets), but there is currently no driver available that exposes this functionality.

As HalfLife 2 has FP render targets as a requirement for it's HDR rendering, the FX-series can not do this in any mode (DX9 or MixedMode) with currently available drivers.

There have been rumours that the hardware functionality may be broken (atleast in NV30) because it has been a long time since availability of the NV30, and the driver writers should have had enough time to implement it.

On this note:
Are the Det. 50s going to expose FP render targets?

AFAIK, Det51.75beta doesnt support FP render targets!
And I wanna know that if NV drivers expose FP render targets,

Can Nv3x support HDR through Mixed Mode instead of Dx9 path in halflife2?


\\
 
AFAIK,

NV3x only supports a subset of what DX 9 requires for floating point render target support, and one of the things that has been proposed as supposedly being considered is another modification/exception in the API to allow exposure.

I believe the functionality in OpenGL is exposed as "RECT" type, but I don't know the specifics of issues for DX exposure that make this type restriction an issue.

Perhaps a lack of a suitable mechanism for reporting texture format restriction on type once the texture format capability has been reported, or API and code issues that would be caused/required by adding the capability to distinguish?

The issue for HL 2 seems to be that it implements HDR using floating point render targets, and that doing things another way would introduce even more issues than the nV3x has already caused and still not make sense because it would make the current performance problem even more acute.
 
Hi, I thought this was perfectly clear and I understood the situation, but... here's my problem;
Doom III supports HDR? Surely that was why Carmac was wanting 64bit+ colour? I know Doom III is supposed to be aimed at DX8 level hardware but I thought He was banging on about 64bit colour with regard to Doom or was it his next engine? So if Doom III supports 64bit colour therefore one would assume that the hardware can't be broken, and thus the functionality must be supported in the OpenGL drivers? however if this is true why are the DX drivers not supporting it? Does Doom III caculate HDR differently to HL2? HDR is High Dynamic Range in terms of lighting isn't it? or does Doom III not support floating point colour?

Eh?

EDIT: Above post was not there when I decided to post :rolleyes:
 
Sim Dietrich said:
FP32 textures are not supported yet due to WHQL issues.

The main problem, AFAIK, is that the WHQL test suites mistakenly require mip-mapping and texture wrapping to be supported on pow-2 fp32 textures, which the fx family does not support.

Microsoft is working very hard with nvidia to find a way to expose them to the development community in a WHQL'd driver. I estimate there will be a driver exposing these on the registered developer site within the month.
 
As far as i know even if they do enable HDR in the drivers then mixed mode wont run it

valve have stated that HDR requires full presion ps 2.0 shaders

mixed mode swaps alot of those for half pression
 
Ilfirin said:
Sim Dietrich said:
FP32 textures are not supported yet due to WHQL issues.

The main problem, AFAIK, is that the WHQL test suites mistakenly require mip-mapping and texture wrapping to be supported on pow-2 fp32 textures, which the fx family does not support.

Microsoft is working very hard with nvidia to find a way to expose them to the development community in a WHQL'd driver. I estimate there will be a driver exposing these on the registered developer site within the month.

This is where the proposed new texture format (or caps bit) comes in, it would effectively say any fp32 surfaces have no wrapping or mip-mapping. Perfect for NV3x and still very useful (many uses of fp32 surface only need simple access, using them as simple look up tables or render targets)

AFAIK its not simple a case of WHQL requiring wrapping but D3D, WHQL requires it for a very good reason. There is no way of telling which format would support which settings (without the new extension), which would put us back in the bad old days of guessing which format does what...

I hope they can work it out, so I can get some of my stuff working.

HDR could still work with partial precision pipelines, FP16 still has enough range for lights of several thousand standard brightnesses... Wether it would look o.k. in HL2 only Valve could say.
 
sir doris said:
Doom III supports HDR? Surely that was why Carmac was wanting 64bit+ colour?

As far as I can remember, the reason given was to have precision for lots of blending without banding.
 
sir doris said:
Hi, I thought this was perfectly clear and I understood the situation, but... here's my problem;
Doom III supports HDR? Surely that was why Carmac was wanting 64bit+ colour? I know Doom III is supposed to be aimed at DX8 level hardware but I thought He was banging on about 64bit colour with regard to Doom or was it his next engine? So if Doom III supports 64bit colour therefore one would assume that the hardware can't be broken, and thus the functionality must be supported in the OpenGL drivers? however if this is true why are the DX drivers not supporting it? Does Doom III caculate HDR differently to HL2? HDR is High Dynamic Range in terms of lighting isn't it? or does Doom III not support floating point colour?

Eh?

EDIT: Above post was not there when I decided to post :rolleyes:

Doom3 doesn't support HDR. Carmack wanted 64bit color for his next engine anway.

I'm sure NVIDIA cards will run HL2 with HDR if the drivers ever support it, but it will probably drop performance even more.
 
If HDR requires render targets, how big and how many would they be? What would they be used for, ie, how much extra rendering needs to be done and how much b/w would those 128bpp surfaces use up (that's the depth R300 supports for deep buffers, right)?

How much could this slow down a 9800 Pro? HL2 doesn't exactly run lightning fast as it is (60-ish FPS I believe).

Ok, this might be very difficult to answer, not knowing the specifics of the source engine and how it works "under the hood", but maybe knowledgeable people like Deano etc can give a guesstimate?


*G*
 
how much b/w would those 128bpp surfaces use up (that's the depth R300 supports for deep buffers, right)?

No more bandwidth than 4xAA... well, unless you plan to run AA with 128-bit surfaces in which case you'll crawl even if you have enough video memory spare to store them in.

Given that my 9500 Pro can run 60+ fps at 1280x960 with 4xAA, I doubt the bandwidth for floating-point non-AA rendering at similar resolutions is going to stress the 9800 Pro at 60fps... I'd imagine it's currently shader limited in HL2.
 
Archaeolept said:
I have a related, though minor question then.

The latest TechReport http://techreport.com/reviews/2003q3/chaintech-5600u/index.x?pg=6 benchs the rthdribl high dynamic range lighting demo. The FX 5600U does horribly, but it does run. Would this be in emulation, then, or is it not even creating the correct output?

Been asking the same question & referencing that demo (rthdribl) & the DX8 HDR demo (mshdribl) too. The answers I've recieved have pointed to the fact HDR can indeed be done in DX8: but Valve either doesn't know how or is too lazy to do it. :rolleyes: Granted it won't be as stunning as DX9 HDR, but it is better than no HDR in DX8-8.1.

The 'Chameleon' demo nV put out last year uses HDR effects too, IIRC.

.02,
 
Grall said:
how much extra rendering needs to be done and how much b/w would those 128bpp surfaces use up
If the shader's of any appreciable length, there's usually plenty of bandwidth to go round. 'Appreciable' is probably than you might think, as well.
 
just me said:
The answers I've recieved have pointed to the fact HDR can indeed be done in DX8: but Valve either doesn't know how or is too lazy to do it. :rolleyes: Granted it won't be as stunning as DX9 HDR, but it is better than no HDR in DX8-8.1.

Valve are busy producing a rather large game, utilising the most shaders of anything so produced so far - they are not producing a tech demo with a single purpose in mind. Full precision DX9 has a much greater range than previous versions, making it a natural choice for HDR - Radeon 9200 and less has a range of [-8,8] and GeForce FX PS1.4 [-2,2] and supporting these probably require much more work. The way they have implemented it also require float buffers, which isn't available pre DX9 and on some DX9 boards.
 
movieman said:
how much b/w would those 128bpp surfaces use up (that's the depth R300 supports for deep buffers, right)?
No more bandwidth than 4xAA... well, unless you plan to run AA with 128-bit surfaces in which case you'll crawl even if you have enough video memory spare to store them in.
Except that you get compression with AA.
 
Back
Top