Unfortunately, if you look at the "driver sources" carefully, it's just another shim to the real driver that does the heavy lifting. This implementation does not submit GPU instructions directly nor does it expose the shader compiler where someone can trace how shaders are being transformed into native instructions. In the end, it's just a layer that just submits user data to some specialized (probably proprietary) ioctl that exposes the functionality of the real driver implemented as a binary kernel blob and/or microcode running on the firmware.
Slashdot videos: Now with more Slashdot!
Honestly unless you are playing Crisis they are getting pretty good. I played Portal 2 on IGP. That is two years old, but the laptop I played on was already a year old at that point.
New Intel IGPs does handle Crysis with fluid framerates even with quality settings turned high.
Link to Original Source
You either don't know what you're talking about or just plainly trolling. The GPU specs that Intel opened is the CoreHD graphics series which is Intel's own GPU technology and is in no way related to ImgTech's PowerVR.
I am looking forward though to the real competition between ARM's latest and greatest with Intel's upcoming Haswell.
Hard drive heads ride on a cusion of air (or in this case, a gas of some kind) so that they don't crash against the drive.
Why a gas? Why not float it using an electromagnet instead?
- Create a desktop kernel fork. Linus & co. are not in the business of writing/maintaining a desktop kernel. Their goals are larger (and smaller) than that. The desktop kernel can track the mainline kernel, but shouldn't adopt every latest ABI or other changeâ"just do a major update every 3-5 years.
What on earth would that achieve? And what is the difference between a "desktop kernel" and a "server kernel" or whatever.
One glaring example of this is the kernel scheduler. If you ever used the OSX / IOS notice how smooth the graphics is and well responding it is to touch events even under heavy load compared to Linux desktops / Android. Although there have been much improvements done in Linux recently especially Android stack that smoothes the UI experience, occasionally you will still encounter random hiccups in the UI (even with a quad-core CPU). Same is true with other Linux-based such as the Nokia N9 Harmattan, where although the graphics is pretty much smooth, the user sometimes encounters stuttering when swiping or scrolling windows.
As the GP pointed out, part of the problem here is that the Linux kernel have vested interests towards server infrastructures. The current scheduler, CFS (tries to) balances CPU utilization and user interactivity fairly. If Linux were to achieve a more smoother response we need a scheduler for extremely low latencies instead of fair prioritization.
There is a project to change the scheduler towards this low latency approach, but even the project author is not expecting it to be accepted in mainline soon - the reason why we need a fork.
...but insanely exciting missions: a robotic boat that would have floated on a methane lake on Saturn’s moon Titan and a comet explorer. I would prefer the robotic boat. You never know what lurks beneath those lakes (TMAs?). This is unfortunate though. Seems NASA has mastered the technical hurdles of Mars but rested on its laurels instead, sticking to tried and true approaches.
Yet another result of Elop's mismanagement of a once great organization. Qt would have been the platform that powered the next generation smartphones to low budget featurephones. Too bad Qt wasn't given a chance due to this guy's ties with his former employer.
I just wished instead the old Trolltech would rise again.
I once saw this concept videovideo at Nokia Research Centre in Helsinki more than 3 years ago. Too bad Nokia failed to capitalise it on time and now they are failing big time.
Seems? How can you say it is sluggish you haven't even tried it out personally? Or were you just judging the performance based on the videos. I have the prototype and it is extrememely fast and snappy indeed. Even Engadget which is biased towards Apple is impressed
Looks like the lightsaber training ball used by Luke
Just the need to upgrade how Kwin uses OpenGL currently to do rendering. Right now its still using the old OpenGL 1.1 - style rendering (fixed-function rendering pipeline) to a programmable one using vertex and fragment shaders. This way, it'll be easier to port it on embedded devices that uses OpenGL 2.0 by default