Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Not open-source but another RPC layer! (Score 1) 77

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.

See for example.

Comment: Re:Now intel users can play 10 year old games :D (Score 1) 133

by xynopsis (#43610431) Attached to: Haswell Integrated Graphics Promise 2-3X Performance Boost

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.


+ - Valve's SteamBox codenamed 'Piston', early specs detailed at CES->

Submitted by xynopsis
xynopsis (224788) writes "Looks like the final version of the Linux based Steam Gaming Console has been made public at CES. The result of combined efforts of small-form-factor maker Xi3 and Valve, the gaming box named 'Piston' is a potential game changer in transforming the Linux desktop and gaming market. The pretty device looks like a shrunk Tezro from Silicon Graphics when SGI used to be cool."
Link to Original Source

Comment: Re:Intel GPUs more open prospect than ARM (Score 1) 163

by xynopsis (#42386449) Attached to: Intel Challenges ARM On Power Consumption... And Ties

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.

Comment: Re:It's not broken. (Score 1) 1154

by xynopsis (#41271505) Attached to: Ask Slashdot: How Would You Fix the Linux Desktop?

- 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.

Comment: NASA rejected the other riskier bets... (Score 2) 61

by xynopsis (#41060475) Attached to: Next Mars Mission Selected For Funding

...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.

Comment: This has been expected (Score 1) 1

by xynopsis (#40928753) Attached to: Digia to acquire Qt from Nokia

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.

Linux Business

+ - Digia to acquire Qt from Nokia 1

Submitted by
MrvFD writes "Ever since the most recent layoffs were announced by Nokia last month and the end of Qt related programs at Nokia was rumored, the fate of Qt has been in the air despite it nowadays having a working open governance model. Fear no longer, Qt brand, since Digia has now announced acquiring of Qt organization from Nokia. While relatively unknown company to the masses, it has already been selling the non-free (non-LGPL) licenses of Qt for 1.5 years. Hopefully this'll mean a bright future for Qt in co-operation with other Qt wielding companies like Google, RIM, Canonical, Intel, Skyp... Microsoft, Jolla and the thousands of Qt open source and commercial license users. Digia now plans to quickly enable Qt on Android, iOS and Windows 8 platforms, where work has already been underway for some time."

Comment: Nothing special about this (Score 4, Informative) 187

by xynopsis (#33076894) Attached to: KDE SC 4.7 May Use OpenGL 3 For Compositing

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

First Person Shooters (Games)

Quake 3 For Android 137

Posted by Soulskill
from the can-i-get-a-hell-yeah dept.
An anonymous reader writes "Over the last two months I ported Quake 3 to Android as a hobby project. It only took a few days to get the game working. More time was spent on tweaking the game experience. Right now the game runs at 25fps on a Motorola Milestone/Droid. 'Normally when you compile C/C++ code using the Android NDK, the compiler targets a generic ARMv5 CPU which uses software floating-point. Without any optimizations and audio Quake 3 runs at 22fps. Since Quake 3 uses a lot of floating-point calculations, I tried a better C-compiler (GCC 4.4.0 from Android GIT) which supports modern CPUs and Neon SIMD instructions. Quake 3 optimized for Cortex-A8 with Neon is about 15% faster without audio and 35% with audio compared to the generic ARMv5 build. Most likely the performance improvement compared to the ARMv5 build is not that big because the system libraries of the Milestone have been compiled with FPU support, so sin/cos/log/.. take advantage of the FPU.''

Thrashing is just virtual crashing.