[Scali]

Originally Posted by MfA

It's not really a big deal, hell there are C++ to C translators ...

I don't think those will work, since 'C for Cuda' isn't fully ANSI C. C++ can only be translated to C if it supports all features... like I said, function pointers are key to the object model.

[Bouncing Zabaglione Bros.]

Originally Posted by trinibwoy

It's really shaping up like Nvidia built Larrabee while Intel was talking about building it. I'm itching to know what fixed function stuff they might have gotten rid of, or if there are any changes to the rendering pipeline.

If it's true, it looks like Nvidia went GPU->CPU while Intel are trying to do CPU->GPU ie both trying to solve the same problems from opposite starting points. It's certainly a very ambitious approach and a big step towards convergence of GPU/CPU.

I guess all those questions about Nvdia not having a x86 licence are kind of moot if you can talk to the new chip via a compiler the same way as you talk to any CPU.

[Arty]

Originally Posted by Bouncing Zabaglione Bros.

Is this the first big leak? Sounds impressive on paper, though I do wonder if all the focus on GPGPU means that the gaming side of things will be taking a backseat.

Very typical of Theo, convenient how both hardware-Infos & bsn come out with this 'exclusive' 'breaking' news story AFTER Rys' hint

By the way, when is the webcast? (est)

[Ailuros]

Originally Posted by Arty

Very typical of Theo, convenient how both hardware-Infos & bsn come out with this 'exclusive' 'breaking' news story AFTER Rys' hint

By the way, when is the webcast? (est)

There's a huge difference between an educated hw analysis and being first and 2nd at nothing.

[Chalnoth]

Originally Posted by MfA

It's not really a big deal, hell there are C++ to C translators ... although I fail to see the point of Fortran apart from the warm and fuzzy feeling the name generates. It's not like even porting legacy code to it is an option, the level of algorithmic changes needed to suit a GPU make a rewrite the only realistic option. Fortran doesn't seem to me to be a great language to write kernels in.

PS. http://www.pgroup.com/resources/cudafortran.htm

Quite a lot of scientific work is still done in Fortran, and though it is possible to get Fortran and C/C++ to play together, it can be difficult and fraught with difficulties with compiling properly. So having a native Fortran version of Cuda could be a boon for getting it adopted within the scientific community.

[Scali]

Originally Posted by Arty

By the way, when is the webcast? (est)

Keynote is at 1 PM PT, which I assume is webcast live, see here for more info:
http://www.nvidia.com/object/gpu_tec...onference.html

[trinibwoy]

Originally Posted by Arty

By the way, when is the webcast? (est)

4pm EST / 1pm PST

http://www.nvidia.com/object/gpu_tec...onference.html

[3dilettante]

Originally Posted by trinibwoy

Looks like that's exactly what they're trying to do. Strange that there's no mention of any graphics specific bits so far. Not saying there aren't any but the focus seems to have veered sharply away from graphics.

The Rys blur-o-gram had a lot of the same colors in the area that the GT200 one had for shader and triangle setup. It looks like there's still some kind of texture block.
The compute portion appears to be heavily reworked, and the area that was the ROP section is still there, but I can't infer much from a gray (oddly dark gray...) smudge.

If the setup, texturing, and ROP specialized sections persist, the Fermi architecture would be the answer to the question "what if we made Larrabee without x86, and gave it ROPs and a rasterizer?"
The next question would be, "what if we built Larrabee with an inferior process", but I digress.

That's true, but the same could be said for G71->G80 which was an even bigger change. Though they are trying to do more stuff now which could have put a strain on resources.

The rumors seem to reflect that the birthing process for this new chip could have been smoother.

It's probably safe to assume that if they're serious about computing, performance of atomics would have been high on their todo list. Side question - are the existing caches on GPUS generally useful for non-texture data (not referring to the specialized caches like PTVC)?

I'm not sure.
They are pretty small, and they are structured to provide peak bandwidth for the common case of filtered texture fetches.
I'm not sure how much of their behavior changes if they are tasked with linearly addressed memory. If the data is structured to make the most of them, then their bandwidth can be used.
Their size and read-only nature makes them less than generally useful.

[MfA]

Originally Posted by Arty

Very typical of Theo, convenient how both hardware-Infos & bsn come out with this 'exclusive' 'breaking' news story AFTER Rys' hint

Wouldn't that be NVIDIA's hint? (If you're under NDA you tell what you are told you can tell.)

[dnavas]

Originally Posted by Rys

All will be revealed later today anyway, not long to go now.

Wow, no wonder the parking lot was full late last night! I thought we had a couple of weeks to go. I wonder if they brought the demo forward for competitive reasons?

Also, I realize Rys says everything has changed, but:
1) 16kb per 8-wide set of SPs does actually work out
2) I like that there are four blue dots and four sets of SPs in there
3) I wonder what bits in the chip run the C++ code
4) If DP runs half-speed, they really have done some work in there.
5) Isn't it great that each SP can run an instruction per clock per thread? Why, all I have to do to increase performance is add more threads! Infinite TFlops!

[Richard]

Originally Posted by chavvdarrr

1 day in near future, a writing on the screen when starting your brand new IBM PC compatible...


"no CPU detected, starting software emulation"

LOL

One would hope that by then we wouldn't need POST-screens anymore. Who am I kidding, we're going to still be posting in x86 mode regardless... the future will bring x86 bootstrap hw in the mobo using CMOS for working set; mark my words. For an industry so quick to change we are an awful crotchety bunch.

[GrapeApe]

With nV being so die space limited again, focusing heavily on the Tesla family in design, and trying to pack in as much compute power onto the die as possible under current fab, I'm guess the return of the NVIO is a safe assumption, no?

With that, what would the limitations be towards putting more than one traditional NVIO on the the PCB to allow for greater multiple monitor configurations (more as a rarer 'we can do it too' configuration than as a general design). With the DRAM and ROP/RBE partitions being an odd number as inferred from the blurry-diagram, I'm assuming a six-cluster would be easier to feed to two external NVIOs than 3 distinct groups of even numbers.

It would be another way to address a PR checkbox, in an era of the return of the checkbox (3DVision, Eyefinity, PhysX etc), and if possible would be simpler than an NVIO near-term redesign.

I'm just not sure of the restriction on the NVIO as there's not too much on the underlying design, just the base components included (TMDS, RAMDACs, etc).

I always thought the NVIO was a cop-out for near term, but would be essential if you wanted to go to an multi-die MCM style future design to avoid duplication of resources and maximize the transistor budget for this and the idea of multiple offspring designs (like Tesla).

I know there's 2 NVIO on the GTX295, but that's primarily due to the SLi considerations when communicating with the bridge.

Anywhoo, just curious if anyone knows for sure if dual NVIOs per chip was possible, or if it's limited by memory interface or RBE/ROP restrictions by design?

[jaredpace]

What is this?

[DegustatoR]

Originally Posted by GrapeApe

With that, what would the limitations be towards putting more than one traditional NVIO on the the PCB to allow for greater multiple monitor configurations (more as a rarer 'we can do it too' configuration than as a general design).

AFAIK even the first version of NVIO allows to have 4 simultaineous outputs.
And NVIO has nothing to do with being die size limited.

[Jawed]

Originally Posted by DegustatoR

That's a bit of an overstatement.

At best 10-20% better performance than HD4890 in games despite having more bandwidth and being dramatically larger. I don't see any overstatement there.

So how come nobody did?

Maybe they did but AMD blanked them

GT218 is a 60mm^2 GPU. I don't think that you can compare it to the 140mm^2 RV740.

It wasn't a reference to the performance of RV740. It was a reference to the ability to refresh on a new node and improve all performance-per metrics significantly.

And you surely can't compare it to a GPU made on another process.

Why? They're direct competitors (until Cedar arrives). If it was higher performance and/or lower-power we'd say "that's the benefit of 40nm". Instead we're just scratching our heads.

In other words we need more information before any conclusion on GT21x being a failure can be made. One review of GT218 isn't enough for such conclusion.

It'll need to be quite a turnaround. Remember NVidia was boasting about expecting to be first with 40nm chips.

When something as "simple" as GT218 is delayed and working badly it's not particularly surprising that NVidia's not ready for W7 launch with a 40nm D3D11 GPU.

Jawed

[AnarchX]

Originally Posted by jaredpace

What is this?

G92(b)

[Jawed]

Originally Posted by Humus

Previously the interpolator provided the interpolated values to the shader. In SM 5.0 the shader can ask for interpolated values by itself. There are some functions for it: EvaluateAttributeAtCentroid(), EvaluateAttributeAtSample() and EvaluateAttributeSnapped().

Ooh, very interesting, thanks. Can't find anything about those online

Is there something similar for use in DS to help in obtaining attributes at the newly generated points?

Jawed

[DegustatoR]

Originally Posted by Jawed

When something as "simple" as GT218 is delayed and working badly it's not particularly surprising that NVidia's not ready for W7 launch with a 40nm D3D11 GPU.

I fail to see any correlation between GT218 and DX11.
And it was late because of TSMC not NVIDIA. Which rises the question of who's to blame for it's power characteristics also.

[Jawed]

Originally Posted by 3dilettante

Any such data path puts RV870 one step closer to fully closing the write/read loop in the manner CPU caches do.
It would probably still be less flexible and have higher latency, but at least there's an on-chip path.

Another thought is merely that the L2 system can query the RBE-owned render target structures and either decode the RBEs' compression tag tables or request decompression semantics for the data it wants to fetch from memory. So the on-chip linkage might be quite simple and L2 is simply doing most of the work, rather than having RBEs fetching the data and using the render target caches.

As a side note, I'm curious about the additional non-texture L1 that was added alongside the regular texture cache, as mentioned in the Anandtech article. What this brings to the table at that size compared to the larger texture and LDS, I'm not sure. It would help with problems with thrashing, if graphics and compute shaders hit the same SIMD, I suppose.
In a GPGPU situation, what would it offer over using the larger L1?

Sure this isn't just the regular L1 cache that's used for textures? I don't trust Anandtech.

Jawed

[Jawed]

Originally Posted by nAo

With now both NVIDIA and ATI interpolating in the shader cores divisions are used even more often

Even Larrabee has RCP and RSQRT intrinsics I wonder what the throughput for these is. I guess that's the cost of doing graphics, rather than just general compute. The EXP2 and LOG2 functions are useful too - though base-2 stuff is pretty easy I dare say (partly re-using FTOI/ITOF I guess?).

Jawed

[Jawed]

Originally Posted by trinibwoy

How do you figure that?

I get 30*16-banks*4-bytes*600Mhz =~ 1.15TB/s

I was looking at it from the point of view of the throughput for the ALUs, that 1 operand per clock is available per MAD: 30 SIMDs * 8 ALUs * 4 bytes * 1476MHz (GTX285) = 1.417TB/s.

Jawed

[3dilettante]

Originally Posted by Jawed

Sure this isn't just the regular L1 cache that's used for textures? I don't trust Anandtech.

I don't know. It seemed like an odd thing to just make up out of thin air.

[trinibwoy]

Originally Posted by Jawed

I was looking at it from the point of view of the throughput for the ALUs, that 1 operand per clock is available per MAD: 30 SIMDs * 8 ALUs * 4 bytes * 1476MHz (GTX285) = 1.417TB/s.

Jawed

Oh, ok, though I'm not sure if the register file and/or shared memory runs at the hot clock. For one thing, results from the pipeline are written 16 at a time which implies some sort of buffering.

[Arty]

Originally Posted by DegustatoR

I fail to see any correlation between GT218 and DX11.
And it was late because of TSMC not NVIDIA. Which rises the question of who's to blame for it's power characteristics also.

That's hardly an excuse, AMD didn't suffer as much so it comes down to NV's design.

Thanks for the webcast time, appreciate it.

[Jawed]

Originally Posted by dnavas

At anyrate, from my limited experience, if I wanted to make my ALUs more generic, DIV would have to be close to the top of my list....

See figure 4:

http://www.ece.ubc.ca/~aamodt/papers...m.ispass09.pdf

Sure, it's not comprehensive, but SFU isn't getting much use there.

Jawed