Slashdot Mirror
Intel To Integrate DirectX 11 In Ivy Bridge Chips
angry tapir writes "Intel will integrate DirectX 11 graphics technology in its next generation of laptop and desktop chips based on the Ivy Bridge architecture, a company executive revealed at CES. AMD has already implemented DirectX 11 in its Fusion low-power chips. Intel expects to start shipping Ivy Bridge chips with DirectX 11 support to PC makers late this year. Ivy Bridge will succeed the recently announced Core i3, i5, and i7 chips, which are based on Intel's Sandy Bridge microarchitecture."
does it still contain the DRM restrictions capability ?,
because Intel can forget all about CPU sales from us and from any of our customers until its removed
i dont care if it promises a free pony
contains DRM==No sale
period
Will Intel provide documentation so that other OSes will be able to make use of this feature ?
UPS Sucks
Goes to 11!
(I'm sorry)
I'd rather they made their integrated graphics fast than simply support new DirectX capabilities. I don't really see the point of supporting certain features if the whole thing is going to be slow. I suppose it's easier to implement something than it is to implement it well.
They have always waited for other graphics companies to lead this charge. It's a huge effort on the hardware side to be Microsoft's partner on this. The benefit is that you get out the door first, but Intel has never pushed for that leadership position in graphics (so long as you don't count volume).
For every benefit you receive a tax is levied. - Ralph Waldo Emerson
1. Will this in any way benefit OpenGL?
2. Will this hinder future versions of DirectX or are they backwards compatible in a way that there would be large chunks in hardware and new changes made as firmware revisions or software implementations?
Learning HOW to think is more important than learning WHAT to think.
And what use is it when a bug is found in DirectX, you can change software, but hardware?
Well, considering DX11 has been out for a while and has been generally tested for bugs already - the idea is that you won't HAVE a bug if it's in the hardware - theres no where for the variables to change values based on a different CPU build or other factors if the calculations are specifically designed to run on that piece of hardware. At least, thats the theory.
But yeah - this does nothing if you typically aren't running Windows. Though I'm more concerned on what this will do to the future of DirectX. Where will the push be to improve things for a DX12 if everything is neatly designed for DX11? We've got enough backwards compatibility issues with old games requiring DX3 not working anymore.
This seems like a prime time for OpenGL to pick up speed. Specific hardware to meet DX11 makes it sound like the DX development process is becoming stagnated. Otherwise, why would you bother?
The Sandy Bridge chips are the first in which Intel has combined a graphics processor and CPU on a single piece of silicon.
I thought Intel already did this a while ago with the newer Atom chips:
http://en.wikipedia.org/wiki/Intel_atom#Second_generation_cores
Escher was the first MC and Giger invented the HR department.
It will still be too slow to use it for anything that is DirectX 11. Why do they even bother?
Those new texture mapping algorithms will really make outlook load fast.
Evil people are out to get you.
ahhh... No.
DirectX has certain hardware requirements. They are not going to hardwire in DirectX but will instead support all the hardware features that DirectX 11 needs.
I hope they support OpenCL as well.
I am not a gamer but I would love to see more programs use the GPU for trans-coding and other none game play uses.
DX11 does support GPGPU but I use OS/X, Linux, and Windows so I want standards support.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
That's what I am worried about, I want my Minecraft landscapes to be rendered better.
He who knows best knows how little he knows. - Thomas Jefferson
For the foreseeable future you can have your pick of ARM and x86.
On the plus side, x86 has been pretty much RISC internally for a long time now. And a lot of the ISA has been changed over too. Once they tack on one or two more ISA extension you'll be able to have 100% of your code avoid the x86 path.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
It's not what you think. It's a built-in graphics card on the CPU. That graphics card has all the hardware necessary to support the directx 11 api. If they change the directx API, intel changes the driver.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Worse what happens when directX 12 comes along? is the hardware useless? can the hardware be upgraded?
1) The same thing that happens when you install DirectX 10 on a DX9 card: the DX9 subset of DX10 is hardware accelerated, the DX10 parts are run in software.
2) No. It's not useless. It will still accelerate everything it was accelerating before.
3) Probably not. But who cares? Either replace it, or live with a subset of current functionality.
What happens to your nvidia 580 card when dx 12 comes along? Exactly the same thing happens with these cpus. Either you live with the reduced functionality, or you put in a new video card, assuming your motherboard has a graphics card slot.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
So why not do it generically? IBM Cell chips integrate a Vector chip on the CPU. Intel and AMD both have video chips integrated into the CPU. So why not integrate like the old Altvec of PPC a Vector co-processor.
Why not use a generic chip designed for that type of instruction set? That way your not limited software versions for your hardware.
i thought once I was found, but it was only a dream.
Use Linux?
http://intellinuxgraphics.org/
All Intel drivers are open source on Linux. I have no idea about code quality or upkeep, so I will say nothing except I know they add regularly.
AMD has already implemented DirectX 11 in its Fusion low-power chips.
As has nVidia in GTX 400.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
So why not do it generically? IBM Cell chips integrate a Vector chip on the CPU. Intel and AMD both have video chips integrated into the CPU. So why not integrate like the old Altvec of PPC a Vector co-processor.
Why not use a generic chip designed for that type of instruction set? That way your not limited software versions for your hardware.
Because sufficiently generic hardware is not sufficiently fast at the desired task, graphics computation. Even with the optimization intel has put into this, they'll be MORE than an order of magnitude of graphics performance behind the dedicated solutions of their competitors.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Actually, on rereading your post ... I think it may actually meet your definition. It isn't hard-wired for dx11. There will be a driver. That driver can be modified/optimized later. The hardware is, in fact, generic graphics hardware, at least in the sense I think you mean.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
You can find Sandy Bridge GPU benchmarks at http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/11
"Intel's HD Graphics 3000 makes today's $40-$50 discrete GPUs redundant. The problem there is we've never been happy with $40-$50 discrete GPUs for anything but HTPC use. What I really want to see from Ivy Bridge and beyond is the ability to compete with $70 GPUs. Give us that level of performance and then I'll be happy.
The HD Graphics 2000 is not as impressive. It's generally faster than what we had with Clarkdale, but it's not exactly moving the industry forward. Intel should just do away with the 6 EU version, or at least give more desktop SKUs the 3000 GPU. The lack of DX11 is acceptable for SNB consumers but it's—again—not moving the industry forward. I believe Intel does want to take graphics seriously, but I need to see more going forward."
Note: all Sandy Bridge laptop CPU have Intel HD Graphics 3000
because DirectX sounds cooler to marketing?
Having to work for a living is the root of all evil.
Do you know some other way to do it? All graphics cards incorporate "hard-wired DirectX". If you are going to have graphics accelerators, they have to accelerate graphics. You can't meaningfully accelerate blits to frame buffers any faster than they already are. You have to accelerate higher level graphics abstractions. That's all DirectX is - an abstraction of higher level graphics operations. Any software, such as OpenGL, can (and does) tap into the more well chosen of those abstractions.
Given that DX is driving innovation in graphics cards at the moment and that GL is playing catch-up, the answer has to be "yes".
OpenGL has to please a large group with more uses than just games; it is done with input from the wide range of developers that use it. Its open, more democratic.
The DirectX dictatorship is faster and likely more efficient (in a way) but it comes at a price that wiser people are not willing to pay.
I'll take slow freedom.
If they could do everything ass-backwards without a speed loss just to make it extremely hard to port to/from OpenGL DirectX would do that. If they really just wanted to move faster, they could add layers above OpenGL and hack in new features into OpenGL; essentially fork it. They don't because there intention is not merely to be ahead of the curve; its about power.
Democracy Now! - uncensored, anti-establishment news
They actually may, seeing that the entire GUI frontend of EVERYTHING in Vista and Windows 7 is basically a multithreaded version of Direct 3D. Those "reflections" on the edges of the window frame? They're textures. And textures require mapping.
gtx 400 isn't integrated onto a cpu, which I think was the point.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Nvidia is making ARM CPUs.
The next version of Windows will run on ARM.
So, yes.
And if you're a Linux zealot, you can compile your kernel for whatever target hardware you want.
the idea is that you won't HAVE a bug if it's in the hardware
I can tell you've never developed graphics hardware or drivers... I'm sure the people I know who do that will be glad to know that they won't have to work around chip bugs anymore.
Why? What RISC architecture provides the same price/power/performance ratio that x86 provides?
POWER is fast and has an excellent power/performance, but entry-level systems cost ~$3500 after discounts.
Itanium is fast, but expensive and power-hungry.
MIPS is fast and power-efficient, but none of the players in the high-performance MIPS market have any interest in anything but network processors.
SPARC gives you two options - SPARC64 (slow, expensive, power-inefficient) and SPARC T-series (fast, but only for throughput-driven workloads; expensive; fairly power-hungry)
ARM has good power and price characteristics, but is slow compared to any production x86 chip except the Atoms and ULV stuff.
Basically, I'm not seeing a credible alternative to x86 for the market that it thrives in. If you want to pay up and get a nice fast RISC system, they're out there; alternatively, if you want a somewhat slower one for cheap, ARM is always available.
It's not really hard-wired hardware these days. The graphics chip runs code which is uploaded when the machine boots. Fixing a bug is usually just a driver update.
No sig today...
The chip's instruction set will be designed around the shading languages used in 3D graphics, it won't be very generic.
No sig today...
None of these chips execute 'Direct3D' or 'OpenGL' directly, they remap the functions to an internal 3D API.
OpenGL and Direct3D do mostly the same things so it's not much of a hardship for the driver writers.
No sig today...
I've worked with directX at a low level a bit, but no I've never actually to develop the hardware or the drivers for such devices.
What I was getting at is that if the Chip is designed specifically for DirectX11, you shouldn't have DirectX11 bugs. Yes, chip bugs definately do exist, but I would think (though I have no proof) that when a piece of hardware is designed for a specific task, it generally preforms that one task better and has issues elsewhere.
So what? If you don't like closed content, just don't use it!
And if you don't like the CPUs that support the creation of the closed content, just don't buy them!
Yeah exactly ... it wasn't at all clear how 'generic' the grandparent wanted ... so I actually replied twice depending on which level of generic they wanted.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
... Intel will make it easy to re-flash the chipsets when DirectX 12 comes out. Or to install OpenGL firmware instead.
Have gnu, will travel.
This isn't about just having a DirectX implementation, it's about having a general purpose CPU with graphics capabilities on the same chip.
Will Intel provide documentation so that other OSes will be able to make use of this feature ?
Sure. They already support Linux with other software products. They are a hardware company after all.
However if your preferred software license prevents content providers from support your operating system of choice that is not Intel's fault is it?
1) The same thing that happens when you install DirectX 10 on a DX9 card: the DX9 subset of DX10 is hardware accelerated, the DX10 parts are run in software.
What is guaranteed by DirectX 10 is that IF the card and driver supports DirectX 10 the application is guaranteed a set of functionality. There is no guarantee that the DX10 support will be there for a DX9 card. Usually the feature will not be implemented in software and you won't be able to run DX10 applications.
That said, boycotting closed media is likely to be just as effective as boycotting hardware that supports it
In other words, not effective. There aren't many (color) feature films or video games that are A. reviewed by the mainstream media (hence notable) and C. distributed under a license for free software and free cultural works from release day. This might have something to do with the fact that to my knowledge, nobody has yet exhibited a motive other than profit that can sustain a singular vision and production values comparable to mainstream movies and games. Free software succeeds at libraries and applications, which are defined by concrete requirements, but the requirement for a movie or game is less clear: a balance between familiarity and novelty combined with competence. So it appears fnj is right: good luck getting gamers to give up high-quality video games for the cause.
It really depends on what you mean. If you mean strict RISC, it was too late the day the term was coined. If, OTOH, you mean a nearly orthogonal architecture that is general purpose (plus the ability to call on specialized functions from attached processor chips), that seem, to me, a real possibility.
Before you jump, though, you must decide on what is the longest word size your computer will address and what is the smallest unit it will address. The larger (and the smaller) you go, the harder the task will be. If all you need is bytes and 64 bit words, then it's quite doable with current technology. (Actually, this is as of a decade ago.) If you want bit level addressability and 128 bit words...you're probably on the cutting edge of possibility right now. (Note that I didn't say practicality.)
The think is, an almost orthogonal architecture expands its requirements tremendously as you increase the dynamic range of operations. If you only operate on bits and bytes, it's nearly trivial. (8-bit computers). When the longest word is a double byte, each opcode needs to come in three variants. If you do bits, bytes, double-bytes, and quad-bytes, then each must come in four variants. Four variants can be specified in two bits. Now if you want to have 64 commands in four variants, that's one byte for the opcode. Then each but none of those include specification for the addresses on which it is operating. For economy we define the lower 4K bytes of address space to be the registers. And we make all addresses the same length. but how long? Well, we've got 64 instructions, we could divide it in half and have 32 that address different lengths of addresses. Or we could break symmetry, and have, say, 8 that address a 64 bit address space, 8 that address a 24 bit address space, and 48 that address the 4K registers. (Note that the registers vary in size depending on which instruction mode is addressing them.)
So it could (easily?) be done. Whether something that strict is desirable is a different matter.
OTOH, I do agree that the current processors are overly complex.
P.S.: The precise allotment I used wouldn't be a good approach. I didn't bother to figure things out carefully at all, but just laid it out on the fly. E.g., Why 48 operations on the registers? Just because I had that many bits available. I didn't bother to figure out what they would be.
OTOH, and interesting approach might be to implement, say, Parrot in hardware. (That's a feasible target and fairly well specified already.) But I'm not sure that it's what you mean by RISC.
(P.S.: I'm talking well out of my field here, if it wasn't obvious.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Linux will receive support directly from Intel for Ivy Bridge, with better timing than for Sandy Bridge (whose support for Linux was notably very late): http://www.phoronix.com/scan.php?page=news_item&px=ODk3Nw
These days each version of directx specifies a set of required features. A "DirectX 11 card" means a card that implements all the features required by DirectX 11. In this context it's perfectly reasonble to ask whether those features will be exposed to other operating systems.
this is a kind of a interesting line of thought to follow. One would suppose that the DX11 chip will be proprietary hardware acceleration that will integrate with the API. Now, because this is being baked into chips by Intel, they will have to provide documentation for anyone who wants to write drivers for this. If they don't provide documentation and/or to anybody but MS, I would think that they will probably run afoul of monopoly or racketeering laws. IANAL, but I don't think you can get away with that that sort of thing. In any event, the hardware can/will be reverse engineered and direct x will become a multi-platform feature. I don't really see this as a band thing, because while OGL is pretty awesome, a little competition is healthy for everybody. Here is hoping that this 'opens up' DX a little more and spurs more innovation all around.
HA! I just wasted some of your bandwidth with a frivolous sig!
Comment removed based on user account deletion
The GPU on sandy bridge consumes die area approximately equivalent to two CPU cores.
Unified memory architecture is an elegant thing, but it does require storing the framebuffer in main memory. At 1920x1080 with 32-bit color, the framebuffer is close to 64MiB. This will typically be refreshed at 60Hz, requiring 3.7GiB/s of memory bandwidth. That is quite a lot of bandwidth to be consuming 100% of the time. Incidentally, I recall that on my old SGI O2 R10k, it surprised me to find that algorithms touching only the CPU and memory ran a third slower at maximum resolution vs at 800x600. This was not a happy discovery given that the machine cost $19,995 and was meant to excel at graphics.
I realize that Intel GMA is not meant to excel at anything at all save for ripping some additional cash from my hand, but there's no need to integrate brain damaged graphics or wireless to achieve this. I would gladly pay for additional L3 cache or another CPU core or two.
Intel's Linux drivers are a lot slower than Windows drivers. Then again, they support more OpenGL extensions than Windows drivers.
Who is John Galt?
Now we have "core" OpenGL and deprecation procedures, I expect it will get easier for them. But in recent years both Intel and ATI have spent far more on their D3D code than they have on their GL code, which is why both are buggy, with Intel standing out in terms of crapness.
Because sufficiently generic hardware is not sufficiently fast at the desired task, graphics computation. Even with the optimization intel has put into this, they'll be MORE than an order of magnitude of graphics performance behind the dedicated solutions of their competitors.
Indeed, and this isn't even a hypothetical situation. Intel tried exactly what the GP wanted with Larrabee. It didn't work.
The enemies of Democracy are
Try harder... When I read this I wanted to burst: "Microsoft fanboi", actually MICROSOFT FANBOY! Actually OpenGL is driving innovation more but perhaps in a less flashy way that the latest whatever-shootin-game-is-popular-nowadays OpenGL has serious uses, like medical imaging, engineering etc... (on top of gaming) DirectX has... big budget run-of-the-mill gaming The winner is obvious.
I don't think so, no. Game development is driving consumer graphics technology, not medical imaging or engineering.
In future I expect GL to take the lead again because of its use in mobile devices. If I had to choose, I'd choose core GL (without all the extraneous crap that bloats it out) over D3D, because of its cross-platform possibilities, but at the moment I'm developing with D3D, because there's just a whole lot more in terms of libraries and tool chains that use it.
They aren't telling them how to makes their cards, they are telling them what features they have to support in order to be called a DirectX whatver compatible card.
Mada mada dane.
Yes CONSUMER graphics; stuff that allows you to watch 1080p movies and think it is somehow new or groundbreaking. That is what CONSUMER graphics is about...
The article linked compares the HD Graphics 3000 in the i5-2500k and i7-2600k against the HD Graphics 2000 in the i3-2100. It seems to me that it's impossible to judge the two different GPUs from that comparison because the CPU differences will have a significant effect as well as the GPU differences.
It's be nice to see a graphics performance comparison of an i5-2500 vs an i5-2500k or i7-2600 vs i7-2600k so the non-GPU differences are minimal.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
That's not what it's about at all, no. Please refrain from having an opinion on things you obviously know little about.
General purpose x86 CPUs have had instructions useful for doing graphics since the Pentium MMX. The first processor I'm aware of which really had substantial silicon for doing this is either the PPro, R5000, or Pentium MMX... depending on how you measure it.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
real servers seem to use pci based video mostly ati bases chip with about 32M video ram.
Oh really? I work in graphics programming (notably OpenGL-based) and have done so for about 15 years now.
Don't dare tell me that the DirectX "consumer" crowd isn't just kids playing their Xbox and watchig HD pr0ns and hollywood blockbusters on their Windows Media Center ?
Yeah I am sure their technical requirements must just beyond imagination and only DirectX can pull it off!
--
http://www.twilightcampaign.net/
At 1920x1080 with 32-bit color, the framebuffer is close to 64MiB. This will typically be refreshed at 60Hz, requiring 3.7GiB/s of memory bandwidth.
You're wrong. 32-bit is 4 bytes, so 1920*1080*4 is 7.9MiB/frame, 474MiB/s at 60FPS. With 20GB/s memories is not such a big problem. Of course, a dedicated bus and memory is better.
So, having not worked with D3D, you find yourself qualified to comment?
Yes, that's exactly what they're doing with their NVIDIA and ATI graphics cards. What exactly are you arguing here?
Before GL 4.1, that was the case, yes. DX10/11 and to an extent 9, made new features available. Drivers for OpenGL are generally more buggy than those of D3D (apart from NVIDIA based cards), because D3D is where the market is at the moment. Not the 1% doing CAD, the 99% playing games.
What's your point?
Who said I didn't work ON DirectX *cough*...
My point is exactly that: Direct3D is deficient in everything EXCEPT games. OpenGL is effecient for everything INCLUDING games.
The market as you call it is just Microsoft pushing dollars to software and hardware people to convince them to push for DirectX while in fact it would be in their own best interest to pay more attention to OpenGL, you know cross-platform and everything.
The market for DirectX is kids drinking MS koolaid
The market for OpenGL is anyone with a brain
Goodnight sir, enjoy your MS (free market, rofl) delusions.
--
http://www.twilightcampaign.net/
I was very happy when my new computer had a 166 mhz chip with "MMX Technology". They even included a pod racer game to show it off. It's all one generation away from being "on one chip" All of it.
Oh I see, you're a Linux troll. The reason you prefer OpenGL is because you can't use anything else.
I'm not sure why you have to be such a cock about it though.
I can use DirectX very well in Wine, thank you for bringing it up ;)
--
http://www.twilightcampaign.net/
You're confusing several things: the Altivec is a 'small vector' extension for the PPC not a 'co-processor',
modern x86 CPUs do have the equivalent: SSE(2,3,4,5) and AVX.
Note that AVX can manipulates 256bit vectors whereas Altivec is currently limited to 128bit.
As for the generic vector coprocessor ISA vs 'specific' video ISA, 'standardisation' has also drawbacks: the x86 ISA is really ugly and
has a cost in performance and power compared to something more modern such as the MIPS ISA.
Wine will give you 1/2 to 3/4 the performance of native D3D, along with all of the bugs not present in the original. It also doesn't support D3D 10/11 (at the moment). Again, I don't know why you have to be such a cock about it.
Of course you do not get nearly as much performance, D3D on Wine is a wrapper around OpenGL, if D3D would be Linux native this wouldn't be an issue.
However the speed of OpenGL compensates some of the losses introduced during the D3D calls translation process.
Again, I don't know why you have to be such a MS fanboy, and also why MS has to be such a cock and simply not give up on D3D and promote OpenGL, they are only hurting developers in the long run (by decreasing code portability)...
--
http://www.twilightcampaign.net/
"SPARC T-series (fast, but only for throughput-driven workloads; expensive; fairly power-hungry)"
Power hungry? They were marketed as super low power chips. I'm pretty sure there wasn't even a fan on my 8-core UltraSPARC T1.
As far as licenses go, as long as I'm allowed to listen to it, I don't see a problem
If you write your own song, and part of it happens to be similar enough to a song you had heard years ago, you have infringed. Bright Tunes Music v. Harrisongs Music.