Intel Software Network articles Feed http://software.intel.com/en-us/articles/visual-computing/type/code/ en-us River Trail: Parallel Web Applications

In a world where the web browser is the user's window into computing, browser applications must leverage all available computing resources to provide the best possible user experience. Today web applications do not take full advantage of parallel client hardware due to the lack of appropriate programming models.

ParallelJS technology (code named River Trail) puts the parallel compute power of client's hardware into the hands of the web developer while staying within the safe and secure boundaries of the familiar JavaScript programming paradigm.

River Trail gently extends JavaScript with simple deterministic data-parallel constructs that are translated at runtime into a low-level hardware abstraction layer. By leveraging multiple CPU cores and vector instructions, River Trail achieves significant, up to an order of magnitude speedup over sequential JavaScript.


 
]]> http://software.intel.com/en-us/articles/river-trail-parallel-web-applications/ Thu, 06 Oct 2011 00:00:00 -0700 http://software.intel.com/en-us/articles/river-trail-parallel-web-applications/#comments http://software.intel.com/en-us/articles/river-trail-parallel-web-applications/ Parallel Programming Visual Computing Code & Downloads Spark: Modular, Composable Shaders for Graphics Hardware

Spark: Modular, Composable Shaders for Graphics Hardware

By Tim Foley (Intel Corporation and Stanford University), Pat Hanrahan (Stanford University)

In creating complex real-time shaders, programmers should be able to decompose code into independent, localized modules of their choosing. Current real-time shading languages, however, enforce a fixed decomposition into per-pipeline-stage procedures. Program concerns at other scales - including those that cross-cut multiple pipeline stages - cannot be expressed as reusable modules.

We present a shading language, Spark, and its implementation for modern graphics hardware that improves support for separation of concerns into modules. A Spark shader class can encapsulate code that maps to more than one pipeline stage, and can be extended and composed using object-oriented inheritance. In our tests, shaders written in Spark achieve performance within 2% of HLSL.


Read the Siggraph paper: Spark: Modular, Composable Shaders for Graphics Hardware [PDF 3.1 MB]

Download the source code: spark-0.1.zip* [ZIP 36.3 MB];

Presented at: ACM SIGGRAPH 2011, Vancouver, B.C. Canada

 

Spark: Modular, Composable Shaders for Graphics Hardware. Tim Foley, Pat Hanrahan. In ACM Transactions on  Graphics (SIGGRRAPH 2011 Proceedings). Volume 30, Issue 4, Article 107. 2011.

*This software is subject to the U.S. Export Administration Regulations and other U.S. law, and may not be exported or re-exported to certain countries (Burma, Cuba, Iran, North Korea, Sudan, and Syria) or to persons or entities prohibited from receiving U.S. exports (including Denied Parties, Specially Designated Nationals, and entities on the Bureau of Export Administration Entity List or involved with missile technology or nuclear, chemical or biological weapons).

 
08-07-2011
08-07-2011
Tech Articles
Research
In creating complex real-time shaders, programmers should be able to decompose code into independent, localized modules of their choosing. Current real-time shading languages, however, enforce a fixed decomposition into per-pipeline-stage procedures. Program concerns at other scales - including those that cross-cut multiple pipeline stages - cannot be expressed as reusable modules. We present a shading language, Spark, and its implementation for modern graphics hardware that improves support for separation of concerns into modules.
]]> http://software.intel.com/en-us/articles/spark-modular-composable-shaders-for-graphics-hardware/ Sat, 30 Jul 2011 00:00:00 -0700 http://software.intel.com/en-us/articles/spark-modular-composable-shaders-for-graphics-hardware/#comments http://software.intel.com/en-us/articles/spark-modular-composable-shaders-for-graphics-hardware/ Visual Computing Dynamic Resolution Rendering

Dynamic Resolution Rendering

The Dynamic Resolution Rendering sample demonstrates a technique for dynamically adjusting the resolution of the main rendering, with graphical user interface components drawn at the native resolution. This technique can help developers achieve their quality and performance goals on a wide range of hardware and scene profiles. The sample also shows how the addition of scaling filters such as velocity aware temporal spatial anti-aliasing can enhance quality.


Video: Dynamic Rendering Resolution Walkthough Video
(click link to view larger)


Read: Dynamic Resolution Rendering
Blog Post: Dynamic Resolution Rendering Sample Now Live - Blog post by Doug Binks
DynamicResolutionRendering_ScreenShot01_thumb.jpg
DynamicResolutionRendering_ScreenShot02_thumb.jpg

A view of the swinging bell with supersampling enabled and dynamic resolution control set to give 30FPS. The geometric temporal anti-aliasing uses velocity aware filtering to reduce ghosting artefacts.

With dynamic resolution parts of the scene with higher performance can have increased resolutions, yet match the chosen performance criteria. Geometric temporal anti-aliasing gives additional smoothness to the edges.

An illustration of the basic principle of dynamic resolution.


System Requirements Additional Code Samples
  1. CPU: Intel® 2nd Generation Core i3 or better
  2. GFX: uses DX11 graphics API on DX10 (or better) hardware
  3. OS: Microsoft Vista / Windows 7*
  4. MEM: 2 GB of RAM or better
  5. Software:
    1. DirectX SDK (June 2010 release or later)
    2. Build with Microsoft Visual Studio 2010* or Microsoft Visual Studio 2008*

* Other names and brands may be claimed as the property of others.


Intel Visual Adrenaline
Developer Community
Intel® Software Partner Program
Game On
Showcase


]]> http://software.intel.com/en-us/articles/dynamic-resolution-rendering/ Thu, 31 Mar 2011 00:00:00 -0700 http://software.intel.com/en-us/articles/dynamic-resolution-rendering/#comments http://software.intel.com/en-us/articles/dynamic-resolution-rendering/ Visual Computing Code & Downloads Game Development Morphological Antialiasing (MLAA)

Morphological Antialiasing

MLAA is an image-based, post-process filtering technique which identifies discontinuity patterns and blends colors in the neighborhood of these patterns to perform effective anti-aliasing. It is the precursor of a new generation of real-time antialiasing techniques that rival MSAA. This sample is based on the original, CPU-based MLAA implementation provided by Reshetov in 2009, with improvements to greatly increase performance. The improvements are:

o Integration of a new, efficient, easy-to-use tasking system implemented on top of Intel® Threading Building Blocks (Intel® TBB).
o Integration of a new, efficient, easy to use pipelining system for CPU onloading of graphics tasks.
o Improvement of data access patterns through a new transposing pass.
o Increased use of Intel® SSE instructions to optimize discontinuities detection and color blending.


Video: CPU Based MLAA Implemention - Developer Walkthrough from Alexandre De Pereyra (click to view larger)


Read: MLAA: Efficiently Moving Antialiasing from the GPU to the CPU by Alexandre De Pereyra

Blog Post: CPU Morphological Antialiasing (MLAA) sample now live! - Blog post by Josh Doss
MLAA_Found_Edges_thumb.jpg
MLAA_MLAA_ZB_thumb.jpg

Viewing the found edges can be helpful when debugging MLAA.

The MLAA sample contains a zoom box to compare different anti-aliasing techniques.


System Requirements Additional Code Samples
  1. CPU: 2nd Generation Core i5 or better suggested
  2. GFX: DX10 capable graphics card
  3. OS: Microsoft Windows Vista* or Microsoft Windows 7*
  4. MEM: 2 GB of RAM or better
  5. Software:
    o DirectX SDK (June 2010 release or later)
    o Build with Microsoft Visual Studio 2008* w/SP1 or Visual Studio 2010*

* Other names and brands may be claimed as the property of others.



Intel Visual Adrenaline
Developer Community
Intel® Software Partner Program
Game On
Showcase


]]> http://software.intel.com/en-us/articles/mlaa/ Wed, 30 Mar 2011 00:00:00 -0700 http://software.intel.com/en-us/articles/mlaa/#comments http://software.intel.com/en-us/articles/mlaa/ Visual Computing Code & Downloads Game Development Game Engine Tasking Animation

Game Engine Tasking - Animation

Desktop gaming systems with 6 cores and 12 hardware threads have been on the market for some time now and 4 core CPUs are becoming increasingly common even on laptops. To give your customers the best experience on their particular platform we want to write game engine code that is core count independent. Tasking allows programs to benefit from scaling as core counts are increased; giving our users a great game experience consistent with their choice of hardware. In this sample we will convert a single-threaded animation system into a tasking animation system. There is small API the application uses for Tasking and internally that uses Intel TBB, but that usage could be replaced with whatever threading system was convenient.

VideoComingSoon.jpg

Video: Will be uploaded soon!  Please check back.

Read: Using Tasking to Scale Game Engine Systems

GDC Presentation: Yannis Minadakis, "Efficient scaling in a Task-Based Game Engine," Game Developers Conference, March 2011. (slides in PDF format)



GameEngineTaskingAnimnationScreenshot_small.jpg
The task-based animation sample in action. Toggle the “Enable Tasking” button to see the result of animating using tasking vs. animating on the main thread. Note that we achieve parallel animation on any number of cores by dividing the animation work into tasks.


System Requirements Additional Code Samples
  1. CPU: Dual core or better (Intel® Core™ i5 or better suggested)
  2. GFX: DX9c capable graphics card
  3. OS: Microsoft Windows Vista* or Microsoft Windows 7*
  4. MEM: 2 GB of RAM or better
  5. Software:
    o DirectX SDK (June 2010 release or later)
    o Build with Microsoft Visual Studio 2008* w/SP1 or Visual Studio 2010*

* Other names and brands may be claimed as the property of others.
TBB Licensing:
The files in this directory tree (the “TBB Files”) are a subset of Intel(r) Threading Building Blocks that
are provided solely for the purpose of evaluating the graphics samples contained in this distribution/package.

The TBB Files are made available under an Evaluation License as defined in the End User License Agreement
found in this directory in the file tbbEULA.txt. Please see tbbEULA.txt for the specific terms, conditions
and restrictions of this Evaluation License. This Evaluation License is granted for an unspecified evaluation
time period, however, Intel may terminate the evaluation period at anytime, and solely for the purposes, and
under the conditions and restrictions, described in this README file and in the End User License Agreement (tbbEULA.txt).

The TBB Files provided here provide a method of static linking. Static linking is not supported by the
Intel(r) Threading Building Blocks product, but is provided here solely for evaluation purposes.

For commercial licenses of Intel(r) Threading Building Blocks, contact: Intel_Tools_Games@intel.com

TBB End User License Agreement


Intel Visual Adrenaline
Developer Community
Intel® Software Partner Program
Game On
Showcase

]]> http://software.intel.com/en-us/articles/game-engine-tasking-animation/ Sun, 27 Feb 2011 00:00:00 -0800 http://software.intel.com/en-us/articles/game-engine-tasking-animation/#comments http://software.intel.com/en-us/articles/game-engine-tasking-animation/ Visual Computing Code & Downloads Game Development GPU Detect Sample

GPU Detect

GPU Detect is a short sample demonstrates a way to detect the primary graphics hardware present in a system, and to initialize a game’s default fidelity presets based on the found graphics device using a simple API. The code download includes documentation and is meant to be used as a guideline, and should be adapted to the game’s specific needs.





GPUDetect_screencap.jpg



System Requirements Additional Code Samples
  1. GFX: DX9c capable graphics card
  2. OS: Microsoft Windows XP* or newer
  3. Software:
    o DirectX SDK (June 2010 release or later)
    o Build with Microsoft Visual Studio 2008* w/SP1 or Visual Studio 2010*

* Other names and brands may be claimed as the property of others.


Intel Visual Adrenaline
Developer Community
Intel® Software Partner Program
Game On
Showcase


]]> http://software.intel.com/en-us/articles/gpu-detect-sample/ Sat, 19 Feb 2011 00:00:00 -0800 http://software.intel.com/en-us/articles/gpu-detect-sample/#comments http://software.intel.com/en-us/articles/gpu-detect-sample/ Visual Computing Code & Downloads Game Development Shadow Explorer

Shadow Explorer

Shadow Explorer is a sample application, with source code, that allows developers to work with several shadowing techniques, examine the performance versus quality tradeoffs of each one, and discover which is best suited for their game. In this first version of Shadow Explorer, we include four algorithms for evaluation: simple shadow maps, percentage closer shadow maps, variance shadow maps and exponential variance shadow maps. Each method is optimized for performance and exposes several variables, which allow the developer to further refine the technique in real time. Additionally, two scenes are provided to enable the developer to explore the strengths of each technique on different types of geometry.


Updated 7/14/2011: EVSM updates to respond to developer feedback.
ShadowExplorer1_small.jpg
ShadowExlorer2_small.jpg
ShadowExplorer3_small.jpg

The Shadow Explorer configured to show Exponential Variance Shadow Maps with 5 cascades.

Visualizing the shadow map cascades within Shadow Explorer.

The light space and the cascades can be visualized concurrently as the user changes multiple shadow techniques and inputs in real time.


System Requirements Additional Code Samples
  1. CPU: Dual core or better (Intel® Core™ i5 or better suggested)
  2. GFX: DX9c capable graphics card
  3. OS: Microsoft Windows Vista* or Microsoft Windows 7*
  4. MEM: 2 GB of RAM or better
  5. Software:
    o DirectX SDK (June 2010 release or later)
    o Build with Microsoft Visual Studio 2008* w/SP1 or Visual Studio 2010*

* Other names and brands may be claimed as the property of others.


Intel Visual Adrenaline
Developer Community
Intel® Software Partner Program
Game On
Showcase


]]> http://software.intel.com/en-us/articles/shadowexplorer/ Sun, 06 Feb 2011 00:00:00 -0800 http://software.intel.com/en-us/articles/shadowexplorer/#comments http://software.intel.com/en-us/articles/shadowexplorer/ Visual Computing Code & Downloads Game Development Adaptive Transparency
aoit_left_small.jpg aoit_right_small.jpg

Transparency is a fundamental open problem in real-time rendering due to the difficulty of compositing in the right order an arbitrary number of transparent layers. The current situation in real-time applications is exemplified by the left image, where numerous objects are incorrectly composited when rendered with alpha-blending, the most popular algorithm for rendering transparent geometry. On the other hand, as shown by the right image, our algorithm can correctly composite all transparent layers while maintaining performance levels typical of real-time applications.



]]> http://software.intel.com/en-us/articles/adaptive-transparency/ Sat, 05 Feb 2011 00:00:00 -0800 http://software.intel.com/en-us/articles/adaptive-transparency/#comments http://software.intel.com/en-us/articles/adaptive-transparency/ Visual Computing Code & Downloads Game Development Threaded Crowd Simulation with Collision Avoidance Download article or visit Colony Page
Download Threaded Crowd Simulation with Collision Avoidance [PDF 714KB]
Visit Colony Page (source, binaries, videos)


Figure 1: Colony in action

One problem that limits the ambitions of modern real-time strategy games is how to tackle the simulation of more than a few hundred units on screen all interacting with collision avoidance. How can we raise the bar on the number of units in a game and still have the game run in real time? Strategy and arcade genre games have small unit counts due to processing overhead. In Colony, we show how that overhead can be minimized with threading on the CPU. We show how to architect multi-threaded collision avoidance. We use profiling tools to visualize the application's behavior, identify problems, and verify the solutions. When optimized, Colony can simulate many thousands of AI-controlled units at 30 frames per second.


Introduction

Colony demonstrates a simulation on the scale of thousands of units within the context of a simple, game-like scenario. This demo showcases real-time local collision avoidance in a task-based, optimized code sample. Colony is implemented as an arcade game to simulate the performance budget game developers have for AI pathfinding and collision avoidance technologies. With Colony, we show how to manage a large number of units without busting the performance budget.


Colony: A Game That Plays Itself

This is not technically a game in that it has only minimal user interaction and no goal, but it was designed using a similar programming approach. The logic flow and data layout are comparable to what you would find in a modern game. Colony starts with a forest scene on a sunny day. Zooming in closer, you see robots moving about. The robots' primary goal is to pave over the entire forest. They first build some concrete factories around the map, after which they systematically deforest the region by making concrete, paving a section, and returning for more concrete. They go back and forth like this until the entire forest is gone, then they start over.


Architecture of the Colony Simulation

Colony is implemented in two parts, simulation and everything else such as gameplay and anything not related to the units. The map tiles, the trees, the coverage calculation, are all part of the second part. It's fairly lightweight because there is no real game functionality, but this is where any additional features would be implemented.

Simulation data is stored in Game object along with the characteristics of the level, such as the dimensions of the map and associated data. The key function of the Game object is the simulation update routine. Collision avoidance is done in the update step using a spatial structure for sorting units. Colony uses a modified kd-Tree to store units, allowing fast access to the nearest neighbors of each unit. We also considered using a broadphase sweep and prune (SAP) approach. The problem with a SAP method is that insertions and deletions are expensive, and the unit count fluctuates constantly. Units were generally uniformly distributed on the map. To improve insertion and deletion performance we implemented a simple binning approach to exclude far units from consideration.

The terrain was partitioned into a fixed-size rectangular grid that corresponds to the physical position of the map. At the beginning of each frame, we insert the units into bins based on their X and Y positions in the simulation. The bin size was chosen by experimenting with different sizes.

The search distance in the simulation is based on the dimensions of the bins. Imagine just a few units all jostling around inside a square, each trying to avoid each other while attempting to move along a path to their goal.

Figure 2: A two-dimensional projection of the Colony map bins

The initial implementation of the update step looped through all units and computed the velocities each unit needs to reach its goal. To improve performance, the sight distance of each unit is limited to 2 bins allowing each unit to consider significantly fewer neighbors. The size of each bin is bounded by the maximum number of units that can exist on that part of the terrain.

Units carry with them all the properties necessary to move about the map, such as velocity, their goal position, their position, and their radius. These are all stored in structure-of-array (SOA) data structures to ensure maximum cache efficiency and SIMD usability. All the information is stored in these arrays and then units are accessed solely by index.


Stepping the Simulation: The Update Call

Now that we have a better understanding of the underlying storage and binning, it's easier to see what goes on during a simulation update. The main loop in Colony calculates direction for units and reconciles physical forces and constraints from their local collision avoidance. A closer look at the simulation reveals a specific design strategy and the threading and performance optimizations that make such a large number of units possible.


Binning

We chose a static binning approach for two reasons. The first is better performance for the nearest-neighbor search needed for unit-unit collision avoidance. The second reason is the ease of hashing a position from the UI to world space. During each frame we rehash all units to their proper bins for the collision avoidance calculation. Current bin size provides the best balance between overhead of processing bins and simulation performance.

Figure 3: Bins and nearest neighbor bins

We had originally considered using a dynamic binning approach, in which the bins would automatically size themselves to contain all the units. However, this method ended up adding too much overhead in our specific scenario. A dynamic binning approach would make more sense with less uniformly distributed units or a dynamic map.


Updating Game Objects

This algorithm calculates each unit's new direction by casting two rays out from the current unit. These rays go in the direction the unit is currently moving, and are spaced the width of the unit apart.

These rays are compared against every neighbor unit in each of the neighbor bins. If either ray hits any of the units, the current unit turns to the same point on the opposite ray (the yellow arrows in Figure 4). This causes the unit to make a sharp or gradual turn, depending on the distance to the neighbor.

Figure 4. Example of collision ray casting


Parallelize Serial Hotspots

Amdahl's law reveals how serial code limits the maximum performance we can expect [M.QUINN04]:


Ideally the Colony simulation would complete the entire update in parallel. Unfortunately, sequential steps are often necessary, as many computations serve as input to further steps. In Colony, we chose to distribute our work as tasks. For our approach, we utilized a Task Manager wrapper around Intel® Threading Building Blocks (TBB) that provides an easy interface to TBB's task-stealing architecture. With this Task Manager, we create a taskset for each step in the simulation, specifying all prerequisites to the taskset as dependencies. Dependencies of a taskset are previously created tasksets that must complete before the new taskset can begin execution. The simulation is partitioned such that each taskset does not require data calculated in other tasks within that operation, and that the range of data being operated on is easily split up. Our update function performs the following parallel steps, operating on arrays where the start and end indices demarcate a group of tasks executed in parallel across the cores of the CPU.
  1. Assign units to bins
  2. Determine new directions for binned units (depends on number 1)
  3. Update units along their new direction and perform unit logic (depends on number 2)
We can see the impact of this parallelization with Intel® VTune Amplifier XE 2011, showing the CalculateDirection method's concurrency when measured on a 4-core 2nd Generation Intel® Core™ processor with HDG 3000.


Figure 5. Concurrency of the CalculateDirectionTask function


Intel VTune Amplifier XE 2011 also shows us overall concurrency. The majority of the simulation time is well distributed across the available hardware threads with only minor serial sections that can be mostly attributed to rendering:

Figure 6. Overall concurrency histogram

And here is the task distribution across one frame as observed using Intel® Graphics Performance Analyzers (Intel® GPA) Platform View with an exploded view of one hardware thread. As previously shown in Intel VTune Amplifier XE 2011, calculating directions takes up the majority of the time:

Figure 7. Work spread across 8 threads on the test system


Performance

Figure 8. Unit count at 30 frames per second


Figure 9. Decreasing frame times with more cores and with Intel® Hyper-Threading Technology

With Intel® Hyper-Threading Technology on, we see a 1.79x performance gain when moving from 2 cores to 4 cores. This analysis was performed on a 4-core 2nd Generation Intel® Core™ processor with HDG 3000 with each core at 2.30 GHz.

Future Work

Potential future work that can be done on Colony includes interactivity, animation, and improved binning. Interactivity and animated units would make the current workload more representative of a real game workload. Improved binning should be able to adapt bin size based on unit density. Smaller bins for high densities and larger bins for low densities would equalize the workload of each bin. In the binning approach currently implemented, some bins may have a max of one hundred units while other bins may be empty. A dynamic binning approach would better distribute the work of calculating directions for high concentration of units across multiple threads.


Conclusion

As CPU core counts continue to increase, the ability to harness that available horsepower is crucial to budgeting a larger number of units in modern real-time strategy games. Colony demonstrates one of many possible technologies for simulating a large number of units with collision avoidance. More advanced technologies could be considered, as well as implementations that focus on more advanced AI. As seen in our simulation update step, the key to easy parallelism lies in the identification of sequential blocks of code with tools such as Intel® Parallel Studio and the storage of data so that it can be easily broken up into chunks for processing, all of which is possible with Intel® Threading Building Blocks.


Resources


About the Authors

Kyle Weicht is a software engineer in the Intel Software and Services Group, where he supports Intel graphics solutions in the Visual Computing Software Division. He holds a B.S. in Game Development from Full Sail University.

Omar A. Rodriguez is a software engineer in the Intel Software and Services Group, where he supports Intel graphics solutions in the Visual Computing Software Division. He holds a B.S. in Computer Science from Arizona State University. Omar is not the lead guitarist for the Mars Volta.

Jeff Freeman is a software engineer in the Intel Software and Services Group, where he supports Intel graphics solutions in the Visual Computing Software Division. He holds a B.S. in Computer Science from Rensselaer Polytechnic Institute.

Omar A. Rodriguez
Kyle Weicht
Jeff Freeman
12-15-2010
12-15-2010
Tech Articles
Intel® GPA
Intel® TBB
no
We introduce Colony, a real-time simulation of a large number of units with AI and collision avoidance. Colony harnesses increasing CPU core count to parallelize serial portions of simulation update code identified by Intel® Parallel Studio. The optimized task-based version of Colony can simulate many thousands of AI-controlled units at 30 frames per second.
]]> http://software.intel.com/en-us/articles/threaded-crowd-simulation-with-collision-avoidance/ Thu, 16 Dec 2010 00:00:00 -0800 http://software.intel.com/en-us/articles/threaded-crowd-simulation-with-collision-avoidance/#comments http://software.intel.com/en-us/articles/threaded-crowd-simulation-with-collision-avoidance/ Visual Computing Game Development Visual Computing Source Onloaded Shadows

Onloaded Shadows

Onloaded Shadows is a technique by which shadow maps can be calculated asynchronously on the CPU. By using cascades, the shadow map for objects near the camera are calculated every frame on the GPU, but the shadow maps for objects in the second cascade and beyond are calculated less often on the CPU. This allows for better work balancing across the CPU and GPU.
OnloadedShadowsWeb1_small.jpg
OnloadedShadowsWeb2_small.jpg
OnloadedShadowsWeb3_small.jpg

Screenshot of the application with Onloaded Shadows technique.

Screenshot of the sample from the light's view with cascades visualized.

Screenshot of the sample upon start up.  Shadows further from the camera are calculated on the CPU asynchronously.


System Requirements Additional Code Samples
  1. CPU: Dual core or better (Intel® Core™ i5 or better suggested)
  2. GFX: DX9c capable graphics card
  3. OS: Microsoft Windows Vista* or Microsoft Windows 7*
  4. MEM: 2 GB of RAM or better
  5. Software:
    o DirectX SDK (June 2010 release or later)
    o Build with Microsoft Visual Studio 2008* w/SP1 or Visual Studio 2010*

* Other names and brands may be claimed as the property of others.


Intel Visual Adrenaline
Developer Community
Intel® Software Partner Program
Game On
Showcase


]]> http://software.intel.com/en-us/articles/onloaded-shadows/ Sun, 12 Dec 2010 00:00:00 -0800 http://software.intel.com/en-us/articles/onloaded-shadows/#comments http://software.intel.com/en-us/articles/onloaded-shadows/ Visual Computing Code & Downloads Game Development