Sorry to those that don't want to see another NV30 thread; although technically this isn't about NV30 as a product but the CineFX architecture. As you know NV have been giving a few conference calls and I was involved on the same one NVMax was yesterday, I just wasn't sure on embargo/NDA details until now and I've been given the go ahead to talk about it.
I'm not going to reiterate the mainstay of the presentation at this time as it's the same as we've heard about from other people who've been on a CC and much of it is public information from SIGGRAPH already - I'll save it for the actual NV30 preview/review. However, I asked a number of questions at the end (actually, I was the only one asking Q's so I hope the others we're eager to get off!) and there was a few details that I feel were new.
I knew that there weren't going to speak of product information or detailed specs, but I did question the their HOS methodology - if we remember the presentation on the web a few days ago in which showed the 'CineFX' architecture to be programmable all the way through they had a '+Displacement Mapping' unit in front of the Vertex Shader; I asked if this (as it was green, indicating programmable) could relate to a 'Primitive Processor'; Geoff Ballew said that he wouldn't talk specifically about it but as I had pointed out this stage is programmable indicating it may be used for than just the HOS that's exposed in DX9.
Going on to DX9 there were a couple of references to how CineFX goes beyond 'pure DX9' - the way they were talking about this and R300 in relation to it indicates that they feel R300 is a 'pure DX9' part, so I don't think there will be concerns over MS shifting the spec so much that R300 will not be a DX9 part by the time DX9 is realeased.
However, when talking about DX9 and it limitations in relation to CineFX I learnt an interesting detail about Cg. I asked that even though CineFX goes beyond DX9, because Cg creates (DX/OGL) assembler if DX is used then isn't the developer going to be limited by this? Geoff explained that this may not in fact be the case - if the Cg Run-time compiler is used it doesn't necessarily compile DX/OGL assembly but compiles directly to the hardware thus circumventing any potential limitations in the current API's. I did a bit of a double take there since this is new information on the capabilities of Cg; If the runtime compiler is used the CG compiler will compile directly to the capabilities of the of the underlying NV hardware, if its used on a non-NV board is used (assuming a compiler is in place) then it will default to generating DX9 (or OGL assembly). If the non-runtime compiler is used (i.e. the game code ships with the compiled assembly) then only DX or OGL assembly will be used.
I also asked about there submission of Cg to the ARB for consideration as OGL2's HLSL. My thought was is that with GC being more or less DX9 HLSL if its submitted to the ARB then wouldn't the ARB want to control it for future updates hence this could represent a slight fragmentation between the two (OGL and DX Cg) because two different bodies would be attempting to control it - Geoff agreed that this could happen, however NV would attempt to make it high level enough that it could fit both with few changes.
One last thing we talked about was the use of specific graphics hardware for high end rendering. In the presentation Geoff said that 'offline' rendering will always be faster - the point of this is that you can easily scale offline rendering by throwing more CPU's / boxes at it. I asked Geoff "but what if we scale the graphics processors" and he agreed that there could be economies of scale/performance from scaling multiple graphics processors as opposed throwing more CPU power at it...
I'm not going to reiterate the mainstay of the presentation at this time as it's the same as we've heard about from other people who've been on a CC and much of it is public information from SIGGRAPH already - I'll save it for the actual NV30 preview/review. However, I asked a number of questions at the end (actually, I was the only one asking Q's so I hope the others we're eager to get off!) and there was a few details that I feel were new.
I knew that there weren't going to speak of product information or detailed specs, but I did question the their HOS methodology - if we remember the presentation on the web a few days ago in which showed the 'CineFX' architecture to be programmable all the way through they had a '+Displacement Mapping' unit in front of the Vertex Shader; I asked if this (as it was green, indicating programmable) could relate to a 'Primitive Processor'; Geoff Ballew said that he wouldn't talk specifically about it but as I had pointed out this stage is programmable indicating it may be used for than just the HOS that's exposed in DX9.
Going on to DX9 there were a couple of references to how CineFX goes beyond 'pure DX9' - the way they were talking about this and R300 in relation to it indicates that they feel R300 is a 'pure DX9' part, so I don't think there will be concerns over MS shifting the spec so much that R300 will not be a DX9 part by the time DX9 is realeased.
However, when talking about DX9 and it limitations in relation to CineFX I learnt an interesting detail about Cg. I asked that even though CineFX goes beyond DX9, because Cg creates (DX/OGL) assembler if DX is used then isn't the developer going to be limited by this? Geoff explained that this may not in fact be the case - if the Cg Run-time compiler is used it doesn't necessarily compile DX/OGL assembly but compiles directly to the hardware thus circumventing any potential limitations in the current API's. I did a bit of a double take there since this is new information on the capabilities of Cg; If the runtime compiler is used the CG compiler will compile directly to the capabilities of the of the underlying NV hardware, if its used on a non-NV board is used (assuming a compiler is in place) then it will default to generating DX9 (or OGL assembly). If the non-runtime compiler is used (i.e. the game code ships with the compiled assembly) then only DX or OGL assembly will be used.
I also asked about there submission of Cg to the ARB for consideration as OGL2's HLSL. My thought was is that with GC being more or less DX9 HLSL if its submitted to the ARB then wouldn't the ARB want to control it for future updates hence this could represent a slight fragmentation between the two (OGL and DX Cg) because two different bodies would be attempting to control it - Geoff agreed that this could happen, however NV would attempt to make it high level enough that it could fit both with few changes.
One last thing we talked about was the use of specific graphics hardware for high end rendering. In the presentation Geoff said that 'offline' rendering will always be faster - the point of this is that you can easily scale offline rendering by throwing more CPU's / boxes at it. I asked Geoff "but what if we scale the graphics processors" and he agreed that there could be economies of scale/performance from scaling multiple graphics processors as opposed throwing more CPU power at it...
