Intel® Software Network

We are glad to announce the release of the Intel Laptop Gaming TDK (Technology Development Kit) v1.0. This is a free software intended to providing game developers with a one-stop place for accessing platform information to better tune their games for the laptop platforms.

This discussion thread in the mobilized software forum has been created to enable constructive discussions on the Laptop Gaming TDK, foster ideas that can enhance gaming on laptops and provide an informal support structure for the TDK users.

Pretty neat.

From what is presented in the TDK, here is what I find compelling (and likely to implement in our game):

1. Display current battery life.
2. Display network signal strength.
3. Support for multiple processors.

Although I see the benefit of scaling usage based on the power source, that would require an architecture change expensive enough that it doesn't feel worthwhile. Even games which provide customization of the rendering quality will typically try to render at full speed - they usually aren't designed with run-time throttling in mind.

--------

There are several changes to your sample application that could be made to more accurately demonstrate what you are advocating.

1. Display frame rate for the sample.
2. Cap frame rate at 30fps if you detect that the power source is a battery.

3. Even though the physics in the sample is run in a separate thread, there is no asynchronous operation. There are three alternate implementations that you could provide which would truly support multiple processors:

Easiest (but worst) - Utilize 2 threads for physics rather than 1. Split the number of spheres to update between the two threads. This will allow each CPU to process a portion of the physics asynchronously. Although this would not translate well to a practical implementation for a game (since most objects need to interact with other objects in the scene during collision response), it would at least demonstrate an increase in frame rate for machines with multiple processors.

Better - Reverse the order of operations between render and physics. This will allow the physics code to execute while the graphics device processes queued calls to draw (which will eventually block the UI thread on Present). This translates well into an easy to implement optimization for most games, but will probably not affect the frame rate much for your sample, since your vertex shader is not very expensive to execute. Also, this doesn't exactly demonstrate support for multiple cpu's, it just shows asynchronous operation between the gpu and the cpu.

Best - Maintain two sets of position data for the spheres. At the beginning of each frame copy from the "Live" set to the "Render" set. Execute both Physics thread and Render at the same time, only blocking prior to end of the frame to wait for both to finish. This would demonstrate true multi-processor usage.

Side note: The UI controls & text on the right are rendering partially offscreen, and the application crashes when I toggle the check box at the bottom.

-Isaac Squires
http://www.SiderealFury.com/

Hi Isaac

Thanks for your detailed feedback. We greatly value such constructive feedback as it will help improve our product offering.

We appreciate your feedback on the sample application and I will make sure any issues that you have reported are fixed for our next release. The suggestion for capping frame rate is a great one that I will add to the application. Regarding the processing of physics on two separate threads based on splitting the number of spheres between the threads, while the data is decomposed, the functional decomposition is difficult. since we expect that these spheres are going to be colliding against each other, we will actually create more interdependencies between the 2 threads. One thing that we can consider doing is split the spheres based on which quadrant they are in and allocate each of the quadrants to a thread, thereby reducing the dependency when it comes to collision.

While we can definitely optimize the sample application for multi-core capability, the intention in this application is more to indicate the potential of platform feedback in the app. In this regard, the first and simplest step was to create these "meters" to show the various platform states on the HUD. But the impact of the platform awareness will show better if the game can use these to change states. In the past, game developers designed games to support the variant capabilities of graphics cards (hi-fidelity to low-end graphics). In the future, I expect game developers to design and develop their games for variant platforms. For example, a game that runs well on a desktop might not run as well on a laptop and might be even worse on a UMPC (ultra mobile PC) or on a cellphone, due to various reasons - form factor, power constraints, aspect ratio, graphics capabilities etc. Today, games are designed specifically for a particular type of platform. In future, this probably will not be the case. The expectation would be for the game to scale seamlessly between platforms. The games that can do this well, will be the ones that probably will lead the market for such usage.

If you have any other usage models for such use of platform information, do share with us and we will try to provide infrastructure for such capabilities in our software.

Thanks and happy gaming!!

Satheesh

Disclaimer: All opinions expressed in this post are those of the author and not a representation of Intel's views on this topic.

Between design changes in our project, and discussion during today's live TDK chat, I am interested learning more about methods to monitor and control power consumption.  Our game is being designed to run for long periods of time (existing in the background while the user performs other tasks), so it would be beneficial to throttle operations even when the user is not running on battery power.  Is there a resource available which will enumerate common hardware which add to CPU / Power overhead, as well as mechanisms to control their activity?

I'm also thinking about some creative ways to handle wireless connectivity loss.

Thank you for hosting today's chat, I found it helpful.

-Isaac Squires
http://www.SiderealFury.com/

Thank you to all the participants in the online chat on the 19th.  Excellent questions and suggestions for creative uses of the TDK. The transcript has been posted.  Take a look and let us know what you think. 

http://www3.intel.com/cd/ids/developer/asmo-na/eng/325879.htm

Nice API. Pity it only support M$. Any plans to port the TDK to linux?
thx,
bob

Hi Bob

We currently do not have plans to extend it to Linux. Having said that, I don't see any reason why it cannot be extended to linux. Will add this to the list of TODOs for the TDK and follow-up with you if and when we plan to implement the linux version.

Thanks for your comment.

Satheesh

Porting the TDK to linux may or may not support Intel chips, but porting the TDK to the Mac absolutely targets an Intel only platform. It seems to me that would be in Intel's benefit. Please consider supporting the Mac platform as many people would rather play games on the Mac OS X instead of Windows, if only there were more games. You can help with this. Respectfully, Douglas W. Goodall

With regard to porting, we recently spoke to one of our other contacts for the TDK, who agreed that the Laptop Gaming TDK can be ported to Linux* with minimal effort. They said porting to MacOS* is likely also not a problem since most of the APIs used are generic, and any Windows*-specific APIs should have an equivalent in MacOS. A Java*-based API should also work.

==

Lexi S.

Intel(R) Software Network Support

http://www.intel.com/software

Contact us