WinCE-TIBSP 3D Graphics
- 1 Introduction
- 2 3D Graphics Framework in Windows CE
- 3 Using the SDK
- 4 Silverlight
- 5 Troubleshooting
- 6 Performance Benchmarking
Some of the TI application processors include a built-in PowerVR SGX Core that provides advanced hardware accelerated support for OpenGL ES and OpenVG graphics decoding. This section describes how to enable the 3D graphics framework to take advantage of this capability under Windows CE.
3D Graphics Framework in Windows CE
Once you install the released graphics package (for e.g., wince_gfx_sgx_xx_yy_xx_setup.exe where xx.yy.zz stands for release version) in the default directory it will contain a Documents directory with the manifest and a copy of the EULA, the DDK which provides the support for the SGX inside WinCE and the SDK that contains the infrastructure to build an application. The DDK is inside the PowerVR directory and it needs to be copied under the PUBLIC directory in the WinCE root (e.g. C:\WINCE600\PUBLIC or C:\WINCE700\public as appropriate). This folder contains the necessary Catalog entries, the associated libraries and kernel modules needed to support PowerVR in WinCE. The SDK which is in the PowerVR-SDK directory can be installed anywhere that is convenient, and along the support libraries and headers it contains useful tools for development, Demos and Tutorials for the different technologies, some of which are described below.
Building an Image that support graphics
The default OSDesigns provided for each particular platform enables by default the use of the PowerVR libraries. To verify that the PowerVR libraries are included in an image, the following elements should be checked in the Catalog:
- The SYSGEN flag for PowerVR is enabled, under ThirdParty (PowerVR check mark)
- The correct core revision is enabled.
- SGX Core Revision 121. For SoCs that have Rev-121 of SGX530 Core (e.g., AM3517, OMAP3530).
- SGX Core Revision 125. For SoCs that have Rev-125 of SGX530 Core (e.g., DM3730, AM3715, AM387x, AM335x).
(Note: There are variants of the above devices that do not have the SGX core and hence don't have hardware accelerated graphics capability. Please double check the device data sheet to make sure that the device you are using has the SGX530 core.)
- WINCE_GFX_SGX release 2.xx.xx (for WEC7)
- The correct Rev of the SGX core needs to be enabled based on the SoC in use. If both entries are enabled PowerVR may not function correctly.
- WINCE_GFX_SGX release 1.xx.xx (for WinCE6)
- If both entries are checked, the image will automatically detect which core is used and it will use the appropriate libraries. This is useful for development, with the caveat of a larger image size and an small extra time taken at boot-up time when the appropriate libraries are identified and copied to the destination directory.
Using the SDK
Using the Demos
The easiest way to validate and observe some of the capabilities of the Graphics subsystem is by the use of the included Demos in the SDK. The binaries for WinCE of these demos are included in the OGLES1.1. and OGLES2 Binaries directories. These can be run either by including them in the binary image (NK.bin), by running them from a device (i.e. SD card) or by executing them remotely via KITL. The pre-built demos will show the FPS performance in the console (or KITL) for each application and will run freely without been bound to the VSYNC. Please refer to the available options from the User Guide in the SDK.
Running demos for AM335x, AM387x
AM335x and AM387x display driver are configured by default to run 24bit color (ARGB32 mode). The PowerVR demos by default are configured for 16bit color. So when you just run the executable as is (by double clicking on the demo icon or running it from a command line without specifying more options) the demos run in BLT mode due to the need for conversion from 16bit color to 24bit color. This affects performance. To see the best (raw) performance use the -cbpp=32 option on the cmd line (this will use frame flipping for full screen application). For e.g., when running from SD card use the following command line (assuming that the executable is in the SD card root directory).
The above demo showcases raw performance but may not appear smooth (or may show some artifacts) because more frames are being generated than can be displayed (buffers getting overwritten with new frames while they are being displayed). To get smooth playback use the -vsync=1 option which will synchronize new frame generation with hardware VSYNC.
\Storage_Card\OGLESVase.exe -cbpp=32 -vsync=1
Note: For AM387x, hardware VSYNC is not enabled and the VSYNC is emulated using a timer.
Running demos for OMAP35x, DM37x, AM35x
OMAP35x, DM37x, AM35x display drivers are configured by default to run 16bit color mode. And since the PowerVR demos by default are configured for 16bit color, running the demos (by double clicking on the demo icon or running it from a command line without specifying more options) showcases the best raw performance (due to frame flipping for full screen application as opposed to BLTs). For e.g., when running from SD card use the following command line (assuming that the executable is in the SD card root directory).
The above demo showcases raw performance but may not appear smooth (or may show some artifacts) because more frames are being generated than can be displayed (buffers may get overwritten with new frames while they are being displayed). To get smooth playback use the -vsync=1 option which will synchronize new frame generation with hardware VSYNC.
Rebuilding the Demos
The simplest way to rebuild one of the demos (or all of them) is by using a command Window from Visual Studio. To do this, the following steps must be completed:
- The "Open Release Directory in Build Window" should be selected from the Build Menu in Visual Studio. This command window will contain all the flags that are associated with the current project/OSDesign.
- Point to appropriate directory that contains the demo that need to be built, or the Demos directory inside OGLES1.1 or OGLES2.0 directory.
- The environment variable SDKROOT must be defined to the point of where the OGLES directory is, i.e.
- Build the application(s) by using the "build" command from the command prompt or "build -c" to clean and rebuild.
The SDK contains a step-by-step tutorial, which is referenced in the User Guide of each API set (OGLES1.1., OGLES2 or OVG). These are under the TrainingCourse directory, and contain a text file explaining briefly what is achieved in each step of the tutorial. To rebuild any of the Tutorial sections, the same steps explained for the demos can be used accordingly.
Imagination provides an abstraction layer for the OS in the form of the PVRShell. All the demos and some of the tutorials take advantage of the Shell to create some independence of the OS for portability. The sources of the Shell are available and are recompiled with each one of the Demos.
Tools & Utilities
Additional tools are provided as part of the SDK (i.e. PVRGeoPOD: Plugin for 3D Studio MAX and Maya). These are described inside the User Guides present in the SDK.
Starting with WinCE6R3, Microsoft introduced Silverlightin WinCE. Fundamentally Silverlight is a development platform that allows users to create graphic rich applications; however these can be resource consuming. Microsoft provides a plugin that will redirect most of the graphic operations that in turn will be accelerated (and offloaded of the host proccessor) when using the SGX. To enable the plugin (which is enabled in the OSDesign by default) the environment variable BSP_XRPLUGIN_OPENGL needs to be set.
WINCE_GFX_SGX release 2.xx.xx (for WEC7)
- No sample Silverlight applications are included in the BSP release. But instructions on how to run Silverlight demos that were part of WinCE6 R3 release on a WinCE7 system is given here
WINCE_GFX_SGX release 1.xx.xx (for WinCE6)
- A set of sample applications for Silverlight were provided as part of the WinCE6 R3 release; the current OSDesign includes these demos embedded in the image and available from the desktop. The demos wrapper was modified by TI to enable and use the rotation so a full VGA screen can be used. Obviously the PowerVR module (or the plugin) needs to be disabled to truly compare the behavior of these demos.
This trouble shooting section contains all the steps in case that the application doesn't start at all, or that Silverlight applications seem to be consuming all the resources in the CPU or whenever an issue is seen while running the PowerVR.
Core Revision Value
The initial step is to verify that the right flags for the appropriate SGX Core Revision were selected in the catalog according to the previous section. If KITL is enabled, messages related to the PowerVR could give hint on what is wrong (e.g. Incorrect hardware selected).
The easiest way to verify that the PowerVR modules are correctly installed is by executing any of demo applications that are provided with the BSP or included in the SDK. In case the application doesn't work, the first step is to verify that the modules are correctly installed, for that the added application eglinfo will show all the associated configurations and enabled attributes:
- Open a command window. In WinCE, the cmd program can be execute from the Run entry in the Start menu.
- Change to the windows directory: "cd windows"
- Execute eglinfo.
Of particular interest for reference purposes and to facilitate support is the EGL version string which should contain the particular version number for the DDK.
In most cases that an issue appears when using the PowerVR module, the first step is to capture logs that could lead to figure out what the problem might be. In the retail version of the modules, all these messages are disabled by default; therefore the firs step is to use the debug modules of PowerVR, either by building a Full debug image or by using the PowerVR debug libraries; for the latter scenario:
- Create a backup copy of the PowerVR directory that is created in PUBLIC.
- Copy the debug libraries from the target directory in oak to the retail directory. Please note that in this case the ddi_powevrlib can't be copied (and the debug information can't be used) unless the debug libraries for the Display driver are used as well.
- Rebuild your solution.
Some comparative benchmarks for WinCE and Graphics is presented here, in which several demo applications are run in different platforms.