Listen, Fuad says Doom3 "owns" on Nvidia.

[digitalwanderer]

PaulS, I think Mako was joking.

I don't, I think he was trying to make a burn and failed rather utterly at it!

Mebbe I should wait to start posting until I grow-up too?

 

[martrox]

Mebbe I should wait to start posting until I grow-up too?

You're never gona grow up, DG.........

 

[WolfsBane58]

PaulS, I think Mako was joking.

I don't, I think he was trying to make a burn and failed rather utterly at it!

Mebbe I should wait to start posting until I grow-up too?

The heck with that... I'm not growing up until my wife's father grows up.... Oh wait... thats never going to happen either!!!...

 

[Quitch]

PaulS, I think Mako was joking.

At 11 posts I doubt it. It's the common Internet insult used by those with no actual counter-argument, the petulant and the sulky

 

[volt]

AFAIK NV3x will be running ARB2 path by default -- the scores should come out interesting when compared to R3x0.

 

[BRiT]

AFAIK NV3x will be running ARB2 path by default -- the scores should come out interesting when compared to R3x0.

AFAIK NV3x drivers will be replacing ARB2 path with fp16 path by default.

 

[KimB]

I believe the precision in the "ARB2" path is determined by whether one uses the "nicest" or "fastest" hint. I was pretty sure that the default was, "nicest."

 

[Richard]

JC said he's letting GFFX's use fp16 throughout in the ARB2 path.

 

[KimB]

JC said he's letting GFFX's use fp16 throughout in the ARB2 path.

Which would make plenty of sense. I don't think DOOM3's doing anything complicated enough to need better than FP16 (of course, remember that texture addressing always uses FP32 on the NV3x).

 

[FUDie]

JC said he's letting GFFX's use fp16 throughout in the ARB2 path.

Which would make plenty of sense. I don't think DOOM3's doing anything complicated enough to need better than FP16 (of course, remember that texture addressing always uses FP32 on the NV3x).

How can this be true? If you store an FP16 value and use that for a texture address, it's still FP16.

-FUDie

 

[Ostsol]

JC said he's letting GFFX's use fp16 throughout in the ARB2 path.

Which would make plenty of sense. I don't think DOOM3's doing anything complicated enough to need better than FP16 (of course, remember that texture addressing always uses FP32 on the NV3x).

How can this be true? If you store an FP16 value and use that for a texture address, it's still FP16.

-FUDie

If you sample the texture using an input register, the precision of the texture address is the same as the interpolaters'. As such, even Radeons, which do everything else at FP24 in the pixel pipeline, sample textures using FP32 addresses. Heck, even a lowly Radeon 8500 with its FX12 precision probably samples textures with FP32 addresses. The same is true with Geforces, regardless of the precision hints. However, if you take the texture address, put it into a temporary register, and then sample the texture, what you have is a texture address whose precision is the same as the register's (as well as a dependant texture read).

EDIT: I actually experimented with this on my R300, comparing the images produced by a normal texture read and a dependant texture read. There was a clear difference, showing that addresses for normal texture reads used a higher precision. I think it's quite safe to assume that precision is FP32.

 

[FUDie]

JC said he's letting GFFX's use fp16 throughout in the ARB2 path.

Which would make plenty of sense. I don't think DOOM3's doing anything complicated enough to need better than FP16 (of course, remember that texture addressing always uses FP32 on the NV3x).

How can this be true? If you store an FP16 value and use that for a texture address, it's still FP16.

-FUDie

If you sample the texture using an input register, the precision of the texture address is the same as the interpolaters'. As such, even Radeons, which do everything else at FP24 in the pixel pipeline, sample textures using FP32 addresses. Heck, even a lowly Radeon 8500 with its FX12 precision probably samples textures with FP32 addresses. The same is true with Geforces, regardless of the precision hints. However, if you take the texture address, put it into a temporary register, and then sample the texture, what you have is a texture address whose precision is the same as the register's (as well as a dependant texture read).

I know what a dependent texture read it. Please read my post again.

Maybe you should reply to Chalnoth, not me.

-FUDie

 

[Ostsol]

I know what a dependent texture read it. Please read my post again.

Maybe you should reply to Chalnoth, not me.

-FUDie

I don't see what's wrong with Chalnoth's statement. The samplers always use FP32 precision addresses, though they can obviously accept FP16 data. It's just like moving an FP16 value into an FP32 register.

 

[FUDie]

I know what a dependent texture read it. Please read my post again.

Maybe you should reply to Chalnoth, not me.

-FUDie

I don't see what's wrong with Chalnoth's statement. The samplers always use FP32 precision addresses, though they can obviously accept FP16 data. It's just like moving an FP16 value into an FP32 register.

It's not 32 bit if the source data is not 32 bit. Chalnoth's statement was "texture addressing always uses FP32", which is not correct.

-FUDie

 

[Ostsol]

I don't see what's wrong with Chalnoth's statement. The samplers always use FP32 precision addresses, though they can obviously accept FP16 data. It's just like moving an FP16 value into an FP32 register.

It's not 32 bit if the source data is not 32 bit. Chalnoth's statement was "texture addressing always uses FP32", which is not correct.

-FUDie[/quote]
That's obvious, though. I think you're taking his statement too literally. I doubt that Chalnoth is so ignorant to not realize this.

 

[FUDie]

I don't see what's wrong with Chalnoth's statement. The samplers always use FP32 precision addresses, though they can obviously accept FP16 data. It's just like moving an FP16 value into an FP32 register.

It's not 32 bit if the source data is not 32 bit. Chalnoth's statement was "texture addressing always uses FP32", which is not correct.

-FUDie

That's obvious, though. I think you're taking his statement too literally. I doubt that Chalnoth is so ignorant to not realize this.

If Chalnoth feels obliged to chime in with completely irrelevant tidbits, I can certainly nitpick.

-FUDie

 

[volt]

Though half precision seems sufficient enough as JC states.

Question: Your .plan indicates that the NV30-path that you use implements only 16-bits floating-point (FP), i.e. half precision FP, for most computation, which should be sufficient for most pixel shading. The ARB2-path does not have 16-bits FP, and so all computation are done with 32-bits FP on the NV30. With regards to the R300, there shouldn't be a difference since it is always 24-bits FP on the R300. According to your .plan, NV30 is twice as slow on 32-bits FP - that is why the NV30 is slower than the R300 on the ARB2-path, but faster on the NV30-path. The question is what sort of quality difference are we talking about (in DOOM3) for such a difference between FP formats?

Answer: There is no discernable quality difference, because everything is going into an 8 bit per component framebuffer. Few graphics calculations really need 32 bit accuracy. I would have been happy to have just 16 bit, but some texture calculations have already been done in 24 bit, so it would have been sort of a step back in some cases. Going to full 32 bit will allow sharing the functional units between the vertex and pixel hardware in future generations, which will be a good thing.

http://www.beyond3d.com/interviews/jcnv30r300/index.php?p=2

 

[Hanners]

Mebbe I should wait to start posting until I grow-up too?

You're never gona grow up, DG.........

Beyond3D's very own Peter Pan.

 

[Quitch]

A worthy title replacement for village fool