Feature Proposals/BulletSim OpenCL - Revision history

Allquixotic at 20:25, 10 September 2013

2013-09-10T20:25:28Z

Allquixotic: /* Introduction and Problem Statement */

2013-09-10T18:57:12Z

‎Introduction and Problem Statement

Allquixotic at 18:47, 10 September 2013

2013-09-10T18:47:00Z

Allquixotic: /* Advantages and Disadvantages */

2013-09-10T18:42:58Z

‎Advantages and Disadvantages

Allquixotic: /* Implementation Ideas */

2013-09-10T18:25:36Z

‎Implementation Ideas

Allquixotic at 18:01, 10 September 2013

2013-09-10T18:01:33Z

Allquixotic: /* Brainstorming */

2013-09-10T17:55:59Z

‎Brainstorming

Allquixotic: /* Brainstorming */

2013-09-10T17:44:30Z

‎Brainstorming

Allquixotic: /* Introduction and Problem Statement */

2013-09-10T17:27:25Z

‎Introduction and Problem Statement

Allquixotic: /* GPU OpenCL Support */

2013-09-10T17:10:52Z

‎GPU OpenCL Support

@@ Line 1: / Line 1: @@
 {| class="wikitable"
 !colspan="8"|Basic Information
@@ Line 16: / Line 18: @@
 ! scope="row"|Core Dev Sponsor(s)
 |None yet.
 |}

@@ Line 34: / Line 34: @@
 |'''Hardware Class For Acceptable Performance'''
 |-
-!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''
+!colspan="8"|↓↓'''Baseline: Yay, we have physics! ...somewhat.'''↓↓
 |-
 |Poor
@@ Line 41: / Line 41: @@
 |Laptop, netbook, or embedded
 |-
-!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''
+!colspan="8"|↓↓'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''↓↓
 |-
 |Good
@@ Line 53: / Line 53: @@
 |Commodity desktop or small server
 |-
-!colspan="8"|'''Not currently possible for most individuals and small businesses'''
+!colspan="8"|↓↓'''Not currently possible for most individuals and small businesses'''↓↓
 |-
 |Good
@@ Line 65: / Line 65: @@
 |Large server (multi-CPU) '''OR''' GPU-accelerated
 |-
-!colspan="8"|'''Possible in the future with GPU acceleration'''
+!colspan="8"|↓↓'''Possible in the future with GPU acceleration'''↓↓
 |-
 |Extreme

@@ Line 2: / Line 2: @@
 !colspan="8"|Basic Information
 |-
-|'''Proposal Name'''
+! scope="row"|Proposal Name
 |BulletSim GPU Acceleration Using OpenCL
 |-
-|'''Date Proposed'''
+! scope="row"|Date Proposed
 |September 10, 2013
 |-
-|'''Status'''
+! scope="row"|Status
 |Draft
 |-
-|'''Proposer'''
+! scope="row"|Proposer
 |[[User:Allquixotic]]
 |}

@@ Line 111: / Line 111: @@
 == Brainstorming Ideas ==
-=== Advantages and Disadvantages ===
+=== Advantages and Challenges ===
 '''Advantages:'''
@@ Line 119: / Line 119: @@
 * Unlock a new level of complexity and dynamicity in OpenSimulator (although other components, such as users' graphics cards, may take time to catch up).
-'''Disadvantages:'''
+'''Challenges:'''
 * A lot of existing hardware hosting OpenSimulator does not have any GPU at all.
 * Acquiring a dedicated GPU for a server that does not have one can be very expensive, especially if you have to custom request one from your hosting provider.

@@ Line 126: / Line 126: @@
 === Implementation Ideas ===
-# We should have a config file option in OpenSim.ini under a BulletSim heading for whether or not to enable OpenCL. Trying to be smart and autodetect might lead to problems, such as a user with an unstable graphics driver accidentally crashing their system (and then if OpenSim starts on boot, that's REALLY bad because their system crashes during the boot procedure!). We absolutely must have a way for the user to enable or disable OpenCL support, and leave it '''disabled''' by default out of the box.
+# We should have a config file option in OpenSim.ini under a BulletSim heading for whether or not to enable OpenCL. Trying to be smart and autodetect might lead to problems, such as a user with an unstable graphics driver accidentally crashing their system (and then if OpenSim starts on boot, that's REALLY bad because their system crashes during the boot procedure!). We absolutely must have a way for the user to enable or disable OpenCL support, and leave it '''disabled''' by default out of the box.<br />
+# We should not throw away our existing code that uses the CPU paths of Bullet. The Bullet non-OpenCL paths are probably faster running on the CPU than a CPU implementation of OpenCL running the OpenCL paths of Bullet, simply because a layer of complexity is removed.<br />
-# We should not throw away our existing code that uses the CPU paths of Bullet. The Bullet non-OpenCL paths are probably faster running on the CPU than a CPU implementation of OpenCL running the OpenCL paths of Bullet, simply because a layer of complexity is removed.
+# If Bullet doesn't already do this, we should refuse to run OpenCL on the CPU except for testing and debugging purposes (maybe a compile flag).
 = GPU OpenCL Support =

@@ Line 108: / Line 108: @@
 # What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?
 # Even if we successfully accelerate Bullet to a high degree, are we still bottlenecked by disk, memory bandwidth, locking primitives in OpenSimulator, or the .NET runtime, inhibiting our scalability past a certain point? If so, how far can we go before we hit this wall? Does GPU acceleration buy us anything, or are we already ''against'' that wall with the capabilities of CPU-based physics?
 = GPU OpenCL Support =

@@ Line 94: / Line 94: @@
 = Scope of Work =
-== Brainstorming ==
+== Brainstorming Questions ==
 If you can answer any of these questions, please [http://opensimulator.org/index.php?title=Feature_Proposals/BulletSim_OpenCL&action=edit edit this page] and fill in an answer beneath each question!

@@ Line 98: / Line 98: @@
 If you can answer any of these questions, please [http://opensimulator.org/index.php?title=Feature_Proposals/BulletSim_OpenCL&action=edit edit this page] and fill in an answer beneath each question!
-. Let's assume that we're going to target the latest Bullet code from version control, and evolve our code to match as Bullet evolves. We should do this ''at least'' until Bullet 3.0 is released as stable, because major improvements to the OpenCL rigid body pipeline are available in git that are not in the latest stable release as of this writing.
+# Let's assume that we're going to target the latest Bullet code from version control, and evolve our code to match as Bullet evolves. We should do this ''at least'' until Bullet 3.0 is released as stable, because major improvements to the OpenCL rigid body pipeline are available in git that are not in the latest stable release as of this writing.
-. What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?
+# What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?
-. Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?
+# Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?
-. What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?
+# What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?
-(a). Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?
+## Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?
-(b). Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?
+## Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?
-(c). Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?
+## Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?
-. What hardware and software configurations should we test on?
+# What hardware and software configurations should we test on?
-. What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?
+# What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?
-. Even if we successfully accelerate Bullet to a high degree, are we still bottlenecked by disk, memory bandwidth, locking primitives in OpenSimulator, or the .NET runtime, inhibiting our scalability past a certain point? If so, how far can we go before we hit this wall? Does GPU acceleration buy us anything, or are we already ''against'' that wall with the capabilities of CPU-based physics?
+# Even if we successfully accelerate Bullet to a high degree, are we still bottlenecked by disk, memory bandwidth, locking primitives in OpenSimulator, or the .NET runtime, inhibiting our scalability past a certain point? If so, how far can we go before we hit this wall? Does GPU acceleration buy us anything, or are we already ''against'' that wall with the capabilities of CPU-based physics?
-−
 = GPU OpenCL Support =

@@ Line 20: / Line 20: @@
 Physics-based simulations and interactions may continue to be optimized on the CPU by switching from the OpenDynamicsEngine physics backend to the the Bullet Physics Engine, because Bullet is significantly faster and more optimized than ODE. However, even Bullet has its upper limit of capabilities on the CPU. Furthermore, there is a certain tradeoff to be made between accuracy/precision and speed, as depicted in the following table. The point is, by raising our computational ceiling, we can either achieve better precision, larger scale (more or more complex objects that are physical), or some tradeoff improving both aspects to a lesser degree. The other point is that GPU acceleration is currently the most cost-sensitive way to raise the performance ceiling (can ''you'' afford a supercomputer?).
 {| class="wikitable"
@@ Line 72: / Line 74: @@
 |High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs
 |}
 = Proposal =

@@ Line 139: / Line 139: @@
 |GeForce 400 Series or later
 Quadro 400 Series or later
 Tesla
 |style="background-color: lime;"|Fully Supported