Slashdot Mirror
Intel Releases Ivy Bridge Programming Docs Under CC License
An anonymous reader writes "The Ivy Bridge graphics processor from Intel is now fully documented under the Creative Commons. Intel released four volumes of documents (2400+ pages) covering their latest graphics core as a complete programming guide with register specifications. Included with the graphics documentation is their new execution unit and video engine."
nVidia should have bit the bullet and done the same thing. Could have benefited them financially and boosted consumer satisfaction.
If you won't allow us to write software for your crappy cards, then they'll be no software for your cards. I don't understand why these Microsoft-style closed source morons always think not allowing people to use what they sell will help them. They're letting their paranoia get in the way of good business.
And a showstopper for those other graphic card makers (AMD/NVIDIA) with their halfbaked support for Linux.
I would've got first post, but I'm still reading TFA. Only two thousand pages to go...
The documentation referenced is available from Intel Linux Graphics: Documentation.
We've come a long way since the 47 registers and paltry documentation of the Commodore 64's 6567 video chip. My question is, who can actually master these modern systems before they are obsolete? No one person, I think, can gobble 2400 pages of documentation to work with a graphics system. Are people now merely specialists of one tiny subset of a system, never to understand what is going on overall? That might explain why we need 600M device drivers these days.
This is a release of a large and very complete set of formal documents, but open source driver code (GPL'd and part of the mainline Linux kernel) has been released under a public development process since just after Sandy Bridge first came out in preparation for the Ivy Bridge launch. This code is written by paid Intel employees.
Incidentally, large portions of the DRM infrastructure in the kernel *and* the X server *and* the upcoming Wayland project are all being made by paid Intel employees. Note that this development work also has major benefits to the open-source AMD driver development and we would all be better off if AMD (not to mention Nvidia) adopted Intel's approach to paying people for open-source work.
In a similar manner, there is already 100% GPL'd code that is available for the next-generation Haswell graphics engines. Obviously at this stage it isn't complete, but things are not hidden behind closed doors and, just like Ivy Bridge, there should be solid launch-day support for the Haswell IGP. Considering the rumours going around about the extra resources that Haswell will offer for the GPU, this could chip could provide very solid launch-day out-of-the-box graphics support in notebooks and other devices that don't require a dicrete GPU.
AntiFA: An abbreviation for Anti First Amendment.
This is a good thing - it means that open-source drivers can now be written that will be adequate for most users. Unless you are doing heavy 3D gaming or HTPC, Intel's products are fine.
For HTPC, Intel would be a great choice if only they'd finally fix that lingering 23.976 FPS bug. They just don't seem to be taking it that seriously, though, since it's existed since the G45 days at least. Also, I don't know if this is supported through the registers (even the documents may not make it clear) but it would be great to have real YCbCr 4:2:2 output – AMD cards claim to do this, but they are actually converting the data from YCbCr (on DVD/Blu-Ray) to RGB and then back to YCbCr for output. Allowing source-direct YCbCr output (which currently only dedicated SoCs can do) and fixing the 23.976 FPS problems would make Intel-based HTPCs a viable option at the high end. (Advanced videophiles want to use a dedicated scaler device, which offers much better scaling and/or deinterlacing results than what software and average standalone players can do.)
Direct link without the Phoronix fluff:
http://intellinuxgraphics.org/documentation.html
I'm curious how many Stream processors Intel can fit into a dedicated chip.
I am John Hurt.
...by releasing their documentation under the Creative Commons license, Intel saved enough money in lawyer fees to purchase a new fab...
http://www.beanleafpress.com
Try not having ancient hardware from before intel started doing decent gpus, that always tends to help.
Well, wasn't the whole P4 thing a failure?
I urge you, take another look at a ivy/sandy bridge gpu.
Let's see...you're basing your opinion on a comparison of an i845 chip from 2002 to a GeForce 7025 from 2006. Hey, Rip Van Winkle, guess what? We're in 2012 now. Intel graphics chips have improved greatly in the 10 years since the i845 came out. Please stop posting, your stupidity and inability to update your knowledge is making Linux users look bad.
Maybe this isn't news to you, and you do make a valid point about this story not being news. But not everyone follows Intel as closely as you do. I was glad to read this article and to know that I could buy a computer without having to worry that the next Linux update or upgrade would render my graphics performance to be slow and chunky. Of course, whether or not my graphics card is supported on Linux depends on the open source development community, but the odds of good support are much better with open documentation.
The diversity and expression of human opinion is essential to human survival.
Well, both Intel and Linux have come a long way since the Pentium 4 era, so I don't think it's fair to use a 10-year-old chipset as an example to avoid Intel GPUs now. Is also isn't fair comparing a 2002 iGPU to a 2007 iGPU. Of course the 7025 still works and is supported - it's much newer. My 2003 FX card, however, won't render anything GTK3 properly, it's completely abandoned by Nvidia and a very low priority for nouveau developers.
Intel publishes ( for free ) nearly all their architecture documents. It's been their business model since the beginning... how else would the X86 platform exist?
Someone clearly fell asleep in the 1990s, when Intel were so terrified of the V86 extensions being copied by AMD that they wouldn't tell anyone except Microsoft how they worked. People actually reverse-engineered it and released their own documentation before Intel was willing to allow things like Linux DOSEMU to use it. This did not endear me to Intel back in the day.
Indeed, an interesting relic from that era is my Turbo Assembler 5 manual. It has a number of blank entries in it for Pentium instructions, e.g.
RDTSC (Proprietary instruction. Contact Intel for more Information.") - Turbo Assembler Quick Reference, p.118
I doubt the issue is with the hardware itself. Issues with "hardware" are generally driver or firmware related.
nVidia is afraid of its competitors, namely INTEL getting better 3D tech. I guess Imagination tech, and ARM's Mali count. Imagination and AMD have been around for a long time, so their teams don't really need practice (Kyro, ATI). Intel has the money, engineers and fabs to steamroll its competition. Intel has already grabbed half of the 3D market by integrating its inferior graphics. Imagine what they could do if their 3D team was among the best. It will happen eventually.
So, in short, nVidia doesn't release hardware details, because of fear of Intel.
For those of us who don't want to waste time actually downloading the PDFs buried in links from the phoronix story, the license is CC-BY-ND, so you can access it freely, and use whatever you want, but god forbid you should fix a typo.
I compared them because it was a direct replacement. The same things are true of every other NVidia card I've got... My 8400, Geforce 4, etc., all similarly "just work" like they should, and always have. Intel is the one releasing hardware with all kinds of issues.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Funny. I categorically won't even consider anything EXCEPT Intel graphics hardware for linux. It does a beautiful job for anything I need. Not only 10 year old stuff, but the latest. I've got both ancient 865 and 945, and two Sandy Bridge systems running PUIAS6 (free RHEL6 clone) and other distros - flawlessly.
I wouldn't use Nvidia and AMD power hog crap even if completely capable linux drivers WERE available open source. I don't need dozens of wasted watts to draw text and little pictures on my monitor. And I certainly don't need it to play HD accelerated video.
I thought that AMD had a number of devs working on open graphics drivers and on other open stuff like Coreboot...right?
Here's their "Open Source Zone", and here's Kevin Tanguay's blog post of May 5, 2011 (emphasis mine):
coding is life
I recently got a TI AM3358. Its technical reference manual is 4200+ pages and at the end of the day you are still missing some crucial bits of information.
Of course this document does not include any details about the ARM core, the graphics accelerator and the programmable real-time unit.
Pinout, timings, and electrical characteristics are also in a seperate document, as usual.
I propose an amendment to slashdot whereby anyone posting a "Why is this news?" post has their account deleted and ip banned. I feel confident in saying that since I have been on slashdot, there has not been a single "Why is this news?" post that added anything of value to the conversation.
Under RHEL6.x, it was a non-starter... 30 minutes of use or so, and the screen stops redrawing. You've got a mess on your screen, and (thanks to KVM) restarting X11 doesn't fix it... you have to completely reboot.
No, you've got a mess on your screen, and you have to completely reboot.
systemd is Roko's Basilisk.
Man, it seems like every other sentence in that article is a link to another Phoronix article. I count 14 Phoronix links in there, and the actual link to the Intel docs is buried in the middle of that.
http://intellinuxgraphics.org/documentation.html
Mada mada dane.
YCbCr 4:2:2 output
What interconnect do you use for this? What kind of display devices will accept it as input?
Also there's probably both highlevel and lowlevel APIs, instructions or modes on the video chip, and in order to write a video driver you probably don't need to understand the internal lowlevel instructions. If you want the write the optimal video driver, you probably do... But optimal code is pretty hard to write
My question is, who can actually master these modern systems before they are obsolete?
I think a small group of dedicated people and maybe some intel engineers.
But fully utilizing them before they are obsolute, is probably not possible, but keep in mind that todays apps are written in Javascript and HTML, when will that EVER utilize anything efficiently?
Back on topic, the next card intel release will probably use the same or fairly similar architecture, so what you learn in these docs are probably not obsolete when intel release a new video chip...
How does a dedicated scaler device offer much better results than what software can do? Does it use some magic process that isn't reproducible using a Turing machine?
Funny. I categorically won't even consider anything EXCEPT Intel graphics hardware for linux. It does a beautiful job for anything I need. Not only 10 year old stuff, but the latest. I've got both ancient 865 and 945, and two Sandy Bridge systems running PUIAS6 (free RHEL6 clone) and other distros - flawlessly.
I wouldn't use Nvidia and AMD power hog crap even if completely capable linux drivers WERE available open source. I don't need dozens of wasted watts to draw text and little pictures on my monitor. And I certainly don't need it to play HD accelerated video.
Good points, but how can I buy an (otherwise) high-end laptop with "only" intel graphics? How can I get a quad-core i7 with full HD (or better) and intel graphics? The high-end laptops all come with nvidia, amd, or sometimes a choice between the two. Intel is only offered on low-resolution screens. :-(
Intel has enough hardware developers that the don't typically need to license third party IP to get the job done. Many silicon vendors don't have that luxury and cannot risk incidental leaks of IP details for which they could be held liable. Lets see how much documentation Intel releases for the Atom smartphone chips with PowerVR GPUs.
Plain old RCA cables like you use for composite video, except you use three of them. Most HDTVs have a set of component inputs for this. It was the analog standard used before DRM, and thus HDMI, was mandated by the content assholes.
More info:
https://en.wikipedia.org/wiki/Component_cable
https://en.wikipedia.org/wiki/YCbCr
HDMI and DisplayPort both support this, and lots of displays will accept it as input. For example, both my home theatre projector (Epson PowerLite 8345) and my desktop's computer monitor (Dell U2711) will accept YCbCr input.
In fact, dedicated media players (such as my PS3) are already outputting YCbCr, so I'm currently using this... Of course, ultimately, it gets converted back into RGB at display-time, since all display devices are RGB.
Fixed-function hardware can implement an algorithm much more efficiently than software. Reproducing what the dedicated scalers do in software may not be practical.
This makes sense because Slashdot is exactly like a constitution.
http://en.wikipedia.org/wiki/Slashdot versus http://en.wikipedia.org/wiki/Constitution
Completely identical!
Except you're discussing ancient GPUs and extrapolating your experience with those to the assertion that they are currently releasing hardware "with all kinds of issues"
Modern Intel GPUs work rather well.
A hardware manufacturer that supplies an instruction manual. Big bonus points for having that instruction manual available under a permissive license.
Intel have had this attitude for quite a long time and their graphics are steadily improving too (already more than good enough for my needs). ATI and NVidia seem to be too busy competing with one another to see that the market they are fighting over is becoming niche. Their occasional token gestures to the community are merely small publicity stunts to the constant support provided by Intel. ...Man, I didn't think Nvidia could suck so hard for so long that they could actually breed Intel fanboys but here I am. :)
What interconnect do you use for this? What kind of display devices will accept it as input?
YCbCr 4:2:2 is part of the HDMI standard, so you would use a regular HDMI cable. Videophiles would run this through a stand-alone video scaler like the Lumagen or Crystalio, so that the scaler could see the exact decompressed data from the original video stream instead of having it already pre-processed into RGB (which is a lossy process on the 8-bit channel values used in digital video).
FWIW, my Sony TV takes YCbCr input just fine, and I think most other HDMI devices do as well.
How does a dedicated scaler device offer much better results than what software can do? Does it use some magic process that isn't reproducible using a Turing machine?
I'm sure you could replicate it using shaders on a video card (or more slowly on the CPU) if you had access to the exact algorithms used. But the companies that produce dedicated scaler devices aren't going to make these algorithms publicly available, since keeping them a trade secret is in their financial best interest. And Intel, AMD, and nVidia don't place the same high priority on making the absolute best scaling and deinterlacing algorithms as do companies to whom this is their core business.
That's hilarious...as if RDTSC would be difficult to figure out what it did.
Read Data 'Till System Crashes?
-- I have a private email server in my basement.
I'm going from memory, but facts were a bit different. the RDTSC had gone through various incarnations in different versions of the x86 processor, and they were afraid that if they made it publicly available they would have to forever support it in the name of backwards compatibility.
This is not an unreasonable fear, given of the x86 IS has survived all thee many years.
I should note that my copy of the Intel Instruction Set Reference from around 2003 has documentation for RDTSC
The important ones anyway.
agree LOL using P4 GPU, intel did not start making good GPU/CPU until core (2,3,5,7) i suggest you try IvyBridge GPU/CPU and than make up to date opinion
A real video nerd knows that LCD matrix is by design RGB so even if display would receive non-RGB, it would still get transformed internally to RGB using algorithms that we can only guesstimate therefore most would rather do it on PC where sometimes it's possible to know the whole chain and be sure that it's not doing something silly and quality reducing. Anyway, what you should want is at least 10 if not 12 bpc (bits per channel) RGB which coinidentally, HDMI can't deliver, you need DP for that.
It's a fair question. My usual answer to most of this class of question is to say Lenovo. Check out the Lenovo 530. Hit the customize button. You will be able to pick all the way up to Core i7-3520M, display type up to 15.6" 1920x1080 LED backlit anti-glare, and still pick Intel HD Graphics 4000. It takes a little diligence to see what they will let you build. There are two even higher processors which for some reason they won't sell without Nvidia; who knows why - but this ones fills the bill. I am sure there are others.
BTW, Lenovo rules.
They might be slow, but:
- They *DO* end up releasing specs. (Although after a long time in legal checks before getting approved for release).
- They do *PAY* developers to write open source drivers for their GPUs.
This has ended up well nicley for them: unlike Nvidia, they have a nice opensource driver that can be ported to chinese (MIPS based) CPUs, bringing lot of money to them. (Also in five year, expect cheap chinese clones of current Radeon GPUs :-P).
(And its not the first time that the opensource driver has been useful for AMD: they have ported it for Windows Embed Compact 7).
Also if you follow news on phoronix:
AMD is working on better collaborate with the opensource world, and better keep it in mind in their production piepline. The target is to have less legal checks before releasing specs, and have more opensource friendly components (less problem with the video DRM).
The long term plan is to reach the kind of integrated opensource development that Intel is enjoying with same day support.
So in a few year, they will probably reach intel-levels of support. For now they aren't as good, but at least, unlike nvidia, they show that they put some efforts in there.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
My question is, who can actually master these modern systems before they are obsolete? No one person, I think, can gobble 2400 pages of documentation to work with a graphics system.
The engineers who designed the chip know it at best.
And the good thing is that with intel, they collaborate with the drivers writing efforts early on. Drivers are written all the while the hardware is designed.
At the end, not only to you get a massive documentation, but you get piece of (L)GPL code written by the very few people who have an understanding of how the system works.
But yes, nowadays, the barrier of entry for writting driver is rather high and requires collaboration between hardware and software design.
That's why there's a time gap between when a company starts to open specs and when there are nice drivers.
Intel started very early on, so now they've reached the point where each new hardware can be released together with specs and opensource drivers. (The 2400 page get written at the same time as the code is developped, both by the very persons who know it at best).
AMD started later, when they acquired ATI. Their process isn't as streamlined: specs must undergo check from the legal team (they have to check the AMD evuivalent of 2400 pages before publishing) and are released a little bit late, the latest drivers still lag behind the latest hardware (the developers need to read said AMD 2400 page before a driver is written), etc. But if they keep their work up (and the recent chinese hardware purchase might help) they can reach the level of support that Intel has.
Nvidia doesn't play along, so the opensource efforts are still at the reverse engineering part. Given the complexity of a modern GPU, that's a tremendous work for the Nouveau team.
What also helps is that there isn't often a huge break in architecture in GPUs. Most of the generation are very often "same as before, only with more parallel units, and a few tweaks and minor features here and there (on a smaller process with faster clocks)". So by the time someone finish reading the 2400 pages, chances are high that the then Intel GPU will be roughly the same, only 24x the number of units, at half the nanometer, running on a 3x faster clock, with some minor block having changed here and there.
The chips will be outdated. But the global architecture, won't necessarily, and thus the documentation won't be that much obsolete.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
It's not really obvious where you can divide a driver up into sections, so the division-of-labor thing doesn't work.
Well currently, Linux GPU drivers are *already* separated into several parts:
- there's the kernel module (DRM) which is in charge of initialising the card, modesetting, and saving/restoring the state for suspend/resume. Texutre uploading/buffer object downloading is partly handled here, in cooperation with the in-kernel GPU memory management.
- then there's the Gallium3D back end which exposes the basic building blocks (shaders, etc.) to the Gallium3D modular API so front-ends can handle the APIs (OpenGL, OpenCL, etc).
- then there's the LLVM-backend (also used by Gallium3D) which handles compiling the shader code into machine code usable by the GPU.
Most of the three are separated, and can be written separately, although they are chonologically interdependant (you need some basic modestting, before starting to play with 3D, you need some API and some 3D or (GPGPU) before compiling shaders).
Usually 3D support appear in that order.
It gets tricky with GPUs because you are expected to provide a whole bunch of things that are not strictly drivers, OpenGL implementations, for example.
Thankfully, the modular / consolidation approach of Linux partially helps this:
- memory management is handled by a dedicated in-kernel facility (GEM, TTM).
- API are handled by the various front-end of Gallium3D: OpenGL, OpenCL, various 2D and video accelerations (there's even an experimental DirectX 10/11 state tracker). As long as the driver back-end exposes enough functionnality, the API get automagically supported.
So for example, getting OpenCL to work on opensource AMD wasn't writing a complete library from the ground up. It was a two way effort, with Gallium3D developpers bringing what opencl state tracker they had (clover) back into shape. And AMD developers writing the necessary bits so the r600g back-end could expose the necessary functionnality for clover to work on it.
The bad part of this, is that current opensource Linux drivers are all stuck with what API is available in Gallium3D: openGL is still at 3.0 (instead of 4.2)
The good part of this, is that getting newer openGL version to work doesn't require each team writting its own driver, but can be achieved globally for everyone involved by collaborating across teams.
As the work force involved is ramped up (AMD will probably ramp up its opensource team after the deal with china, 3rd parties like VMware also develop code for Gallium3D (and even bought Tungsten), even Valve has been reported toying with the idea of paying Linux (non-game-)developers now that they are slowly porting their stuff to Linux, etc.) the gap will probably slow over the next years and will end up with linux drivers following the next APIs.
The state of support for opencl is a nice indicator: it's an API which appeared much more recently than OpenGL, at a time when development is already better organised, and thus a relatively short amount of time was necessry before the first hardware opensource support for openCL arrived. OpenCL is more or less starting to get support for the latest version in Linux.
OpenGL is worse because it started earlier. Back then there wasn't enough muscle to keep Mesa3D up to date, and by now even if the situation is better, there's still a lot to do to catch everything that hapenned in between up.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Intel would love a fully optimized OpenGL 4.2 engine when they're working on Mesa that's still on OpenGL 3.0 as far as I know.
Even worse, for their older hardware, the still use the classic (non-modular) part of Mesa, so they don't even get full OpenGL 3.0.
At least Gallium3D (the modern modular part of Mesa) is fully OpenGL 3.0 and is slowly being developed onward. It's used by the oficial AMD opensource drivers, by Nouveau, by the Intel official driver for the latest generation, and some experimental drivers for older generations done by tungsten when they started toying with the idea (and some further development done by google as they are interested for their ChromOS).
Also Nouveau and the opensource version of AMD will also benefit from an OpenGL 4.2 implementation, thanks to the modular architecture of Gallium3D.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Yes they do. Only they have very few developers on the graphic drivers (a couple of guys), whereas Intel had a whole company (Tungsten graphics, now bought by VMWare) writing their drivers.
They'll probably now ramp up their opensource team after getting the chinese deal.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]