Philosophy of VPU Design

[Luminescent]

In a recent thread it there was some sort of an implicit debate as to the major priority of an IHV when designing a product and balancing features with performance; it is the age old debate of priorities, and relates to hardware pusing software vs. software pushing hardware. Which vision (if you had to choose 1 or the other) do you believe each of the two major IHV contenders is abiding by with the release of the current generation (NV40, R420)?

The triangle of interests that influences the above involves the hardware developer, software developer, and end user. The core performance of a hardware product (independent of aesthetic features) benefits the end user and is primarily the responsibility of the IHV (w/ compilers, developer relation seminars, etc.). Features that allow for/exploit programmability and ease of development benefit the developer are also the responsibility of the IHV. Aesthetic features that benefit the end user, like AA, Aniso implementations, etc., are solely the domain of the IHV. In the end, the success of the IHV's design philosophy is dependent on how well it satisfies each of these two departments (for ISVs and end users) and how it feeds its own needs, financial status, etc.

Let us proceed to define the elusive terms that will be helpful in letting us measure the cornerstone design philosophy of each respective IHV from a third person (B3D) perspective. The features vs. performance orientation of a VPU should be a good indication of the above, so let us define features and performance as they pertain to this discussion. Features are hardware resources that are dedicated to granting developers more careful and easy access to underlying hardware and that allow developers to overcome the limitations of the programming model/pipeline available to them in the previous generation. Features are also the hardware elements available to the end user that allow for him/her to enhance image quality independently of the software code.

Performance is the raw processing power, in hardware, dedicated to processing the graphics of current/past generation software at the time of its (the hardware's) release.

Below are some of my observations, which I had to type in a hurry:

It seems Nvidia and Ati were not too distinguishable before NV10, however Nvidia pushed the direction of software with NV10's T&L. Since then, each IHV has seemed to flip-flop with respect to design philosophies.

NV15 vs. R100 - R100 is more future focused and feature complete, yet lacks the raw performance of NV15.

The hardware feature gap of R100 relative to NV15 is about even with the performance gap, although raw performance favors NV15.

Software community does not make much effort to exploit R100's features in-game (envbm, single pass triple-layer texturing) over NV15's. NV15's performance advantage is evident, however.

NV20 vs. R200 - NV20 1 ups the featureset of R100, although R200 is even more feature complete (albeit where filtering and AA is concerned) and performs better overall.

The hardware feature gap of R200 over NV20 is a bit more than its performance lead.

With software, the extra featureset of R200 is barely exploited, although it may have led the future development of software w/PS 1.4, which is more readily evident in recent titles than PS 1.2/1.3.

NV25 vs. R300 - NV25 is able to outperform R200, yet still lags behind in terms of featureset. R300 again outfeatures NV25 and nearly doubles its performance.

The extra featureset of R300 is about as great as its performance advantage.

R300 drives software to exploit its featureset and drives software development, perhaps because it was clearly ahead of NV25 in both departments: features and performance, by a large margin.

And the list goes on.

NV10: Feature focused and performance oriented, relative to its predecessors. Drives software development into T&L and use of combiners.

NV15: Performance oriented, moreso than its predecessor. Establishes the position initiated by NV10, evident in the cutting-edge software of the time (giants, sacrifice, etc.)

R100: Feature focused, moreso than NV15, but less raw performance with the software available at the time.

NV20: Feature focused, with a moderate increase in performance over NV15 and R100.

etc.

 

[Inane_Dork]

I would put API providers in the third vertex of your triangle before I put users there.

 

[Luminescent]

Inane_dork, good suggestion, but the API is more akin to the lines which connect the vertices in the triangle of interests. It allows IHVs to organize their implementations and conform them to a standard that unifies software, hardware, and the end user.

The above is my personal organization and assesment of the relationships that affect an IHV's design philosophy. This aside, I believe the heart of the matter lies in whether or not an IHV wants, foremost (in terms of R&D, transistor budget allocation, etc.) to conform to current software and developmental trends or pave the way for future developmental software and trends. It seems that with the level of programmability we have now, it benefit IHVs to conform to current software and developmental trends (which also includes engines that are a work in progress) moreso than to pave the way and be revoluionary.

It seems that software initiates the development of hardware, which then affects/limits the development of software. Once a hardware trend begins, it is up to the IHV and API to break molds and establish paradigms. Software R&D allows for groundbreaking techniques, but it can never be put in practice (i.e. games) unless an IHV decides to allow for it. The likelyhood of going back to a software approach for advanced effects is about nill at this point.

 

[_xxx_]

I would even say that API providers are the driving force behind the development of new hardware, since the hardware makers try to optimize their hardware for specific platforms with respectable favoured API's.

 

[Inane_Dork]

Inane_dork, good suggestion, but the API is more akin to the lines which connect the vertices in the triangle of interests. It allows IHVs to organize their implementations and conform them to a standard that unifies software, hardware, and the end user.

Fair enough. I just think of API providers as being far more influential in graphics development than users. The APIs seem to funnel development into slightly more strict channels than IHVs desire. F-buffer, anyone?

But like I said, fair enough.