My obsession with Android smartphone hardware continues. Because I'm lame.
Sprint is about to have two Android handsets on the market - HTC's Hero and the Samsung Moment.
The hardware couldn't be any more different between the two handsets. One has just softkeys, the other a slide-out keyboard. The Moment has an OLED screen. One has a trackball, the other has a proximity sensor. The biggest difference that I'm curious about is the processor.
The Hero uses the conventional 528 MHz Qualcomm MSM7201A processor, a chipset that claims 3D acceleration to the tune of 4 million triangles a second. The Moment uses Samsung's own 800 MHz S3C6410 which claims the same 4 million triangles per second with OpenGL ES 2.0 support.
I'm not sure who wins, especially since the Hero has an entirely different UI and a lil' bit more RAM (288M vs. 256M). With OpenGL acceleration being about the same... hard to say.
Showing posts with label opengl. Show all posts
Showing posts with label opengl. Show all posts
Wednesday, October 14, 2009
Monday, April 27, 2009
What I've Seen with Your Eyes
Eskil posted the video for his GDC presentations and they're abso-freakin-lutely amazing.The gameplay of Love was interesting, but the video displaying the tools Eskil created are completely mind blowing. It's the stuff that actually gives you hope for the world again. The GDC tool video shows off several tools Eskil has released: Loq Ariou which allows you to create assets & models with the same ease as a pencil & scratch paper, Co On which provides scene mapping that's startlingly similar to how you might visualize things in your own mind, and Verse, a data transfer & protocol standard that allows such data to be shared instantaneously between applications.
Obviously Eskil had to create an intelligent set of tools to properly build Love within a decade, but I had no idea he had constructed such a cadre of tools that could be re-used by other developers. Not only does he speed content generation up and provide better interfaces - he goes one step further by breaking down human factor boundaries that plague every other asset generation tool to date. Just watch the video - especially the portion demonstrating shaders in Co On - and you'll see why I'm going completely nuts over these releases.
Eskil is giving back a huge amount to the community at large with these tools, and is likely opening the doors for many, many others to creatively express themselves in ways that were once prohibitively difficult. Love isn't just creating a fanbase... it's creating a legacy.
Tuesday, March 31, 2009
I Heart NVIDIA
Awww... NVIDIA. I love you and your driver updates, especially now that they're coming once a month to *nix.
Sunday, July 13, 2008
KDE 4 Really Fast, Except When It's Really Slow
I've enjoyed openSUSE 11.0 not necessarily because it works flawlessly, but because it's the best working install of KDE 4. KDE 4 has a lot of great potential, but it's not fully realized until you hit KDE 4.1. Since 4.1 is the actual version of KDE 4 meant for widespread usage, I've been downloading the unstable builds from SuSE's build service.
Things have been working fine except for one extremely nagging thing - the initial draw of a konsole window takes 5-10 seconds. It's extremely obnoxious, especially when you need a terminal so often.
I found out this was due to NVIDIA's drivers on newer boards - as described in the KDE techbase and illustrated in the Ubuntu forums and How-To's. Luckily it was an easy fix - running
The Linux Hater's Blog brings up a great point about Xorg not being about to allocate offscreen buffers - something that I didn't realize. Xorg lacks a memory manager, so all the stuff you need for full OpenGL support just can't be done. It simply can't be done with Xorg. All the points made in the rant are absolutely right - the memory management infrastructure for pbuffer and framebuffer objects have to be there, otherwise you're hosed.
The core issue that comes from this deficiency is that X11 in and of itself is inherently unable to support OpenGL. Lack of offscreen buffers means that all the great stuff you should be able to do directly in hardware can only be accomplished with a software renderer. Of course, this defeats NVIDIA's entire business model of making the GPU the most important part of your workstation. So they had to massively replace parts of X11; the NVIDIA Linux drivers must, by sheer necessity, replace huge chunks of the XOrg implementation.
After reading the Linux Hater's post a lot of other stuff made sense - why NVIDIA's drivers are so invasive, why you magically don't need to install Xgl to run Compiz Fusion if you are using the proprietary nvidia driver (because it already replaced Xorg for you, thanks), and why KDE's desktop effects had window resizing slowdowns.
NVIDIA didn't break things - they fixed things. They're just trying to live in our broken world.
Things have been working fine except for one extremely nagging thing - the initial draw of a konsole window takes 5-10 seconds. It's extremely obnoxious, especially when you need a terminal so often.
I found out this was due to NVIDIA's drivers on newer boards - as described in the KDE techbase and illustrated in the Ubuntu forums and How-To's. Luckily it was an easy fix - running
nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1 as root set the appropriate settings in the NVIDIA driver to allow windows to resize at the speed they should. But I don't necessarily blame NVIDIA - the blame deserves to be cast further.The Linux Hater's Blog brings up a great point about Xorg not being about to allocate offscreen buffers - something that I didn't realize. Xorg lacks a memory manager, so all the stuff you need for full OpenGL support just can't be done. It simply can't be done with Xorg. All the points made in the rant are absolutely right - the memory management infrastructure for pbuffer and framebuffer objects have to be there, otherwise you're hosed.
The core issue that comes from this deficiency is that X11 in and of itself is inherently unable to support OpenGL. Lack of offscreen buffers means that all the great stuff you should be able to do directly in hardware can only be accomplished with a software renderer. Of course, this defeats NVIDIA's entire business model of making the GPU the most important part of your workstation. So they had to massively replace parts of X11; the NVIDIA Linux drivers must, by sheer necessity, replace huge chunks of the XOrg implementation.
After reading the Linux Hater's post a lot of other stuff made sense - why NVIDIA's drivers are so invasive, why you magically don't need to install Xgl to run Compiz Fusion if you are using the proprietary nvidia driver (because it already replaced Xorg for you, thanks), and why KDE's desktop effects had window resizing slowdowns.
NVIDIA didn't break things - they fixed things. They're just trying to live in our broken world.
Subscribe to:
Posts (Atom)