Writing an update article to the Editor's Day coverage

[Dave Baumann]

Is ShaderMark flawed then?

Jakub - this is like asking "Is Tomb Raider: Angel of Darkness is flawed because it has float buffer support that doesn't work on FX cards?".

As OpenGL guys points out Range is one of the most important things when dealing with HDR.

 

[Rolf N]

Can someone familiar with OpenGL confirm these floating point render target restrictions by NVIDIA?

no filtering (infact, only GL_NEAREST or GL_NEAREST_MIPMAP_NEAREST)
no alpha test
no alpha blend
no logic op
no dither

Additionally, NVIDIA only allows floating point textures to be used only with NV_texture_rectangle (this means no mipmaps at all here) and fragment programs.

Confirmed

Also, "no logic op" seems like a very general restriction. Care to give an example of what it could entail? Right now it seems like almost anything...

Logic op in GL indeed refers to something very specific. Instead of blending, you can opt for a range of 'logic' functions, eg performing a bitwise XOR between the incoming pixel and the one already in the frame buffer.

It's not terribly useful at all nowadays, and pretty much pointless for floating point formats, so this isn't a big loss IMO.

For the whole shebang you can download the spec and take a look at page 182 (Acrobat Reader insists it's page 195; you'll understand when you try it).

 

[Arun]

In your initial article you said that Huang made the comment along the lines that "ATI is obsessed with NVIDIA and has engineers looking at their IQ problems and then they tell people at Shader day".

I'd just like to point out that this was not the point of ATI's Shader day at all and ATI did no such thing there. The only people that made any claims about NVIDIA issues at Sahder Daye and/or IQ were in fact Valve, and given the surprise from the ATI personel about the presentation Valve actually gave they weren't expecting that at all.

Once again, if the emperor has no clothes, but that he shoots the messenger - what are you going to tell him?

Check your PMs.


Uttar

 

[Neeyik]

Slightly off topic but I had emailed the author of RTHDRIBL when the demo was released, asking him various questions. I've unfortunately lost the original but some things that I do remember are that all releveant shaders are marked with the _pp hint; average number of passes is over 40 (assuming all effects are being used) and that INT render targets are used for the FX range, but require conversions to/from floats for the shader inputs/ouputs.

 

[Xmas]

Pete -> FX12 and FP16 precision is the same (10bits)

Actually, FP16 is more precise than FX12 in the [-1, 1] range, and equally precise in the [-2, -1] and [1, 2] ranges.

 

[Tridam]

A) R350/360 don't have a problem with PS2.0 and instruction limits that I'm aware of aren't they actually like 65k???

A). OK, so I've heard 64, 96, and 160 so far... and now 65k This just gets easier with every passing hour.

IIRC, Radeon can handle 32 texture ops and 64 ALU ops (-> 96 ops). The 64 must comes from the number of loopback that a pixel can do in the pipeline.

As Radeons can do a vector and a scalar operation at the same time, if they use 64 loopbacks, they can do 128 ops. -> 128 + 32 = 160 ops. OpenGL seems able to use this possibility but not DX9.

65k is for VS 2.0.

 

[Tridam]

Pete -> FX12 and FP16 precision is the same (10bits)

Actually, FP16 is more precise than FX12 in the [-1, 1] range, and equally precise in the [-2, -1] and [1, 2] ranges.

Arg I had forgot that the exponent is part of [-1,1] numbers.

 

[Jakub]

I'd just like to point out that this was not the point of ATI's Shader day at all and ATI did no such thing there. The only people that made any claims about NVIDIA issues at Sahder Daye and/or IQ were in fact Valve, and given the surprise from the ATI personel about the presentation Valve actually gave they weren't expecting that at all.

I'll be sure to make that distinction, trust me.

I'm really rather annoyed at the stilted mud-slinging, and I should have questioned that statement more since it's obvious NVIDIA wouldn't want to admit that a dev was slinging mud, instead of ATI.

 

[tb]

The number of updates, corrections and interesting comments to add is getting absurd.

Two last issues I'd like to clear up:

a). Supposedly the F-Buffer allows R350/R360 class hardware to run without an instruction limit, at least in OpenGL 2.0. Is it the miracle cure-all, and if so, is it something PS 3.0/DX10 will be able to take advantage of?

b). Brandon brought to my attention the interesting ShaderMark results (scroll down, you'll see a lot of failures on NVIDIA's part.) These results might mirror Valve's problems with NVIDIA hardware, I thought, and I brought it up with NVIDIA, here's the answer I got:

Floating point render targets make HDR implementation easier and more developer-friendly; however, it is possible to achieve high dynamic range using 16-bit (and even 8-bit) integer render targets, with some extra shader (and developer) legwork; notice how the high dynamic range effects in Masaki Kawase's RTHDRIBL demo run correctly on GeForceFX hardware, despite running with the same set of texture formats and render targets that are available to Shadermark. In fact, one of the primary HDR texture storage formats used in off-line rendering (Radiance's RGBE) is just 8-bits per component.

Here is a description and download link to said demo.

Is ShaderMark flawed then?

Current NV3x VPU and their drivers don't support 16 bit 3 or 4 component formats like D3DFMT_A16B16G16R16F / D3DFMT_A16B16G16R16. They support D3DFMT_G16R16 and D3DFMT_V16U16 as textures, but no > 8 bit format is supported as a render target. So you have to do HDR on the gffx using the old DX8 way, which means use the alpha channel for the overbright values. Before the ShaderMark v2.0 development started I asked NVIDIA's Doug Rogers about this issue and he statet they will add support for fp textures / rt in the 5x.xx drivers.

>Can you tell me a release date, when NVIDIA's detonator 50.xx will be 
>released?
Currently this is slated for fall.  No exact date.

>These should be the first detonators with fp texture support for dx9!?
Yes, that is the plan.

>What about multi element textures ?
Those will be supported.

-Doug


-----Original Message-----
From: Thomas Bruckschlegel [mailto:thomas@tommti-systems.com] 
Sent: Monday, July 14, 2003 8:35 AM
To: Doug Rogers
Subject: dx9 fp textures - when ?


Hi!

Can you tell me a release date, when NVIDIA's detonator 50.xx will be 
released? These should be the first detonators with fp texture support for 
dx9!? What about multi element textures ?

Best Regards,
Thomas
 -- 
Senior Editor / Lead Programmer

ToMMTi-Systems (http://www.tommti-systems.com)
ShaderMark (http://www.shadermark.com)

Thomas

 

[Jakub]

Current NV3x VPU and their drivers don't support 16 bit 3 or 4 component formats like D3DFMT_A16B16G16R16F / D3DFMT_A16B16G16R16. They support D3DFMT_G16R16 and D3DFMT_V16U16 as textures, but no > 8 bit format is supported as a render target. So you have to do HDR on the gffx using the old DX8 way, which means use the alpha channel for the overbright values.

Which goes in line with the results of the RTHDRIBL demo, that defaults to E8R8G8B8. So pardon the stupid question, but is E8 what is used to make overbrights happen, in place of the alpha channel? How can you do transparency in that case?

 

[tb]

There is no E8R8G8B8 format in dx9, only A8R8G8B8 and X8R8G8B8. Alpha blending isn't used in the RTHDRIBL demo (at least, I don't know where, maybe you better ask masa@daionet.gr.jp), because if you don't have correct alpha values in the alpha channel, it may look wired.

Thomas

 

[OpenGL guy]

Current NV3x VPU and their drivers don't support 16 bit 3 or 4 component formats like D3DFMT_A16B16G16R16F / D3DFMT_A16B16G16R16. They support D3DFMT_G16R16 and D3DFMT_V16U16 as textures, but no > 8 bit format is supported as a render target. So you have to do HDR on the gffx using the old DX8 way, which means use the alpha channel for the overbright values.

Which goes in line with the results of the RTHDRIBL demo, that defaults to E8R8G8B8. So pardon the stupid question, but is E8 what is used to make overbrights happen, in place of the alpha channel? How can you do transparency in that case?

Not all transparency effects require destination alpha. The alpha used in blending can come from different sources: Diffuse color, a texture, the render target, or simply computed in the shader. Of course, not all blending modes even use alpha. For example ONE/ONE is a common blending mode used to add two results together. Other blend modes use things like SRCCOLOR/INVSRCCOLOR so, again, alpha is not needed at all.

 

[Jakub]

There is no E8R8G8B8 format in dx9, only A8R8G8B8 and X8R8G8B8. Alpha blending isn't used in the RTHDRIBL demo (at least, I don't know where, maybe you better ask masa@daionet.gr.jp), because if you don't have correect alpah values in the alpha channel, it may look wired.

Thomas

Well, for whatever reason, RTHDRIBL shows E8R8G8B8. I also would have thought that alpha blending would be necessary to get the glare to wash over an object like this.

 

[Jakub]

Not all transparency effects require destination alpha. The alpha used in blending can come from different sources: Diffuse color, a texture, the render target, or simply computed in the shader. Of course, not all blending modes even use alpha. For example ONE/ONE is a common blending mode used to add two results together. Other blend modes use things like SRCCOLOR/INVSRCCOLOR so, again, alpha is not needed at all.

OK you just answered the qustion I had below

 

[Dio]

"Alpha Blending" != "Destination Alpha"

In fact, use of destination alpha is reasonably rare.

 

[Jakub]

"Alpha Blending" != "Destination Alpha"

In fact, use of destination alpha is reasonably rare.

[ignorance exposed]

So what, exactly, does that entail for NVIDIA? Not having alpha blending isn't a big deal?

 

[demalion]

There are 4 components for common color processing and processing storage: Red, Green, Blue, and "something".

"Alpha" is one usual name for that "something" (RGBA), associated with alpha channel blending as done in some image compositing programs.

It is also a term that can be used for "alpha blending", and the alpha component related to that can be used for an exponent ("RGBE").

The use is defined by what the shader decides to use it for, don't let the labelling confuse you. Actually, that extends to R, G, and B as well, but we're not discussing that much at the moment really.

As I mentioned before, using RGBE ties up that fourth component. The issue for that is the complications it might introduce for doing other effects along with implementing HDR, even aside from the issue of how well it does do HDR, because other effects might have been implemented efficiently using it.

EDIT: clarified some muddle.

 

[Jakub]

Alright, could you give me an example of an alpha effect that might interfere with this implementation of HDR?

I assume the most obvious is transparency, like a model of a man turning into a ghostly shape?

 

[Althornin]

Thanks OGL guy, you just clued me in (I think... no more quick conclusions.)

This is exactly what i was trying to tell you with my "flippant remark".

Your remark I took very seriously, it was someone else's flippant "you are asking the wrong questions" comment that irritated me. I mean great, what's that supposed to mean. Here I am, humbling myself, asking for help in order to help my readers, and what I got in return was a snide comment simply telling me that I'm still doing the wrong thing, without any hint about what the right thing might be.

Look, it wasnt meant as abuse - you ARE asking the wrong questions. Sorry, i'd rather force people to figure out what the problem is rather than just give them an answer - especially those who are writing articles on the subject. You need to figure out the right questions to ask on your own.

Sure, you are asking questions, thats great. But i answered the way i did because your flippant/quick assumption that you were told the truth/useful information by nVidia bothers me. Someone writing articles needs to do research and be a little less trusting, imo.

 

[Jakub]

Sure, you are asking questions, thats great. But i answered the way i did because your flippant/quick assumption that you were told the truth/useful information by nVidia bothers me. Someone writing articles needs to do research and be a little less trusting, imo.

Your remark didn't contribute at all. You didn't say anything useful, you just criticized and didn't offer an alternative.

For the record:

A). I didn't ever assume NVIDIA was telling the truth.
B). I posted what I did, presented NVIDIA's point of view, and then asked a question to spark discussion.
C). YOU, personally, took it to mean that's what I believe.

If I implicitly believed what they told me, I wouldn't be posting it here and asking for commentary, would I?