During the past few weeks/months we have been seeing a lot of news about the future HW of different vendors. Qualcomm has been pushing out news about their 1.5GHz dual-core Snapdragon (ARM cortex-A8 based, Qualcomm modified), Samsung about their Orion a 1GHz dual-core ARM Cortex A9 and Marvell its tri-core Armada 628 (once again ARM based, ARM v7 cores) which can have the main two cores running up to 1.5GHz and the third at 624 MHz. Quite impressive, right?
Lets first think about the figures that the different vendors are providing. What do we do with all of that power? at least form my point of a view this is an excellent questions.
Take for ex the first generation iPhone - ARM11 downclocked to run at 412Mhz, PowerVR MBX light (optimized for low power consumption instead of speed), 128MB of RAM. Still with these figures in the paper even the first iPhones can still beat many of the devices in the markets today. And bare in mind that iPhone 2G was announced already at at the beginning of 2007.
Why is that? Well the SW and especially the framework has been build in a respect of the underlaying HW. And because of the fact that Apple was ready to make compromises with the device - no multitasking which makes things a lot simpler (limited support existing nowadays), simple set of features which really work, extremely simple and limited set of widgets without theming or the 480x320 pixel resolution combined with a color depth of 18 bits (helping a lot with memory bandwidth usage [1]) - focusing on simplicity and usability.
And its not only about the framework from the SW side that matters - badly implemented drivers, SW which is not making the use of the architecture and features a chip offers (separate cores for video, image processing, blitting, etc.). This will effect to the overall performance.
The other thing with these nice MHz figures is the battery consumption. My self I would at least like to get my hands on one touch screen based device which would really last longer than my working day. Of course this is also how the power management of the device is done, which comes once again to well designed and implemented SW...
Instead of getting the MHz's up, how about as an ultimate goal to get the CPU to run as slow as possible and really shifting the operations to GPU. The GPU's can in many cases achieve far better efficiency than the CPU. This would of course still require something from the SW - framework build in such away that it can really utilize the GPU and not just making it to do some fancy effects when switching between applications.
[1] 320x480pixels, 18 bits for a pixel and rendering that 60 times per sec vs. that a frame would hold 800 x 480 pixels (as the Nexus has).
Showing posts with label performance. Show all posts
Showing posts with label performance. Show all posts
Sunday, 17 October 2010
Sunday, 5 September 2010
UI done right
I have always been a fan of what the guys at TAT are doing. These guys have really understood the whole thing of making great looking UI's in away that it is respecting the underlaying HW and taking every last bit out of it.
Their latest creation Velvet is just that - innovative, simple, great looking UI. Nice job!
PS. Would be nice to understand how these guys are working. You have your UI designer, framework developer and lower level graphics guy all working seamlessly together...
Their latest creation Velvet is just that - innovative, simple, great looking UI. Nice job!
PS. Would be nice to understand how these guys are working. You have your UI designer, framework developer and lower level graphics guy all working seamlessly together...
Monday, 15 February 2010
Challenges in 2D acceleration - how about the future?
To achieve great 2D graphics performance from Linux Graphics stack has most definitely been an challenge for years. Trying to get the XRender extension more usable with XAA/EXA/UXA (see my previous blog post), utilising all-software image backends, utilise GL directly to accelerate the 2D and so on. The best solution really has been the CPU rasterization backend based on the fact that the CPU simply runs with higher clock speed and quite many of these 2D operations require raw processing power.
So are we stuck just to continue the everlasting optimisation of the existing solutions? Maybe not.
Now it seems that this there might be some light in the tunnel. Cairo has been getting some quite impressive performance figures with its cairo-drm backend. Instead of using XServer to do the rendering or build an abstraction of XRender with GL backend (what glitz was doing) it has the capabilities to use directly the GEM buffers and issues the rendering commands directly to HW. This will allow direct access to GPU and will give quite impressive performance figures.
The thing is still that cairo-drm is an experimental backend and that the backend is limited to Intel HW (i915 to be specific).
With the performance figures - what the cairo-drm can really do, the goal for the guys is now to get this same performance out from the GL interface directly. This would 1st of all remove the limitations mentioned above and 2nd, it would also allow all the rendering to happen under one driver - OpenGL. This of course would mean that there would be only one graphics stack to tune and maintain and would allow CPU to do other stuff. The cairo-gl project aims to do exactly this.
The cairo-gl backend would also make the solution usable with other than Intel specific HW. The questions of course is that how well the solution performs in non-Intel HW.
Time will show how the cairo-gl backend will perform and whether it is capable to beat CPU rasterization backends.
More info about the progress from:
1. http://anholt.livejournal.com/
2. http://ickle.wordpress.com/
So are we stuck just to continue the everlasting optimisation of the existing solutions? Maybe not.
Now it seems that this there might be some light in the tunnel. Cairo has been getting some quite impressive performance figures with its cairo-drm backend. Instead of using XServer to do the rendering or build an abstraction of XRender with GL backend (what glitz was doing) it has the capabilities to use directly the GEM buffers and issues the rendering commands directly to HW. This will allow direct access to GPU and will give quite impressive performance figures.
The thing is still that cairo-drm is an experimental backend and that the backend is limited to Intel HW (i915 to be specific).
With the performance figures - what the cairo-drm can really do, the goal for the guys is now to get this same performance out from the GL interface directly. This would 1st of all remove the limitations mentioned above and 2nd, it would also allow all the rendering to happen under one driver - OpenGL. This of course would mean that there would be only one graphics stack to tune and maintain and would allow CPU to do other stuff. The cairo-gl project aims to do exactly this.
The cairo-gl backend would also make the solution usable with other than Intel specific HW. The questions of course is that how well the solution performs in non-Intel HW.
Time will show how the cairo-gl backend will perform and whether it is capable to beat CPU rasterization backends.
More info about the progress from:
1. http://anholt.livejournal.com/
2. http://ickle.wordpress.com/
Saturday, 23 January 2010
N900/Maemo5 and different texture formats
Garage.maemo.org is providing an nice tool for benchmarking the different texture formats that the meamo5, SGX based device supports. The tool GLMemPerf is meant for measuring the texture memory bandwidth performance of an OpenGL ES 2.0 implementation with a set of different kinds of precompressed textures. As an output it blit the different textures from its /data folder to the screen and provides an nice set of information - how the different formats and texture processing methods effect to the overall performance.
From the results the compressed textures formats (IMG specific PVRTC and ETC1) are clearly giving an performance benefit - as one could expect. The IMG PVR Texture Compression format has the 2-bits-per-pixel and 4-bits-per-pixel options create PVRTC data that encodes source pixels into 2 or 4 bits per pixel. This meaning that each texel is encoded into fewer bits than the equivalent uncompressed texture, which of course is meaning less load for memory bandwidth.
The downside with the compression is that the overall quality of the render will suffer. The quality hit is still depending from the compressed content so might be worth of checking how 2 vs 4 bits per pixel will effect.
The other thing to note is how the textures are stored and accessed from the memory.
SGX as many other GPUs benefit greatly from the usage of using power-of-two sized textures - which improves the implementation of the texture mapping when converting the texture coordinates to texel coordinates. It might be worth of rounding up the textures to the nearest power-of-two to get the benefit. Note also that the PVRTC formats require that the textures are in power-of-two size.
The other thing related accessing the memory is the texture twiddling. The twiddling is by default done for all the SGX uploaded textures. What the twiddling does is that it re-arranges the texture samples to optimize the memory access for different operations. One thing to note is that with pixmaps you will not get this benefit as in a case of pixmaps you don't upload the textures to the video memory but instead source the pixels directly.
How about generating and processing your textures? For this IMGTec is providing an nice tool called PVRTexTool. The tool has an version for command line usage and also an GUI based tool for seeing in more detailed the output of your changes - for ex when wanting to do comparison between the different compression methods. The PVRTexTool supports your normal RGB/ARGB formats + the texture compression format PVRTC and ETC.
From the results the compressed textures formats (IMG specific PVRTC and ETC1) are clearly giving an performance benefit - as one could expect. The IMG PVR Texture Compression format has the 2-bits-per-pixel and 4-bits-per-pixel options create PVRTC data that encodes source pixels into 2 or 4 bits per pixel. This meaning that each texel is encoded into fewer bits than the equivalent uncompressed texture, which of course is meaning less load for memory bandwidth.
The downside with the compression is that the overall quality of the render will suffer. The quality hit is still depending from the compressed content so might be worth of checking how 2 vs 4 bits per pixel will effect.
The other thing to note is how the textures are stored and accessed from the memory.
SGX as many other GPUs benefit greatly from the usage of using power-of-two sized textures - which improves the implementation of the texture mapping when converting the texture coordinates to texel coordinates. It might be worth of rounding up the textures to the nearest power-of-two to get the benefit. Note also that the PVRTC formats require that the textures are in power-of-two size.
The other thing related accessing the memory is the texture twiddling. The twiddling is by default done for all the SGX uploaded textures. What the twiddling does is that it re-arranges the texture samples to optimize the memory access for different operations. One thing to note is that with pixmaps you will not get this benefit as in a case of pixmaps you don't upload the textures to the video memory but instead source the pixels directly.
How about generating and processing your textures? For this IMGTec is providing an nice tool called PVRTexTool. The tool has an version for command line usage and also an GUI based tool for seeing in more detailed the output of your changes - for ex when wanting to do comparison between the different compression methods. The PVRTexTool supports your normal RGB/ARGB formats + the texture compression format PVRTC and ETC.
Subscribe to:
Posts (Atom)