Intel Launches New Chipset

mikemuch writes "The new P35 and G33 chipsets, codenamed 'Bear Lake' are now available. They have a new memory controller that supports DDR3 RAM at up to 1333MHz, a new southbridge, and will support the upcoming 45nm Penryn CPUs. They don't yet have an actually new and different GPU — their GMA 3100 is pretty much the same as the GMA 3000 of the G965 chipset." For a little more technical info you can also check out the Hot Hardware writeup.

Comments

OT: External Intel(r) gfx?

[Anonymous Coward]

Really, it would be nice if we can get a external gfx (pcie) for "our" systems.

Re:OT: External Intel(r) gfx?

[jandrese]

You want Intel Graphics as a actual video card? You are aware that you can buy low end nVidia and ATI cards for less than $50 that will outperform them right?

Re:OT: External Intel(r) gfx?

[Anonymous Coward]

But do those nVidia and ATI cards have open source drivers? The Intel chips do!

Intel is therefore the best for Linux.

Re:Yawn

[AKAImBatman]

From what I can tell, this is basically good news for anyone who wants an affordable business machine. The updated specs mean that it will be competitive with the latest technologies, while still offering the savings and simplicity of an integrated design. (Assuming you're not die-hard about Intel integrated graphics sucking.)

On another topic, I love the screenshots of the upcoming motherboards. Computer components are getting so colorful. I remember back when you got a green motherboard with black and white parts. (<grumpy-old-man>And we liked it that way!</grumpy-old-man>) Maybe with a few blues for caps. Now you can really see the different parts as they leap out at you in blues, purples, oranges, yellows, and greens! Yeah, it looks a bit Fisher-Price. But it's kind of refreshing at the same time. :-)

When Do We Get Onchip DSPs?

[Doc Ruby]

Intel devastated the entire DSP industry in the late 1990s when they staked out the NSP ("Native Signal Processing") strategy of faster clockrates to run DSP in SW instead of in HW. But now they're up against new Cell chips from IBM which multiprocess with parallel DSPs onchip, and even GSPs ("Graphics Signal Processors") threaten new competition from first nVidia, then TI and other old surviving rivals, as GPGPU techiniques become more sophisticated and applicable.

All because DSP is more parallelizable than true general purpose processing, as parallelization is the best solution to increasing CPU power, just as the data to be processed is inherently more parallel, and more simply streams of "signals", as multimedia convergence redefines computing.

So when will Intel reverse its epoch of NSP, and deliver new uPs with embedded DSP in HW?

Re:When Do We Get Onchip DSPs?

[AKAImBatman]

So when will Intel reverse its epoch of NSP, and deliver new uPs with embedded DSP in HW?

Probably about the same time that web application developers realize that their problems (particularly AJAX) can be solved more efficiently with a DSP architecture and start designing tiers of servers in a pipelined DSP configuration. Considering the amount of computer science exhibited by this industry, I'd peg it at sometime around a quarter to never.

Re:When Do We Get Onchip DSPs?

[AKAImBatman]

All I get from your comment is that you weren't following what I was saying.

Intel's designs are driven by what drives the sales of their processors. For right now, that's gobs of desktop and PC Server machines. The alternative architectures are in no danger of knocking Intel out of that position. They will carve themselves a niche for now, which is why Intel has been more worried about AMD than they've been worried about IBM. Which means that Intel will sit up and take notice of the DSP-oriented chips if and when it actually impacts their bottom line.

Desktop machines are unlikely to need DSP processing anytime soon. (Outside of the similarities in GPU design, that is.) So there needs to be an extensive push inside the server arena to make Intel budge. As it happens, there is an issue that DSP designs can address.

Traditionally, DSPs have been used to process sampled analog data in real-time. They are carefully calibrated to stream the samples at high clock rates, with the expectation that the data will be merely transformed rather than processed by means that would require unexpected (and costly) branching. This expectation allows DSP microprocessor makers to design their chips in certain ways.

Of course, the basic tenets behind DSP microprocessor design do not require that the data I/O be analog in nature. Which is why you're starting to see DSP-derived designs (e.g. the Cell) starting to show up in digital devices with no analog sampling. As you said, the economics of the situation are making DSP microprocessors more effective than traditional GP microprocessors.

Now look at the web. What are we passing around like madmen? Streaming data, of course. These data streams are architecture-independent serializations that potentially lend themselves well to parallel processing of the data. In many cases, it's a simple matter of translating a data stream from a serialized form into an memory form or visa-versa. Sun has already realized this and has begun producing multiprocessor chips designed around streaming data. But their solution is highly focused on existing web loads, and will lose effectiveness as multimedia solutions become more common on the web. Cell is more general purpose, being capable of handling integer and floating point data equally well.

But I'm getting ahead of myself. With the current streaming situation on the web, we're starting to run into resource limitations on individual machines. The interim solution is to develop a pipelined processing stack over the network. As the requests stream into the front-end servers, they should be processed only as far as necessary to branch the stream to the correct server that's next in the pipeline. This server then takes the data and either deals with it directly, or does more processing and branching.

To give an example, take an instant messaging site like Meebo. Let's take a look at how it could be architected in a streaming fashion.

A login to the server produces a ripple effect where each person on the buddy list needs to be notified. This event creates an inverse multiplex for N number of signals, where N is the number of "buddies" in the list. Since these buddies are potentially on different communication protocols, the events can be demuxed to different servers, each one dedicated to maintaining links to that protocol. (e.g. Jabber, AIM, MSN, Yahoo, and Meebo)

IM packets continually hitting their servers as parallel streams of data. Similar to generating a login event, this requires that the messages be demuxed to the correct server based on their intended destination. It also requires that the incoming stream be transformed from a web stream (e.g. XML, JSON, or other textual format) into the format of the destination protocol. This can be handled by a separate machine from the one that maintains the backend IM connections. The stream can be transformed ahead of time, then forwarded to the protocol server for actual delivery to the IM network.

This example is a key area where

Re-state the question.

[DrYak]

A chip set is just supposed to talk to the CPU, and in case of Intel's architecture, talk to the memory.

A new chipset for DDR3 is logical in this situation : the chipset has to handle a different and electrically incompatible memory.

But why does a new CPU needs a newer Chipset ?!?!?

Meanwhile, in AMD's land, there's a standard between the chipset and the CPU called Hypertransport.
As long as both the CPU and the chipset follow the same protocol or compatible variation of (like AM2 being HT/2.0 and AM2+ and AM3 being HT/3.0) you can pretty much pair any thing you want.
The only restriction for a mother board is to have compatible socket (the CPU has on-board memory controller and directly speaks to the RAM sticks. There are different sockets type for different memory combination : 794 is for single channel DDR, 939 is for dual channel DDR, AM2 is for DDR2, Opteron F is for DDR2 and much higher number of Hypertransport lanes), and even that is getting stabilised (future AM2+ and AM3 CPUs can plug in today's AM2 board).

Why can't Intel guarantee the same kind of stability ?!?!?

Oh, yes, I know : they make chipsets and earn money by selling more motherboard.
Even back at the Pentium II/III era they have gone through the same cycle, releasing several incompatible chipsets and slot/socket formats in order to pump up motherboard sales, even if the same slot-1 PII motherboard could last until the last PIII only using adapted slotckets.

Meanwhile AMD is getting recommended on various website (like Ars Technica) as preferred solution for entry-/middle- level machines, because of cheaper board and more stable (and upgradable) hardware.

Stability of AM2/AM2+/AM3 is one of biggest AMD's advantage over LGA775 and should be put forward.

Re:Re-state the question.

[mrchaotica]

Meanwhile, in AMD's land, there's a standard between the chipset and the CPU called Hypertransport.

Note that that's not just "AMD land," that's IBM land, VIA land, Transmeta land, HP land, SUN land, and every-other-chip-manufacturer-except-Intel land.

Re:What's Different

[IPFreely]

Well, for one, Intel's biggest instruction set change in 5 years: SSE4 extensions, an updated to Intel's SIMD instruction set.

Really? I would have thought going 64 bit would be considered a slightly larger instruction set change than SSE4.

Maybe it does not count since it was an AMD invention rather than an Intel invention?

Minor nitpick: 1333 is CPU bus, not RAM.

[Anonymous Freak]

This new chipset supports 1067 MHz DDR-3 max. 1333 MHz is the CPU bus speed. This chipset will probably be revved to officially support 1333 MHz RAM, but not yet.

But, as many have already discovered, the previous P965 chipset can be made to support DDR-2 faster than its specced 800 MHz, and processors above its specced 1067 MHz, so 1333 MHz RAM will PROBABLY work just fine with minor BIOS tweaking, but its still unofficial.

I'm waiting for X38, with its dual X16 PCI-E 2.0 slots, among other improvements.

Re:What's Different

[TheRaven64]

Rumour has it (I haven't kept up, so maybe rumour had it) that SSE4 would include scatter-gather instructions. These allow you to specify multiple memory addresses to be loaded into the same vector. This makes auto-vectorisation much easier for compilers, since your memory layout no longer has to be designed with vectorisation in mind.

If this is true, then it might need co-operation from the memory controller to work effectively. Since Intel's memory controllers are on the north bridge chip, it would need a new chipset.

Of course, I'm just guessing, so don't take this as fact.