DirectCompute (Direct3D11 Compute Shaders)

Thats a comment, not a statement.

However, there are many market drivers for DX10 - i.e. OEM / partner requirements/expectations, logo requirements etc. Additionally, and most importantly, there is a clear software path to its use. DPFP is an optional feature that has limited scope in consumer applications at this point in time.

 

I'm sorry.

Right, but while RV610 was designed, there was no software to use it, even though some was bound to appear. But in how many applications did DX10-support really make a difference for RV610-users? I mean, apart from the only DX10-exclusive game Storm-Rise.


But don't you think, it'd add to the feature's acceptance with developers and thus more widespread use, when market penetration increases also in lower price segments?
I thought that was one of the motivations behind the "family launch" of HD2000 for example?

 

Removed.

 

Well, probably the major motivator for DX10 on Rv610 was OEM design wins. Similar to how Nvidia has included DX10.1 in their new low end cards despite the fact they don't really "want" to support Dx10.1.

Increasing install base of Dx10 level cards would be nice for greater adoption of a new feature, but if that new feature isn't going to be used anyway due to a variety of factors (slow adoption of Vista for example for Dx10), then it's a secondary consideration.

Other than hobbyists, I don't see any market for DPFP for consumer cards, now or in the near term future.

58xx is in a unique situation compared to the rest of the line in that not only is it more attractive to the businesses that could leverage DPFP but more importantly FireGL cards will probably use the Rv870 chip. So it makes sense in that case to have it on chip.

Regards,
SB

 

A lot of that is dependant on how the developer wants to use a new API - each generation of DX is increasing flexability and that can be harnessed to improve quality and/or improve performance; DX10 could have been harnessed to improve performance for a given quality level, we saw a number of cases where that is exactly how DX10.1 was utilised and you can make a case for 4 or the 5 primary additions/enhancements in DX11 can be used to improve performance. So, you can look at use transistors to improve "raw" performance or you can use them to support the specification that your customers are asking for and that can also provide a performance improvement as well, if used in such a manner.

This is as may be, but you also have to weigh that against the demand for the feature, the benefits to the target market and the impacts to the products if its supported.

GPU compute is in its infancy - decent industry standards with DX Compute and OpenGL are just getting off the ground, first we have to get that off the ground and make use of the transistors that are spent purely for that.

 

I know, but the same emulation could be applied to RV670 wich have scatter support too, right?

 

Yeah, I don't know if RV670's scatter is more restrictive than RV770 or not. Most early reviews of RV770 only talk about "faster scatter than RV670" but I can't find anything about its restrictions.

Of course, another possible problem is synchronization. Even using global memory to simulate shared memory, the threads still have to be synced. If there is no internal synchronization function, then the only way to "simulate" it is through multiple runs of the kernel, and that can be extremely slow.

 

Sorry I was more upset that the feature sets didn't seem to be the same between all of the 4k seires. The 5k thing kinda slipped in there. Really I am not a programmer(only python stuff), so I cant say how useful one feature is over the other so pardon my ignorance on the subject. Really I was worried we were going to have another geforce 4 going for us where only 1/3 of the cards sold supported pixel shader model 1.1.

 

With regards to DirectCompute on DX10(.1) you have to bear in mind that this specification was not planned prior to DX10(.1) parts being designed or implemented and was added after the hardware was done.

 

CarstenS, I think the bold in Dave's reply before your comments readily addresses this concern. Granted even if both DP and DX10 had no software, DX10 had a clear software path that impacts that market segment to one degree or another while DP is far more foggy and doesn't appear to be something relevant for the use of that market segment during the lifetime of that product.

If AMD/NV saw that games would be using DP in 2010 I am sure it would be more relevant to the lower end board market.

 

It's all about sales. Remember how the Radeon 9000 slaughtered the GeForce FX 5200 in performance? DX9 support gave the latter many design wins, and it kept NVidia's market share mostly intact during that era (along with the loyalty of their fan base at the high end).

 

I am aware of that (my bolding), but don't you think that especially infants need plenty of food and care to grow strong in a short period of time?

A very good point IMHO. And - if i may ask - do you share my belief, that this investment in (given the abysmal performance of the FX 5200 in just about every game) pretty useless transistors helped quite a lot in giving DX9-games a good push to market? Of course, additionally to Atis well deserved success and skyrocketing sales with R9700/9500/9600/9800 at the time?

 

Not really since many games had to use DX8 fallback paths on the FX 5200 because it was too slow in DX9 mode, even with liberal use of "_pp" everywhere.

-FUDie

 

That's terrible logic. Hey AMD how about you spend a bunch of transistors for a feature on a product that less than 1% of its owners will use? See the problem with this? AMD first and foremost makes 3D accelerators, not GPGPU's.

 

Food and care, yes. Candy...?

Note that all of the programming standards that we build towards made DPFP an optional feature specification - you may argue that thats because the hardware vendors drive the spec, but thats only part of the story; software vendors also drive the spec and that represents the overall desire and need of DPFP across the stack at this point in time.

 

Replace "double precision" with "any functionality that has limited benefit for graphics but huge value for compute," and a clearer picture emerges. Lots of sacrifices and compromises were made in the open standards in the name of compatibility; if this didn't happen to some degree, adoption would be much harder. Did the open standards make the right compromises for a 1.0 release? Time will tell.

(also, good lord, every thread really does come back to NV30)

 

We're not just talking about compatibilty for previous hardware here but also clean slate hardware as well. DirectCompute 11 had the opportunity to mandate it, but chose not to.

 

I believe all threads in a wavefront are always synchronized.

 

NV is providing all the food/water/shelter/ECC/read-write caches for this baby. AMD will like to mate the kid with ruby once it grows up.

 

While we are speaking of it: Was DPFP-Support in RV740 a mistake then? I mean, it's entry price was even lower than HD5700's, IIRC.