R400 reshuffling due to Xbox 2 contract?

I think both have two architectural design teams (that take on the high end parts) and the technology from these trickle down to other teams for other sectors.

You might want to add RV250 and RV280 over the past year as well as the other market sectors already spoken of.

One analyst once said to me that ATI has more hardware engineers than NVIDIA has employee's in total - its not quite like that these days, but you shouldn't underestimate the resources they do have.

 

More important than the quantity of resources available, though itself not an insignificant factor, is how those resources are used.

Consider this:

nVIDIA has at present 30% fewer employees yet they [have historically] produced 40% more revenue than ATi. Clearly, it's not the number of resources, but rather how they are used. However, to the casual observer, it would seem that ATi has [re]learned this lesson and nVIDIA forgotten it.

 

While true, ATI has [historically] been a more vertically orientated company.

This backwards compatability issue will be interesting to say the least. I question how games whose programming has forgone abstraction and been coded into nVidia native pushbuffers will work. Unless they do what SCE does and shrink the current XBox IC's onto a single 90/65nm chip, but I find this answer unlikely for a varienty of cost and inter-company IP reasons.

 

Exactly. Which is why it's nearly impossible to derive anything meaningful solely from the number of employees/engineers - it lacks the relational data necessary to make it a useful comparison.

Agreed. I'm more inclined to believe that MS is trying to pressure nVIDIA [on pricing] by publicly dangling the carrot in front of ATi, but will go with nVIDIA in the end. However, if MS can save a buck by going to ATi, and yet retain backwards functionality, it'd be uncharacteristic of them not to. It will indeed be very interesting to see how this plays out.

Best regards,
Joe Florez

 

One thing I'm wondering about: If MS really goes the ATi way - to reach an at least acceptable level of backwards compatibility, wouldn't ATi have - despite a relatively high-level SDK - to get a lot of low-level info about NV2A, far too much for nVidia's taste? Aren't there IP problems to be expected?

 

Practically, you can see the NV2A as a NV20 with a few minor additions in the Pixel Shader front, 8 zixels per clock, ... - and so on.
Furthermore, the XBox doesn't use nVidia proprietary extensions - it pretty much uses DX8, with maybe a few differences - and that SDK would then most likely work in a traditional way, using a driver.

So, eh, even slightly modifying a DX8 driver might work for the XBox. I doubt there'd be any serious issues there.
I'm more concerned about the chipset part. Heck, as someone mentionned, an nVidia chipset with an ATI GPU isn't completely out of the question, although unlikely.


Uttar

 

Its critical from a supply and and costs perspective to keep the parts to as few suppliers as possible. Also, remember that it was NVIDIA themselves that made the comment that there should be no backwards compatibility issues from the 3D side should another supplier be sought.

 

I wish you would have read my previous comment before stating this (or atleast adressed it instead of avoiding it):

I wasn't aware that these pushbuffers would directly map a competing IHV's architecture? It's my understanding that several of the new/future generation games are forgoing the extreme abstration of a DX8 type HAL and instead going for preformance gains when possible - it is a closed box console after all.

 

Vince the first statement is "When DirectX is used the rendering instructions are converted..." indicating that the game code itself will be DirectX, how that executes at a hardware level is beside the point since its up to the compiler to take the directX code and convert that into machine operation.

What you need to understand to evaluate whether that is an issue is whether any developers have used the "pushbuffers" directly or they just use DX code.

 

Dave, I wouldn't have posted it if it wasn't the case. Besides, the quote is from State of Emergency (SoE) a game that you, yourself, can buy today for XBox. That excerpt was a quote from two developers during GDC2003 on their experience in porting their hand-tuned VU microcode from PS2 to the XBox.

What do you think, I'm posting hypotheticals just to argue? heh.

PS. After rereading your responce, I'd suggest you reread the quote from above as I think you're missing what they did. Here's another and the link below:

 

This technique doesn't necessarily mean that it's NVIDIA specific rendering, but rather a characteristic of how instruction are packaged and sent to the GPU, I don't see any reason to assume that this would not work on other hardware - again, NVIDIA don't think this is an issue to MS.

 

I guess this means that if there were technical info NVidia didn't want ATI to have, they couldn't reveal it to Microsoft, which in turn couldn't reveal it to XBox developers.

 

Tech

I suspect that if MS had any sense they would have put a free rights clause into the develoment contract.

 

Can anyone else see an xbox 2 using a a64 , power vr 3d chip and a video lodgic sound chip (they still make sound chips right?)

 

There seems to be a lot of confusion about the Xbox GPU... Hopefully this may clarify things (and not break any NDAs...)

Xbox Direct3D is different from PC Direct3D, the PC interfaces are mostly there but lots of games don't use them. There are LOTS of things that are in hardware specific format AND use 'features' that are not commonly availible. Except for ports, lots of developers are working at a much closer level than on PC. Notable things includes working with the register combiners directly, relying on pixel/texture formats (i.e. accessing depth/stencil buffer data as colour by just pretending the depth/stencil buffer is a ARGB8 texture) and non-standard alpha test functionality (so-called AlphaKill).

The push buffers are rendering commands in a DMA list. There are the interface between software and GPU. There is no Direct3D DLL on Xbox. The Direct3D libraries are statically linked in the program and output push-buffers (i.e. no different from a developer writing there own push-buffer outputting routines (from a compat point of view) ). MS allow Devs to work on the push-buffers themselves rather than using Direct3D. There is even a library for the PC that will output the push-buffers, which allows a off-line PC convertor to generate the native Xbox GPU commands directly, by just calling Direct3D like routines on the PC.

The important things to note about any GPU compatiblity.

A) Must include pixel/Texture formats, bugs and features (i.e. you must be able to do AlphaKill, even though D3D or OpenGL have no concept of it)
B) Must be able to digest push-buffers, as there is no DLL to intercept. I.e. no magic driver swap, requires hardware emulation