Mixed NV3xpath doesnt support HDR in HL2?Who knows?
- Thread starter engall
- Start date
Vortigern_red
Newcomer
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)
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)
AFAIK the FX series has this functionality (FP render targets), but there is currently no driver available that exposes this functionality.PaulS said:
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,
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.
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
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
Ilfirin said:
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.
horvendile
Regular
sir doris said:
As far as I can remember, the reason given was to have precision for lots of blending without banding.
Archaeolept
Newcomer
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?
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?
StealthHawk
Regular
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
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 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*
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:
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.
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,
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.
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.
OpenGL guy
Veteran
Except that you get compression with AA.movieman said:
