Nvidia's Fermi Architecture Debuts; Nouveau Driver Already Working

crookedvulture writes Nvidia has lifted the curtain on reviews of its latest GPU architecture, which will be available first in the high-end GeForce GTX 680 graphics card. The underlying GK104 processor is much smaller than the equivalent AMD GPU, with fewer transistors, a narrower path to memory, and greatly simplified control logic that relies more heavily on Nvidia's compiler software. Despite the modest chip, Nvidia's new architecture is efficient enough that The Tech Report, PC Perspective, and AnandTech all found the GeForce GTX 680's gaming performance to be largely comparable to AMD's fastest Radeon, which costs $50 more. The GTX 680 also offers other notable perks, like a PCI Express 3.0 interface, dynamic clock scaling, new video encoding tech, and a smarter vsync mechanism. It's rather power-efficient, too, but the decision to focus on graphics workloads means the chip won't be as good a fit for Nvidia's compute-centric Tesla products. A bigger GPU based on the Kepler architecture is expected to serve that market." Read on below for good news (at least if you prefer Free software) from an anonymous reader. Update: 03/22 19:35 GMT by T : Mea culpa -- that headline should say "Kepler," rather than Fermi; HT to Dave from Hot Hardware (here's HH's take on the new GPU). Our anonymous friend writes "The open-source Nouveau driver project that reverse-engineers the official NVIDIA driver to provide a free software alternative has made some big accomplishments. Nouveau announced today they have same-day Kepler support and are now de-staging on Linux. The GeForce GTX 680 'Kepler' launch just happened hours prior to Nouveau, somehow managing initial mode-setting support with early hardware, from a project that NVIDIA 'officially' does not support. The de-staging in the Linux kernel now means that the driver is at version 1.0 with a stable ABI."

Comments

Wrong architecture!

[kz26]

I believe you mean Kepler, not Fermi, in the story title.

Re:Wrong architecture!

[Cainam]

Exactly. Fermi launched two years ago.

Re:Fermi ?

[billcopc]

Exhibit A: "Posted by timothy"

The prosecution rests, your honor.

Re:Fermi ?

[WrongSizeGlass]

Exhibit A: "Posted by timothy"

The prosecution rests, your honor.

Your honor, we're asserting an affirmative defense based on the fact the it's nap time.

Nouveau

[Narishma]

If the Nouveau project doesn't get support from Nvidia, how did they manage to support this new chip before it's release? Have they had access to one of the cards sent to the press?

Re:Nouveau

[Kryis]

It doesn't *officially* get support from Nvidia. That isn't the same as not getting support at all.

Re: Nouveau

[Anonymous Coward]

Troll spotted

As a Nouveau dev, I can tell what's wrong with Nouveau and it is not the lack of acceleration!

First of all, we have 2D and 3D acceleration (up to OpenGL 3 and a toy directx 10/11 support that runs Unigine Heaven) for all cards, back to the TNT 2 (of course, no hw opengl 3 there). OpenGL has been good-enough for me to play many games at decent framerates and have a composited desktop running on all my cards minus one. This one is the half-Fermi/half-Kepler nvd9 that still needs some love.

Up until the G50, there mostly was no real power management. Clocks were set at boot time and that was enough for us.
G50 introduced reclocking support on mobile GPUs. The boot clocks were no longer set to the stock values but only to lower clocks (let's say half the normal frequency). Most desktop GPUs lacked power management.
GT215 extended the laptop power management scheme to desktops.
Fermi, of course, kept that scheme but pushed it a little further. Now, boot clocks are terribly low (core = 50MHz, memory = 100MHz) at boot time.

On my GTX460, Nouveau is perfectly usable on kde 4.8 (I have 100fps with KWin and the OpenGL backend) but games are obviously really slow, about 30fps for xonotic.

At the same clocks, Nouveau's performance is about 80% of the proprietary driver and thus, not bad. Our real problem, is that we need reclocking support to get more performance out of the cards. We have been working on it for about 1.5 years and trust me, it isn't the easiest part of the hardware to reverse engineer.

So, what's the current state of reclocking support?
- G50->GT200: Clocks can be set to the desired frequency and the operation should be stable. Some cards don't work but we are ironing the corner cases. In some cases, the screen turns black for a few ms while reclocking. It's a bug I'm working on.
- G215 -> GF100: Clocks can be set for all engines and memory but the end-result isn't usually working because of some black voodoo we aren't doing right now. It is being addressed.
- GF100 series: Only the engines can be reclocked. Nothing but very experimental memory reclocking. It is being worked on.
- Kepler: Hey, it was released today, most of us haven't put my hands on anything yet.

If reclocking is supported on your card, dynamic reclocking is a piece of cake (compared to reclocking) and the support for it has already been written.

To sum up, we have hw acceleration on all cards but nvd9 (unless you use some microcode from the blob) and Kepler. The only problem with 3D is the lack of proper power management but it is being worked on and we have made great progress. As cards are all different but in fact doing the same thing for it (even across generations), I have good hopes that Kepler will be fully functional 3D-wise before a new series come.

Remember that, contrarily to the blob, we do support cards older than geforce 7 AND we provide out of the box/open source hw acceleration that is already way sufficient for desktop usage. Also, remember that this work is mostly done by a core team of less than 10 people, most of us being students and only one being paid by Red Hat.

Martin Peres, PhD student working on power management on Nouveau

Re: Nouveau

[PopeRatzo]

Martin Peres, thank you for your hard work. It is no small thing that you do with Nouveau, especially considering the general lack of appreciation shown by some.

Anybody who uses their time and talent to develop OSS stuff deserves a lot of respect, and at least a little thanks, IMO.

I'm not an OSS dev, or a dev of any kind, but as a professional music recordist, I have done a lot of work with OSS devs in the audio realm, and although I've been too impatient sometimes with the progress of OSS music production on Linux, there has been some pretty impressive work done in the last couple of years, to the point where I've been able to do my first all-OSS music production project last year and get absolutely first-rate results. There are still rough patches, but today there is finally the possibility of serious creative audio work using all OSS, thanks to a lot of people like you.

So, salut!

Re:Next Consoles...

[Narishma]

The rumours around all point to all next gen consoles having AMD GPUs in them though.

Re:Fermi ?

[Anonymous Coward]

What's it got to do with Timothy?

A careful reading of the source clearly shows...

Oh. Never mind.

Bad for GP-GPU computing

[Anonymous Coward]

Firstly, this new architecture (GK104) has a great number of cores (192 versus 32 of the Fermi architecture) sharing a single control logic within a stream multiprocessor (SM). Internally, each SM is SIMD, so this move is bad for divergent kernels, i.e., algorithms containing if-then-else constructs. Secondly, as usual from Nvidia, the GeForce brand has poor double-precision performance, only 1/8 of the SP's. On the other hand, the AMD Radeon HD7000 family doubles this fraction, being much faster at DP operations, which is a must for scientific computing.

Re:Bad for GP-GPU computing

[jensend]

The double precision situation is a lot worse than that. For GK104, fp64 performance is only 1/24 fp32. Previous to this, NV's consumer cards did fp64 at 1/12 (midrange) or 1/8 (high-end) fp32; I guess that wasn't enough handicapping to protect their Tesla line so they bumped it up.

If you need more precision than fp32 and want to use nV consumer GPUs you should consider software emulation. A very simple software double emulation scheme can give you 1/6 - 1/4 of fp32 performance. Of course it's less precise than fp64- it has 48 significand bits (double fp32's 24, less than fp64's 53) and 8 exp. bits (same as fp32, 3 less than fp64), and to get ~1/4 of fp32 performance you have to skip a lot of error/NaN/inf handling type stuff. But it's probably sufficient for a lot of applications where people use fp64. Even software "quad-single" (96 significand bits using 4 32-bit floats) would likely be faster than nV's native fp64.

OTOH, AMD doesn't have much reason to handicap its cards, as you mention, its cards do fp64 at 1/4 fp32-- and that's with full IEEE 754 compliance. They used to be at a big disadvantage for GPGPU, but with their new compute-oriented GCN architecture and their now-huge fp64 lead for $2000 cards, I think a lot of GPGPU folks will switch.

Re:In b4

[chill]

Epic fail on your part. Nouveau got it to light up. Gaming support comes from acceleration support.

From the actual article on Phoronix:

There isn't any acceleration support yet for Kepler or anything besides mode-setting on Nouveau, but this is welcoming at least so early Kepler adopters won't need to fall-back to the xf86-video-vesa driver and likely some less-than-ideal resolution.

Stupid Nvidia

[SgtDink]

Once again they don't have same day OS/2 support. Do they seriously expect to remain viable if they don't know who there customers are?

Re:Next Consoles...

[dstyle5]

With XBOX 1 Nvidia burnt their bridges with Microsoft over licensing and Microsoft moved to ATI for the 360 since ATI would design the GPU for Microsoft, but Microsoft owns it.

I don't know what licensing agreement Sony & Nvidia had with the PS3, but if I'm Sony and I see what the other guys are doing I would rather go with the more flexible GPU design house. That and ATI's Fusion experience would probably help tip the scales in their favor too.