Skip to content


iPhone CellID information for Bangalore – Airtel

After having read about the location tracker information that the iPhone stores on backup records. Using the MAC application decided to test it. You would be surprised to the extent of information it can visually display on the map. Here is a snapshot of Airtel Cell coverage in Bangalore. Maybe others in the area can publish such information to create a OpenCellID information database that can be used to provide FOSS services in the city.


here is the link to the application

http://petewarden.github.com/iPhoneTracker/


Posted in Hacks.

Tagged with , , , , .


Concept Product Renderings

I have been fascinated with concept renderings, especially for user interface related products. Due to lack of 3D tool skills like Alias or 3D MAX. I made best possible use of Omnigraffle and Apple Keynote to render some of the product concepts. Most of the UI has been constructed using Keynote drawing elements and Omnigraffle vector elements and modified stencil objects. If you like the source for this kindly email me. I would be happy to share it.

Energy Meters have been a rage these days with Micro-Controller device manufacturers especially the ARM M4 series and SH processors. The concept is a low cost design based on Zigbee or DECT basestation with Wifi to fetch information from other connected elements like PowerMeter, WaterMeter, Heating or Natural GAS and utility machines.

Schedule Wizard : We have had experiences that meeting rooms despite being booked on share-point or Outlook or any other web-based tools would be unavailable just because somebody occupied despite a reservation. It would be kinda of cool if meeting rooms are access controlled like conference calls, only the moderator can open the call. Added to this we usually don’t have an idea on the meeting in progress or the duration if you just walk by the room. In the age of tablets this should be a problem that could be easily solved. Communication and display is no issue. But rather its about industrial design, power and usability.I took a shot at a mockup for such a display device.


Posted in General.

Tagged with , , , , , , , .


Slashdot icons

Slashdot the geek news website has constantly improving its look & feel. Here is a collection of the icons found on its website.

If you happen to use google chrome , then use developer tools and download these icons. SOme have very interesting design.


I especially like the Microsoft icon, Mr Bill as a cyborg.


Other notable ones are Patent pending


DRM ->straitjacket


Programming


IT -> The red swingline stapler from Office Space

Here is what they say regarding the re-use policy

Can I use Slashdot icons freely on my site?

Yes, we are fine with you using any icons from Slashdot on your site, provided you ask permission, and you link us back and credit us as the source for the graphics. Thanks to Artua for helping us with the latest batch of icons.

Of course, some of the icons are copyrighted by other people. So, you’ll have to decide for yourself if you can actually use them under fair use. Some of the general icons are provided via Glyphish and you need to buy a license. Social media icons provided via Icondock


Posted in General.

Tagged with , , .


OpenGL ES Simulators & Emulators

If you are into developing mobile applications you have certainly used emulators or simulators in some form. To clarify the nomenclature.

Simulators : they use native hardware to simulate functionality rather than re-interprit the API.
Emulators : Execute real HW machine code , much like executing ARM code on X86 processor.

Lets look at different options available to developers.

iPhone: Uses a PowerVR GPU supporting OpenGL ES 2.0, 1.1 and OpenVG API, however the iPhone XCode development environment uses an API that is similar to OS X API and thus during development the iPhone presented is more a UI skin which compiles the iOS API into x86 executable. OGLES is a pass through API directly supported by the Discrete NVidia, Intel or AMD CPU. There are plenty of precautions one needs to take while developing using the simulator, note the use of the word simulator rather than emulator. The iPhone cross-compiles only during deployment to the target. Here are some limitations as noted on apple’s developer website.

  • Simulator does not use a tile-based deferred renderer.
  • Simulator does not enforce the memory limitations of the MBX.
  • Simulator does not support the same extensions as either the MBX or the SGX.
  • Simulator does not provide a pixel-accurate match to either the MBX or the SGX.

—————-

Note : PowerVR SGX does not support non power of 2 cube mapped or mipmapped textures. Apple also does not allow pre-compiled shader binary on the iPhone. So hand optimized shaders work best. I hope that Apple does port and provide shader optimization tools for its products.

One can argue if supporting runtime compilation is GLSL is efficient , certainly not but to prevent fragmentation Apple does not support this technique. One can probably decompile iOS binary to get GLSL code and replicate it.

—————–xx————–xx—————

Android : SDK is packaged with an QEMU based ARM emulator, however this emulators does not support complete OGLES 1.1 or 2.0, it supports a primitive version of OGLES 1.0 implemented in software. The NDK or the native development kit does include a simulator developed by AMD/ATI intern passed on to Qualcomm and onto the Android NDK. One cannot explicitly run a OGLES 2.0 program on the Android emulator but can only run it on the device or in some form on the NDK simulator. Google does not publish NDK limitations with respect to OpenGL ES or the simulator limitations.

Once you have a android enabled device either from Nvidia or Qualcomm or a PowerVR based device, their performance instrumentation tools can be obtained from the respective SDKs but in general its a nightmare to develop games on Android devices and be successful in the Android market.

MeeGo : Does have an innovative solution to emulating OGLES in QEMU, they created a wrapper and a pass through solution with a client server architecture and a custom virtual I/O driver. I have not tested or played with this solution but have heard good reviews about the same.

Lets look at other OGLES emulators available from Nvidia, ARM, Imagination and Qualcomm.

All of these above said companies offer OGLES 2.0 simulators for windows XP operating system with a generic pass through to the PC HW graphics engine using desktop OpenGL or a software implementation using MESA DRI under linux. libGLESv2.lib is the recommended naming convention by Khronos. The following diagram is derived from an description represented from Qualcomm’s 80-VN411-1_A_Adreno_Unified_Emulator_UG.pdf . The PDF can be obtained through a simple registration on qdevnet.

  • egl.h and eglplatform.h are standard EGL header files from Khronos
  • gl2.h and gl2ext.h are standard OpenGL ES 2.0 header files from Khronos, supports some standard extensions.
  • gl2extXXX.h gives access to supplimental OpenGL ES 2.0 extensions from IMG, AMD, Nvidia, ARM, Vivante etc
  • Link your application against libEGL.lib and libGLESv2.lib
  • libEGL.dll or libEGL.so is the simulator for EGL 1.3 or 1.4
  • libGLESv2.dll or libGLESv2.so is the simulator for OpenGL ES 2.0
  • on Windows EGL uses the hwnd handle and on Linux uses the X11
  • Khronos is contemplating on a native EGL implementation for the PC world

Hopefully in the coming year both Nvidia and AMD will release OpenGL ES 2.0 support directly on the hardware since next-gen browsers will start supporting WebGL for which OGLES 2.0 is a prerequisite.

—————–xx————–xx—————

Nvidia : Supports OpenGL ES 2.0 on WinXP or Vista , provided that the PC supports one of the following Nvidia graphics processors.

  • Quadro NVS 110M
  • GeForce 8400 series
  • GeForce 8600 GTS
  • Quadro FX 4000 (Quadro and PerfKit drivers)
  • GeForce 6200 TurboCache (no support for Luma-only FBOs)
  • GeForce 6600GT (no support for Luma-only FBOs)
  • GeForceGo 6600 TE (no support for Luma-only FBOs)
  • Quadro NVS 135M (no support for advanced ogles 2 particles on some drivers)

Most other newer GeForce and Quadro GPUs, A complete list can be obtained on Tegra developer website or on Khronos conformant products website. GeForce is the primary choice because the Tegra is based on this GPU , marketed as a ultra low power GPU in reality might be just a heavily clock gated architecture.

Restrictions

  • Binary-precompiled shaders not supported
  • Only fixed-function alpha blending supported
  • Shader limitations should be read from the tables in the Tegra OpenGL ES 2.0 development guide; the wrapper is not guaranteed to return Tegra-correct values
  • Default precision specifiers ignored.
  • Non-power of two textures can support mipmapping and wrapping
  • Does not support ETC or LATC textures
  • Maximum texture size is implementation-dependent
  • Depth buffer formats differ by implementation and may include 24 or 32 bpp depth
  • No support for PBuffers
  • Performance is in no way linked to final Tegra device performance
  • No vector-graphic support
  • No CSAA support – MSAA support may be enabled automatically on some drivers.

These restrictions are stated in NVidia tegra emulator document.

Qualcomm : Supports OpenGL ES 2.0 for their Snapdragon processor. The SDK supplied a nice tool which can be used to configure the emulator and some driver parameters which include CPU cycles , Type of GPU and so on.

Hardware Requirement

  • Recommended hardware is ATI Radeon X1300 or higher.
  • ATI Radeon 9500 is the minimum required hardware.
  • Equivalent hardware from other vendors may work, but it is not tested.
  • Install the latest Catalyst drivers from [R1].
  • This is important, as there have been recent fixes that affect the emulator.

Simulator Restrictions

  • The binary shader support in the emulator requires different binary shaders than real hardware will need. MakeBinaryShader is a command-line utility that generates binary shaders for the emulator, but you will be forced to run your shaders through a similar tool for your target hardware before shipping your game if you choose to use binary shaders.
  • All precision qualifiers in shaders are ignored and the default shader precision for your desktop graphics card is used instead.
  • Full OpenGL ES 2.0 error checking is not supported, but it is pretty close. Shader invariance rules are ignored. Varying packing rules are not followed. Shader constant expressions are not evaluated.
  • Since the emulator is built on top of desktop OpenGL, any bugs in your desktop OpenGL driver will affect the emulator. As of this document’s writing, the FBO implementations in desktop OpenGL drivers are incomplete.
  • Real devices may support only 16-bit or 32-bit display buffers (depending on the display technology chosen and amount of memory available). The emulator supports both. If you wish to test 16-bit displays, set your desktop to 16 bits. If you wish to test 32-bit displays, set your desktop to 32 bits. The emulator follows the EGL specification in regards to EGLconfigs sorting. See [S1] for more details.
  • The max values for Qualcomm’s future GPU are used for constant states like MAX_TEXTURE_SIZE, MAX_VARYING_VECTORS, …
  • MAX_VERTEX_ATTRIBUTES is a special case where 15 is exported instead of 16 like future hardware supports.
  • Vertex texture fetches are not supported.
  • ATI desktop hardware does not support non-power of two textures with a wrap mode other than clamp. These will punt to software and be unbearably slow on the emulator even though the real mobile hardware supports this.

The source is as stated above the emulator user guide for Adreno GPUs. There is also a nice blog post on why Qualcomm does not support binary shaders here and how to optimize shader for games.



Posted in Embedded Graphics.

Tagged with , , , , , , , , , , , , , .


Mobile Graphics Drivers, the need for Open Source

Here are the slides from the talk, the suggestion is very preliminary but very valid in the context of SoC companies, Device integrators and Developers. The IP companies ofcourse would not like it and will throw in things like optimization, security and performance. But if apple can successfully implement such a model , I strongly believe at a community driven project with a driver like Google or Linaro will help see this model work.

Download it here…


Posted in Embedded Graphics.

Tagged with , , , , , , .


FOSS.IN

If you are in India, FOSS.in is the plce to be. Some great talks from speakers around the world. The energy at this place is outstanding. So register @ www.foss.in

http://foss.in/talks/final-list.html

FOSS.IN


Posted in Linux.

Tagged with , , , , , , .


Android HAL and Graphics

Update : Some additional architecture information on Android Graphics. I will also be talking at FOSS.in Dec 15-17 regarding the need for open graphics drivers.

I meant to post this about 3-4 months ago but work as kept me busy, Anyway here it is.

Android offer various benefits for handset manufacturers also a revolution in software architecture bring diverse software stacks together. One important aspect of the entire framework is the HAL or Hardware Abstraction Layer which provides a layer to protect proprietary software from licensing point of view. As an architectural decision, I would consider it a mess a bad one and an un-necessary step. To substantiate these statements need to look at a bit of background on software stacks.

  • RIL ( Radio Interface Layer ) for GSM & CDMA
  • Graphics ( Drivers for OpenGL ES )
  • GPS & Bluetooth baseband drivers


Baseband( GSM Handset Architecture ) paper provides some useful insights.Thisfor GSM chipsets has been developed by a very few providers the major players in this arena being Infineon, Broadcom, TI, Qualcomm, MediaTek, ST-Ericsson. The software is divided between the DSP ( CEVA, x64, StarCore.. ) and typical ARM processor and has never been made open or any details revealed, rather provided as a black-box to handset manufacturers.

Graphics : Although OpenGL ES is an open standard, the drivers are rather very proprietary and it starts from the IP provider who choses to either license source or ported drivers for various operating system. The device manufacturers then integrates these drivers. To date there has been no information on register level access on any graphics core integrated into an SoC. This is also true for larger PC graphics core. Its to note that most peripherals on an embedded application processors have register level access except the graphics core.
[Update] Only recently major device & GPU providers released GPL version of low level drivers for Linux.

Bluetooth & GPS : BlueZ stack is rather open and the BB with all the OSI layers are quite well known among developers. The GPS baseband is however special largely depends on special algorithms but the interface layers have largely remained a standard.

Talking about Android again, the use of linux kernel offers a modular structure for development of drivers. Although the driver structure is standardized there is no model yet for standard technology interfaces like Graphics, GPS etc. Android has taken this a step further by putting in-place a Hardware abstraction layer or ( HAL ). The concept is great that android only uses and requests services or features that will be used by the upper layers but this interface is very crudely defined in their architecture . Graphics especially works through various hacks in several layers or components. before diving into the graphics hacks its worth to look into a working model.

The picture derived from one of Google I/O talks, it does provide a clear view on connections between the Kernel, HAL ( libhxxx.so ) , C++ headers, JNI binding and finally the JAVA API. Consider the complete audio subsystem in Android and in particular the OMAP 35xx applications processor.

Kernel Driver : kernel/sound/soc/omap/omap3beagle.c
Kernel Driver : kernel/sound/codecs/twl4030.c
UserSpace : ALSA Driver / Pulse Audio
HAL : libaudio.so

Does Android really use OpenGL ES API for UI acceleration ?.

Update : Since 2.1 Android does use OGLES 1.0 API to accelerate GUI, in absence of HW it uses a sample OGLES 1.0 SW implementation.

The Answer is NO, not out of box !. Android uses SKIA a SW renderer that offers great performance and portability across ARM processors, it performs remarkably well in presence of the ARM NEON ( SIMD ) processor. The OpenGL SW implementation is half baked and does not offer a full OpenGL ES 1.1 implementation. A real OpenGL ES implementation on hardware is integrated as part of libgl.so and libgl2.so, however these are only used through a thin JAVA API layer for games and as part of the NDK. The bottom line is Google needs to come out with a cleaner interface mechanism and graphics stack that is portable and scalable.


Posted in Android, Embedded Graphics.

Tagged with , , , , , , , .


GPL Kernel GPU drivers, ARM MALI, Qualcomm, PowerVR

There has been a recent wave of releasing kernel drivers for embedded GPUs. Its important to understand the tiered driver structure of the software stack. The kernel level drivers mostly setup registers, allocate memory, some basic low level memory management and maintain a bus abstraction layer, maybe also provide some basic performance metrics or debug. Most of the hidden magic happens in the user space where the OpenGLES libraries reside. This is very proprietary software since GPU registers functions are a hidden secret atleast to the end developers. The userspace drivers provide access to OGLES 1.1 or 2.0 API . The efficiency and footprint largely form a key component in the selection process of an embedded GPU. For example if the GPU is to be integrated in either a automotive or avionics application you would want the driver to be very fast and of a smaller footprint., You don’t want to wait for your dashboard to boot up slowly after turning on the ignition. In the mobile space its a question of performance and debug metrics, the programmable pipeline especially a multicore design can throw up a lot of questions on scheduling and bottlenecks.

Here is a list of references to the open source kernel drivers. A first step in freeing up the deployment and build of drivers to various kernel releases and the possibility to further integrate into the Android structure.

Qualcomm : Snapdragon with AMD’s IMAGEON 3D OGLES 2.0 GPU http://goo.gl/tXCK
ARM MALI 200 : OGLES 2.0 http://goo.gl/rLEd
ARM MALI 400 : OGLES 2.0 MP http://goo.gl/qvCI
PowerVR SGX535: OGLES 2.0 http://goo.gl/EYWl


Posted in Embedded Graphics, Linux.

Tagged with , , , , , , , .


Some new icons from WWDC10: innovation in every step

Some great new icons designed just for WWDC presentations. Love the concept and the colors. If any of you need it just email me.


Posted in Embedded Graphics, General, MAC OS X, iPhone.

Tagged with , , , , , , , , , .


Fragmented Graphics stack in Android

Initial releases ( 1.1 ) of android was based on a incomplete software implementation of OpenGL ES 1.0 and partially on Skia ( 2D graphics lib ). The next release Donut ( 1.5 ) supported OpenGL ES 1.1 on hardware and certain extensions but the software implementation was only partially extended with major improvements only to skia rendering library. The lastest release android Eclair brought OpenGL ES 2.0 to the picture with support for various screen sizes which also meant changes to EGL.

OpenGL ES 1.0 : Android 1.1, 1.5, 1.6
OpenGL ES 1.1 : Android 1.5, 1.6, 2.0, 2.1
OpenGL ES 2.0 : Android 2.0, 2.1

As per the below data a combined ( 1.5 / 1.6 ) version occupy about 60% of the Android device space and the rest are the 2.1 based devices. The favorable part is the older or first generation devices only use Qualcomm chipset with integrated ATI GPU, becomes fragmented due to the use of different chipsets like OMAP 3 with PowerVR or Samsung also with PowerVR . The problem is not the API compatibility but support for extensions and texture compression, particularly the incompatibility between ATITC & PVRTC and some of the drawbacks of using ETC1 ( An Ericsson contribution ).

The Android NDK used for easy portability of games supports an emulator developed by ATI / Qualcomm. So for game developers just developing on the emulator only solves half the problem it becomes a dire necessity to have a couple of different Android devices with different chipsets to completely test games, their performance and provide a compelling user experience that is consistent. Extensions and texture compression is not much of a issue for application written in Java since Android provides a number of inherent functions and mechanisms to adapt the native UI to different screens and rendering layers. The fragmentation becomes a bigger issue for game developers.

Android 2.1 ( ATI Imageon )
Android 2.1 ( PowerVR )
GL_AMD_compressed_3DC_texture
GL_AMD_compressed_ATC_texture
GL_ARB_texture_env_combine
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_vertex_buffer_object
GL_ATI_compressed_texture_atitc
GL_ATI_texture_compression_atitc
GL_EXT_blend_equation_separate
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_stencil_wrap
GL_OES_EGL_image
GL_OES_blend_equation_separate
GL_OES_blend_func_separate
GL_OES_blend_subtract
GL_OES_compressed_ETC1_RGB8_texture
GL_OES_compressed_paletted_texture

GL_OES_draw_texture
GL_OES_extended_matrix_palette
GL_OES_framebuffer_object
GL_OES_matrix_palette
GL_OES_point_size_array
GL_OES_point_sprite
GL_OES_read_format
GL_OES_stencil_wrap
GL_OES_texture_cube_map
GL_OES_texture_env_crossbar
GL_OES_texture_mirrored_repeat
GL_ALIASED_POINT_SIZE_RANGE: 1, 128
GL_SMOOTH_POINT_SIZE_RANGE: 1, 128
GL_OES_byte_coordinates
GL_OES_fixed_point
GL_OES_single_precision
GL_OES_matrix_get
GL_OES_read_format
GL_OES_compressed_paletted_texture
GL_OES_point_sprite
GL_OES_point_size_array
GL_OES_matrix_palette
GL_OES_draw_texture
GL_OES_query_matrix
GL_OES_texture_env_crossbar
GL_OES_texture_mirrored_repeat
GL_OES_texture_cube_map
GL_OES_blend_subtract
GL_OES_blend_func_separate
GL_OES_blend_equation_separate
GL_OES_stencil_wrap
GL_OES_extended_matrix_palette
GL_OES_framebuffer_object
GL_OES_rgb8_rgba8
GL_OES_depth24
GL_OES_stencil8
GL_OES_compressed_ETC1_RGB8_texture
GL_OES_mapbuffer
GL_OES_EGL_image
GL_EXT_multi_draw_arrays
GL_OES_required_internalformat
GL_IMG_read_format
GL_IMG_texture_compression_pvrtc
GL_IMG_texture_format_BGRA8888
GL_EXT_texture_format_BGRA8888
GL_IMG_texture_stream
GL_IMG_vertex_program
GL_ALIASED_POINT_SIZE_RANGE: 1, 32
GL_SMOOTH_POINT_SIZE_RANGE: 1, 1

Source : OpenGL ES Extensions on different Android Devices


Posted in Android, Embedded Graphics.

Tagged with , , , , , , , .