http://opensimulator.org/api.php?action=feedcontributions&feedformat=atom&user=AllquixoticOpenSimulator - User contributions [en]2026-04-04T16:11:49ZUser contributionsMediaWiki 1.19.9http://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T20:25:28Z<p>Allquixotic: </p>
<hr />
<div>{{proposal}}<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
! scope="row"|Proposal Name<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
! scope="row"|Date Proposed<br />
|September 10, 2013<br />
|-<br />
! scope="row"|Status<br />
|Draft<br />
|-<br />
! scope="row"|Proposer<br />
|[[User:Allquixotic]]<br />
|-<br />
! scope="row"|Core Dev Sponsor(s)<br />
|None yet.<br />
|-<br />
! scope="row"|Commercial?<br />
|No.<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
'''Caveat''': I am well aware that the estimates of scale below for the number of prims is potentially inaccurate by several orders of magnitude up or down. These are ''rough'' estimates. I am also aware that different types of physics interactions and different shapes have vastly different computational costs; for instance, it is much easier to calculate collision between two cubes compared to two toruses (torii?). The general point, however, remains valid.<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|↓↓'''Baseline: Yay, we have physics! ...somewhat.'''↓↓<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|↓↓'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''↓↓<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|↓↓'''Not currently possible for most individuals and small businesses'''↓↓<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|↓↓'''Possible in the future with GPU acceleration'''↓↓<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming Questions ==<br />
<br />
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!<br />
<br />
# 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.<br />
# What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
# Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
# What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
## Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
## Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
## Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
# What hardware and software configurations should we test on?<br />
# What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
# 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?<br />
<br />
== Brainstorming Ideas ==<br />
<br />
=== Advantages and Challenges ===<br />
<br />
'''Advantages:'''<br />
* Improved performance.<br />
* Reduced CPU usage.<br />
* Ability to use more physical objects with the same performance goals.<br />
* Unlock a new level of complexity and dynamicity in OpenSimulator (although other components, such as users' graphics cards, may take time to catch up).<br />
<br />
'''Challenges:'''<br />
* A lot of existing hardware hosting OpenSimulator does not have any GPU at all.<br />
* 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.<br />
* Support for open source Linux graphics drivers running OpenCL is still in a very early stage (as of September 2013).<br />
<br />
=== Implementation Ideas ===<br />
<br />
# 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 /><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 /><br />
# 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).<br />
# We should look at Bullet developer and user blogs, wikis, code comments, etc. and attempt to figure out what parts of the GPU rendering pipeline provide the greatest performance improvement vs. CPU, and run the best on GPUs, and exploit that to the best of our ability, while avoiding or minimizing the use of features that the GPU does not handle as well.<br /><br />
# We should investigate the possibility of continuing to use the CPU for physics, especially if there are certain interactions or edge cases that are horribly slow on a GPU, or not implemented in the GPU pipeline on Bullet. Better yet, we could develop some sort of physics scheduler, that first attempts to max out the GPU, and if there are still physics calculations that need to be done, push the remainder of them onto the CPU until the CPU is also saturated. On high-end servers, the CPUs do indeed allow for a non-trivial amount of physics to be done, so we needn't leave it all up to the GPU<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T18:57:12Z<p>Allquixotic: /* Introduction and Problem Statement */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
! scope="row"|Proposal Name<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
! scope="row"|Date Proposed<br />
|September 10, 2013<br />
|-<br />
! scope="row"|Status<br />
|Draft<br />
|-<br />
! scope="row"|Proposer<br />
|[[User:Allquixotic]]<br />
|-<br />
! scope="row"|Core Dev Sponsor(s)<br />
|None yet.<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
'''Caveat''': I am well aware that the estimates of scale below for the number of prims is potentially inaccurate by several orders of magnitude up or down. These are ''rough'' estimates. I am also aware that different types of physics interactions and different shapes have vastly different computational costs; for instance, it is much easier to calculate collision between two cubes compared to two toruses (torii?). The general point, however, remains valid.<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|↓↓'''Baseline: Yay, we have physics! ...somewhat.'''↓↓<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|↓↓'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''↓↓<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|↓↓'''Not currently possible for most individuals and small businesses'''↓↓<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|↓↓'''Possible in the future with GPU acceleration'''↓↓<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming Questions ==<br />
<br />
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!<br />
<br />
# 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.<br />
# What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
# Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
# What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
## Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
## Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
## Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
# What hardware and software configurations should we test on?<br />
# What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
# 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?<br />
<br />
== Brainstorming Ideas ==<br />
<br />
=== Advantages and Challenges ===<br />
<br />
'''Advantages:'''<br />
* Improved performance.<br />
* Reduced CPU usage.<br />
* Ability to use more physical objects with the same performance goals.<br />
* Unlock a new level of complexity and dynamicity in OpenSimulator (although other components, such as users' graphics cards, may take time to catch up).<br />
<br />
'''Challenges:'''<br />
* A lot of existing hardware hosting OpenSimulator does not have any GPU at all.<br />
* 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.<br />
* Support for open source Linux graphics drivers running OpenCL is still in a very early stage (as of September 2013).<br />
<br />
=== Implementation Ideas ===<br />
<br />
# 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 /><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 /><br />
# 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).<br />
# We should look at Bullet developer and user blogs, wikis, code comments, etc. and attempt to figure out what parts of the GPU rendering pipeline provide the greatest performance improvement vs. CPU, and run the best on GPUs, and exploit that to the best of our ability, while avoiding or minimizing the use of features that the GPU does not handle as well.<br /><br />
# We should investigate the possibility of continuing to use the CPU for physics, especially if there are certain interactions or edge cases that are horribly slow on a GPU, or not implemented in the GPU pipeline on Bullet. Better yet, we could develop some sort of physics scheduler, that first attempts to max out the GPU, and if there are still physics calculations that need to be done, push the remainder of them onto the CPU until the CPU is also saturated. On high-end servers, the CPUs do indeed allow for a non-trivial amount of physics to be done, so we needn't leave it all up to the GPU<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T18:47:00Z<p>Allquixotic: </p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
! scope="row"|Proposal Name<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
! scope="row"|Date Proposed<br />
|September 10, 2013<br />
|-<br />
! scope="row"|Status<br />
|Draft<br />
|-<br />
! scope="row"|Proposer<br />
|[[User:Allquixotic]]<br />
|-<br />
! scope="row"|Core Dev Sponsor(s)<br />
|None yet.<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
'''Caveat''': I am well aware that the estimates of scale below for the number of prims is potentially inaccurate by several orders of magnitude up or down. These are ''rough'' estimates. I am also aware that different types of physics interactions and different shapes have vastly different computational costs; for instance, it is much easier to calculate collision between two cubes compared to two toruses (torii?). The general point, however, remains valid.<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming Questions ==<br />
<br />
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!<br />
<br />
# 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.<br />
# What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
# Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
# What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
## Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
## Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
## Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
# What hardware and software configurations should we test on?<br />
# What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
# 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?<br />
<br />
== Brainstorming Ideas ==<br />
<br />
=== Advantages and Challenges ===<br />
<br />
'''Advantages:'''<br />
* Improved performance.<br />
* Reduced CPU usage.<br />
* Ability to use more physical objects with the same performance goals.<br />
* Unlock a new level of complexity and dynamicity in OpenSimulator (although other components, such as users' graphics cards, may take time to catch up).<br />
<br />
'''Challenges:'''<br />
* A lot of existing hardware hosting OpenSimulator does not have any GPU at all.<br />
* 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.<br />
* Support for open source Linux graphics drivers running OpenCL is still in a very early stage (as of September 2013).<br />
<br />
=== Implementation Ideas ===<br />
<br />
# 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 /><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 /><br />
# 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).<br />
# We should look at Bullet developer and user blogs, wikis, code comments, etc. and attempt to figure out what parts of the GPU rendering pipeline provide the greatest performance improvement vs. CPU, and run the best on GPUs, and exploit that to the best of our ability, while avoiding or minimizing the use of features that the GPU does not handle as well.<br /><br />
# We should investigate the possibility of continuing to use the CPU for physics, especially if there are certain interactions or edge cases that are horribly slow on a GPU, or not implemented in the GPU pipeline on Bullet. Better yet, we could develop some sort of physics scheduler, that first attempts to max out the GPU, and if there are still physics calculations that need to be done, push the remainder of them onto the CPU until the CPU is also saturated. On high-end servers, the CPUs do indeed allow for a non-trivial amount of physics to be done, so we needn't leave it all up to the GPU<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T18:42:58Z<p>Allquixotic: /* Advantages and Disadvantages */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
'''Caveat''': I am well aware that the estimates of scale below for the number of prims is potentially inaccurate by several orders of magnitude up or down. These are ''rough'' estimates. I am also aware that different types of physics interactions and different shapes have vastly different computational costs; for instance, it is much easier to calculate collision between two cubes compared to two toruses (torii?). The general point, however, remains valid.<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming Questions ==<br />
<br />
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!<br />
<br />
# 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.<br />
# What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
# Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
# What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
## Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
## Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
## Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
# What hardware and software configurations should we test on?<br />
# What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
# 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?<br />
<br />
== Brainstorming Ideas ==<br />
<br />
=== Advantages and Challenges ===<br />
<br />
'''Advantages:'''<br />
* Improved performance.<br />
* Reduced CPU usage.<br />
* Ability to use more physical objects with the same performance goals.<br />
* Unlock a new level of complexity and dynamicity in OpenSimulator (although other components, such as users' graphics cards, may take time to catch up).<br />
<br />
'''Challenges:'''<br />
* A lot of existing hardware hosting OpenSimulator does not have any GPU at all.<br />
* 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.<br />
* Support for open source Linux graphics drivers running OpenCL is still in a very early stage (as of September 2013).<br />
<br />
=== Implementation Ideas ===<br />
<br />
# 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 /><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 /><br />
# 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).<br />
# We should look at Bullet developer and user blogs, wikis, code comments, etc. and attempt to figure out what parts of the GPU rendering pipeline provide the greatest performance improvement vs. CPU, and run the best on GPUs, and exploit that to the best of our ability, while avoiding or minimizing the use of features that the GPU does not handle as well.<br /><br />
# We should investigate the possibility of continuing to use the CPU for physics, especially if there are certain interactions or edge cases that are horribly slow on a GPU, or not implemented in the GPU pipeline on Bullet. Better yet, we could develop some sort of physics scheduler, that first attempts to max out the GPU, and if there are still physics calculations that need to be done, push the remainder of them onto the CPU until the CPU is also saturated. On high-end servers, the CPUs do indeed allow for a non-trivial amount of physics to be done, so we needn't leave it all up to the GPU<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T18:25:36Z<p>Allquixotic: /* Implementation Ideas */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
'''Caveat''': I am well aware that the estimates of scale below for the number of prims is potentially inaccurate by several orders of magnitude up or down. These are ''rough'' estimates. I am also aware that different types of physics interactions and different shapes have vastly different computational costs; for instance, it is much easier to calculate collision between two cubes compared to two toruses (torii?). The general point, however, remains valid.<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming Questions ==<br />
<br />
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!<br />
<br />
# 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.<br />
# What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
# Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
# What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
## Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
## Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
## Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
# What hardware and software configurations should we test on?<br />
# What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
# 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?<br />
<br />
== Brainstorming Ideas ==<br />
<br />
=== Advantages and Disadvantages ===<br />
<br />
'''Advantages:'''<br />
* Improved performance.<br />
* Reduced CPU usage.<br />
* Ability to use more physical objects with the same performance goals.<br />
* Unlock a new level of complexity and dynamicity in OpenSimulator (although other components, such as users' graphics cards, may take time to catch up).<br />
<br />
'''Disadvantages:'''<br />
* A lot of existing hardware hosting OpenSimulator does not have any GPU at all.<br />
* 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.<br />
* Support for open source Linux graphics drivers running OpenCL is still in a very early stage (as of September 2013).<br />
<br />
=== Implementation Ideas ===<br />
<br />
# 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 /><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 /><br />
# 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).<br />
# We should look at Bullet developer and user blogs, wikis, code comments, etc. and attempt to figure out what parts of the GPU rendering pipeline provide the greatest performance improvement vs. CPU, and run the best on GPUs, and exploit that to the best of our ability, while avoiding or minimizing the use of features that the GPU does not handle as well.<br /><br />
# We should investigate the possibility of continuing to use the CPU for physics, especially if there are certain interactions or edge cases that are horribly slow on a GPU, or not implemented in the GPU pipeline on Bullet. Better yet, we could develop some sort of physics scheduler, that first attempts to max out the GPU, and if there are still physics calculations that need to be done, push the remainder of them onto the CPU until the CPU is also saturated. On high-end servers, the CPUs do indeed allow for a non-trivial amount of physics to be done, so we needn't leave it all up to the GPU<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T18:01:33Z<p>Allquixotic: </p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
'''Caveat''': I am well aware that the estimates of scale below for the number of prims is potentially inaccurate by several orders of magnitude up or down. These are ''rough'' estimates. I am also aware that different types of physics interactions and different shapes have vastly different computational costs; for instance, it is much easier to calculate collision between two cubes compared to two toruses (torii?). The general point, however, remains valid.<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming Questions ==<br />
<br />
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!<br />
<br />
# 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.<br />
# What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
# Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
# What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
## Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
## Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
## Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
# What hardware and software configurations should we test on?<br />
# What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
# 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?<br />
<br />
== Brainstorming Ideas ==<br />
<br />
=== Advantages and Disadvantages ===<br />
<br />
'''Advantages:'''<br />
* Improved performance.<br />
* Reduced CPU usage.<br />
* Ability to use more physical objects with the same performance goals.<br />
* Unlock a new level of complexity and dynamicity in OpenSimulator (although other components, such as users' graphics cards, may take time to catch up).<br />
<br />
'''Disadvantages:'''<br />
* A lot of existing hardware hosting OpenSimulator does not have any GPU at all.<br />
* 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.<br />
* Support for open source Linux graphics drivers running OpenCL is still in a very early stage (as of September 2013).<br />
<br />
=== Implementation Ideas ===<br />
<br />
# 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 />
<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 />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T17:55:59Z<p>Allquixotic: /* Brainstorming */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
'''Caveat''': I am well aware that the estimates of scale below for the number of prims is potentially inaccurate by several orders of magnitude up or down. These are ''rough'' estimates. I am also aware that different types of physics interactions and different shapes have vastly different computational costs; for instance, it is much easier to calculate collision between two cubes compared to two toruses (torii?). The general point, however, remains valid.<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming Questions ==<br />
<br />
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!<br />
<br />
# 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.<br />
# What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
# Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
# What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
## Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
## Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
## Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
# What hardware and software configurations should we test on?<br />
# What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
# 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?<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T17:44:30Z<p>Allquixotic: /* Brainstorming */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
'''Caveat''': I am well aware that the estimates of scale below for the number of prims is potentially inaccurate by several orders of magnitude up or down. These are ''rough'' estimates. I am also aware that different types of physics interactions and different shapes have vastly different computational costs; for instance, it is much easier to calculate collision between two cubes compared to two toruses (torii?). The general point, however, remains valid.<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming ==<br />
<br />
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!<br />
<br />
# 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.<br />
# What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
# Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
# What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
## Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
## Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
## Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
# What hardware and software configurations should we test on?<br />
# What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
# 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?<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T17:27:25Z<p>Allquixotic: /* Introduction and Problem Statement */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
'''Caveat''': I am well aware that the estimates of scale below for the number of prims is potentially inaccurate by several orders of magnitude up or down. These are ''rough'' estimates. I am also aware that different types of physics interactions and different shapes have vastly different computational costs; for instance, it is much easier to calculate collision between two cubes compared to two toruses (torii?). The general point, however, remains valid.<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming ==<br />
<br />
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!<br />
<br />
0. 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.<br />
1. What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
2. Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
3. What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
3(a). Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
3(b). Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
3(c). Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
4. What hardware and software configurations should we test on?<br />
5. What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
6. 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?<br />
<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T17:10:52Z<p>Allquixotic: /* GPU OpenCL Support */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming ==<br />
<br />
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!<br />
<br />
0. 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.<br />
1. What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
2. Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
3. What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
3(a). Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
3(b). Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
3(c). Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
4. What hardware and software configurations should we test on?<br />
5. What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
6. 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?<br />
<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T17:10:06Z<p>Allquixotic: /* GPU OpenCL Support */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming ==<br />
<br />
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!<br />
<br />
0. 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.<br />
1. What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
2. Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
3. What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
3(a). Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
3(b). Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
3(c). Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
4. What hardware and software configurations should we test on?<br />
5. What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
6. 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?<br />
<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T17:09:56Z<p>Allquixotic: /* GPU OpenCL Support */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming ==<br />
<br />
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!<br />
<br />
0. 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.<br />
1. What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
2. Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
3. What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
3(a). Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
3(b). Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
3(c). Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
4. What hardware and software configurations should we test on?<br />
5. What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
6. 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?<br />
<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
"Knights Corner" (Xeon Phi) or later<br />
<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T17:09:39Z<p>Allquixotic: /* GPU OpenCL Support */</p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming ==<br />
<br />
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!<br />
<br />
0. 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.<br />
1. What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
2. Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
3. What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
3(a). Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
3(b). Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
3(c). Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
4. What hardware and software configurations should we test on?<br />
5. What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
6. 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?<br />
<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" Desktop/Mobile (Core i3/i5/i7 3xxx) or later<br />
"Ivy Bridge" Server (Xeon 1275v2) or later<br />
"Knights Corner" (Xeon Phi) or later<br />
Excluding enthusiast and multi-CPU chips (Ivy-E, etc.)<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T17:06:37Z<p>Allquixotic: </p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming ==<br />
<br />
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!<br />
<br />
0. 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.<br />
1. What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
2. Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
3. What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
3(a). Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
3(b). Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
3(c). Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
4. What hardware and software configurations should we test on?<br />
5. What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
6. 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?<br />
<br />
<br />
= GPU OpenCL Support =<br />
<br />
Here is just a table describing the current state of GPU-accelerated OpenCL support on various platforms and hardware. I choose to arbitrarily define the following:<br />
<br />
* "Windows" as "Windows Vista SP2 or later, 32 or 64-bit";<br />
* "Mac" as "Mac OS X 10.7 or later";<br />
* "Linux Proprietary" as "Linux 2.6.32 or later on RHEL 6+, Debian 6+, Ubuntu 12.04+, Fedora 17+, OpenSUSE 12.1+, with a '''closed-source''' vendor-supplied GPU kernel module";<br />
* "Linux FOSS" as "Linux 3.10 or later on the latest stable Fedora, Ubuntu, or OpenSUSE, or Debian Testing, with an open-source, Mesa or Gallium3d graphics driver".<br />
<br />
{|class="wikitable"<br />
|-<br />
! scope="col"|Vendor<br />
! scope="col"|Minimum Hardware Generation<br />
! scope="col"|Windows<br />
! scope="col"|Mac<br />
! scope="col"|Linux Proprietary<br />
! scope="col"|Linux FOSS<br />
|-<br />
! scope="row"|AMD<br />
|Radeon HD5000 or later<br />
FirePro W600 or later<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Nvidia<br />
|GeForce 400 Series or later<br />
Quadro 400 Series or later<br />
Tesla<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: yellow;"|Experimental<br />
|-<br />
! scope="row"|Intel<br />
|"Ivy Bridge" (Core i3/i5/i7 3xxx) or later<br />
Xeon Phi?<br />
|style="background-color: lime;"|Fully Supported<br />
|style="background-color: lime;"|Fully Supported<br />
|N/A<br />
|style="background-color: yellow;"|Experimental<br />
|}</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T16:38:01Z<p>Allquixotic: </p>
<hr />
<div>{| class="wikitable"<br />
!colspan="8"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|-<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction and Problem Statement =<br />
<br />
Right now, physical object movement and collision consumes significant CPU time for OpenSimulator. There are several popular sims that have either disabled physics completely, or severely restricted its use to the bare minimum. Use cases of OpenSimulator that desire to use lots of physical objects, collide them together in interesting ways, etc. will quickly peg their CPU, which slows down the simulator FPS, introduces time dilation, and increases network latency due to the CPU being pegged. This is observable even on high-end, current-generation single processor systems (e.g. Core i7 4770K), on any platform. Even on hardware that can easily handle a large number of objects, this problem negatively impacts region "density" (how many regions you can fit on a single server). <br />
<br />
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?).<br />
<br />
{| class="wikitable"<br />
!colspan="8"|Physics Tradeoffs<br />
|-<br />
|'''Precision'''<br />
|'''# Physical Prims'''<br />
|'''Performance On Commodity Hardware'''<br />
|'''Hardware Class For Acceptable Performance'''<br />
|-<br />
!colspan="8"|'''Baseline: Yay, we have physics! ...somewhat.'''<br />
|-<br />
|Poor<br />
|Few (10s)<br />
|Excellent<br />
|Laptop, netbook, or embedded<br />
|-<br />
!colspan="8"|'''Typical (CPU-only BulletSim or ODE on desktops, single-CPU servers, etc.)'''<br />
|-<br />
|Good<br />
|Few (10s)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
|Poor<br />
|Many (hundreds or thousands)<br />
|Acceptable<br />
|Commodity desktop or small server<br />
|-<br />
!colspan="8"|'''Not currently possible for most individuals and small businesses'''<br />
|-<br />
|Good<br />
|Many (hundreds or thousands)<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
|Poor<br />
|Hundreds of thousands or millions<br />
|Poor<br />
|Large server (multi-CPU) '''OR''' GPU-accelerated<br />
|-<br />
!colspan="8"|'''Possible in the future with GPU acceleration'''<br />
|-<br />
|Extreme<br />
|Many (hundreds or thousands)<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|-<br />
|Good<br />
|Hundreds of thousands or millions<br />
|Awful<br />
|High-end GPU or multiple GPUs; impractical with non-supercomputer CPUs<br />
|}<br />
<br />
<br />
<br />
= Proposal =<br />
<br />
Since we already have a physics backend that uses [http://bulletphysics.org Bullet Physics Engine], and since Bullet upstream itself is developing a GPU-accelerated physics pipeline, "all" we have to do is to take advantage of that pipeline in our code. Successful implementations will notice reduced CPU usage, the possibility of increased region density, or the ability to remove restrictions on tenants, like, "make sure you have no more than 10 physical objects at any time" (for example).<br />
<br />
== General Observations ==<br />
<br />
* In recent years, both Intel and AMD have started shipping [http://ark.intel.com/products/65719/ desktop] and [http://ark.intel.com/products/75464 server] CPUs which contain an IGPU (Integrated Graphics Processing Unit).<br />
* The capabilities of IGPUs have been rapidly accelerating -- in fact, they have been increasing at a much higher rate than the CPU part of the chip. GPU performance is still roughly following Moore's Law, while CPU performance is leveling off in a huge way.<br />
* Many computers running OpenSimulator, whether a spare desktop in someone's home or a dedicated server in a datacenter, have either an IGPU or a DGPU (Discrete Graphics Processing Unit) which is, to a greater or lesser extent, underutilized -- meaning that the resources are available, but are sitting entirely or mostly idle.<br />
* The state of the art of graphics drivers has advanced significantly, to the point that IGPUs and DGPUs by AMD, Intel and Nvidia have available [http://www.khronos.org/opencl/ OpenCL 1.1] implementations on major platforms (Windows, Mac, and Linux). <br />
* The Bullet Physics Engine development community is gradually shifting their own focus towards improving and optimizing Bullet for GPUs, and offering more physics operations being accelerated by the GPU rather than the CPU.<br />
* While Bullet supports DirectX and CUDA to various extents (these are also APIs to access the GPU), it also supports OpenCL. OpenCL is one of, if not '''the''' only industry-standard, general-purpose GPU computing language that is available on all the platforms that OpenSimulator officially supports (Windows, Mac and Linux), and on all the major GPU vendor hardware (Intel, AMD, and Nvidia).<br />
<br />
== Conclusion ==<br />
<br />
Enabling GPU-accelerated Bullet physics via OpenCL is the obvious path forward to unlocking the next level of scalability and/or precision of physics simulations in OpenSimulator.<br />
<br />
= Scope of Work =<br />
<br />
== Brainstorming ==<br />
<br />
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!<br />
<br />
0. 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.<br />
1. What parts of Bullet are currently GPU-accelerated in the 3.x preview codebase?<br />
2. Of the parts of Bullet that are GPU-accelerated, does OpenSimulator use any of them?<br />
3. What configuration or API usage changes are required of OpenSimulator's use of Bullet in order to use the GPU-accelerated features?<br />
3(a). Can we simply enable Bullet's GPU acceleration by changing a configuration setting, or an initialization flag?<br />
3(b). Do we have to use entire new classes in the Bullet C++ API to use the GPU-accelerated features?<br />
3(c). Do we have to change our entire approach to using Bullet in the BulletSim physics backend to use the GPU-accelerated features?<br />
4. What hardware and software configurations should we test on?<br />
5. What is the minimum hardware specification that would actually yield a performance improvement over the CPU pipeline?<br />
6. 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?</div>Allquixotichttp://opensimulator.org/wiki/User:AllquixoticUser:Allquixotic2013-09-10T15:30:11Z<p>Allquixotic: </p>
<hr />
<div>== About Me ==<br />
<br />
* 27 years old<br />
* Male<br />
* From Maryland, USA<br />
* Software Engineer / Information Security Engineer<br />
* Wide array of interests spanning most software development domains<br />
* Focussed knowledge in GNU/Linux, Gstreamer, GTK+, Java, C#, and TCP/IP networking and protocols<br />
* Working in application security testing as a day job<br />
* Have worked in a software engineering company for smartphones<br />
<br />
== Contact ==<br />
<br />
* IRC (freenode): allquixotic<br />
* Email: smcnam. Oh, you were wondering what domain I'm at, too, weren't you? Well, you'd have be a pretty smart spambot to get this far! I use Google's e-mail service -- the shortened version of "googlemail".<br />
* Yahoo: Same as IRC<br />
* Google Talk/Jabber: Same as Email<br />
* Secondlife (Agni) and OSgrid: Tiyuk Quellmalz<br />
<br />
== Why? ==<br />
<br />
Why am I interested in OpenSim? Because it's very hackable, being a high-level language with automatic memory management and objects, and written in a very modular way; and because I run a bunch of sims on OSgrid that I want to help flourish. Turns out we could really use certain features to get our sims working well, so I'm willing to put in the effort.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T15:27:37Z<p>Allquixotic: </p>
<hr />
<div>{| class="wikitable"<br />
!colspan="6"|Basic Information<br />
|-<br />
|'''Proposal Name'''<br />
|BulletSim GPU Acceleration Using OpenCL<br />
|'''Date Proposed'''<br />
|September 10, 2013<br />
|-<br />
|'''Status'''<br />
|Draft<br />
|-<br />
|'''Proposer'''<br />
|[[User:Allquixotic]]<br />
|}<br />
<br />
= Introduction =<br />
<br />
A summary of what this feature is about.<br />
<br />
= Proposal =<br />
<br />
The text of the proposal.</div>Allquixotichttp://opensimulator.org/wiki/Feature_ProposalsFeature Proposals2013-09-10T15:22:08Z<p>Allquixotic: Add feature proposal for BulletSim_OpenCL</p>
<hr />
<div>==Feature Proposals==<br />
If you want to propose a feature, you should do so on the opensim-dev mailing list. If there is interest or if you plan to write the code yourself, you can create a page here. Please do not propose features in the Mantis bug tracker. Please do not propose features if you don't have a clear idea of how they would work on a technical level. Please do not propose features expecting other people to do the implementation work without convincing them first - this will not happen.<br />
<br />
Feature proposals must be created in conjunction with a post to the opensim-dev mailing list - if they are just created here then it's possible they will not get seen by other developers.<br />
<br />
If you're adding a proposal here, please do it with a page name of Feature_Proposals/<name of service>. For example Feature_Proposals/AutoBackup.<br />
<br />
=== Templates ===<br />
<br />
* [[Feature Proposal Template]] - Use this template for your document.<br />
<br />
=== Present ===<br />
<br />
* [[Feature Proposals/Dynamic Attributes in Scene Objects]]<br />
* [[Feature Proposals/Deduplicating Asset Service]]<br />
* [[Feature Proposals/Improve Groups Service]]<br />
* [[Feature Proposals/BulletSim_OpenCL]]<br />
* [[IntegrationService]]<br />
* [[RemoteAdmin:RemoteAdmin_Proposals]] - proposals for additional [[RemoteAdmin]] external methods.<br />
<br />
=== Past ===<br />
<br />
* [[Feature Proposals/Multi-Region OARs]]<br />
* [[Feature Proposals/AutoBackup|AutoBackup]]<br />
* [[Statistics Server]] - Proposal for a statistics server in OpenSimulator.<br />
* [[OpenID]] - Proposal for using OpenID in OpenSimulator<br />
* [[AssetServerProposal]] - Proposal for a distributed asset server<br />
* [[A better SimCrossing]] - A work in progress about implementing a smooth simcrossing<br />
* [[Creating profiles not used for login]] - RFC for alternative ways of creating profiles that will never be used for login<br />
* [[OpenSim Profile Anchors]] - a mechanism for retaining creator information for offline item transfers<br />
* [[Explicit Object Serialization]] - a proposal to explicitly serialize scene objects rather than using automatic .NET XML serialization<br />
* [[Opensim: 0.5 Release Target Discussion]]<br />
* [[Opensim: 0.6 Release Target Discussion]]<br />
* [[Opensim: Future Release Discussion]]<br />
* [[OpenWiredux: Taking the next step]]<br />
<br />
[[Category:Development]]<br />
[[Category:Proposal]]</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCLFeature Proposals/BulletSim OpenCL2013-09-10T15:21:33Z<p>Allquixotic: Template import</p>
<hr />
<div>=Date=<br />
<br />
Date of this proposal.<br />
<br />
= Status (draft, in progress, done or abandoned) =<br />
<br />
Status of the proposal. No set form as of yet, but could be draft/in progress/done/abandoned.<br />
<br />
= Proposers =<br />
<br />
The names of the people proposing this feature.<br />
<br />
= Introduction =<br />
<br />
A summary of what this feature is about.<br />
<br />
= Proposal =<br />
<br />
The text of the proposal.</div>Allquixotichttp://opensimulator.org/wiki/Development_TeamDevelopment Team2011-05-16T10:40:12Z<p>Allquixotic: /* Additional Developers/Testers/Contributors */</p>
<hr />
<div>__NOTOC__ {{Template:Quicklinks}} <br />
<br />
[[Technical Reference|Technical Reference]] -&gt; [[Technical Reference/terms|Terms]] -&gt; [[Development Team|Core Development Team]] <br />
<br />
== Active Core Developers ==<br />
<br />
Developers who have commit access to our central server, are [http://www.ohloh.net/projects/4753/contributors regular contributors] to the codebase, and have voting rights over development and process issues of the OpenSimulator project. See [[Organization]].<br />
<br />
* '''Only voted in developers are listed here, please do not list yourself'''<br />
<br />
{| border="1" cellpadding="2" cellspacing="0" class="sortable"<br />
|-<br />
! <br />
! IRC Nick <br />
! Name<br />
! SL Avatar<br />
! Other Grid<br />
! Time Zone<br>(UTC)<br />
! Org<br />
! Areas of Interest<br />
|-<br />
| <br />
| [[User:Adam Frisby|Adam Frisby]]<br />
| Adam Frisby<br />
| Adam Zaius<br />
| <br />
| +8<br />
| DeepThink Pty Ltd<br />
| Terrain, Performance<br />
|-<br />
|<br />
| [[User:Chi11ken|chi11ken]]<br />
| Jeff Ames<br />
| Chillken Proto<br />
| <br><br />
| +9<br />
| [http://www.genkii.com Genkii]<br />
| <br><br />
|-<br />
|<br />
| [[User:Justincc|justincc]]<br />
| Justin Clark-Casey<br />
| Lulworth Beaumont<br />
| Justin Clark-Casey (all other grids)<br />
| 0<br />
| OSVW Consulting<br>[http://justincc.org/blog justincc's OpenSim blog]<br />
| Grid, performance &amp; reliability, inventory (avatar and object), assets, scenes, OARs, etc. Generally speaking, my main interest is to create infrastructure that other people can build on top of.<br />
|-<br />
|<br />
| [[User:Dahlia|dahlia]]<br />
| T. Hoff<br />
| Dahlia Trimble<br />
| <br />
| -8 / -7<br />
| Independent<br />
| Collision geometry, various math and physics issues, occasional bug fixes and random enhancements<br />
|-<br />
|<br />
| [[User:Melanie T|Melanie_T]]<br />
| Melanie<br />
| Melanie Milland<br />
| <br><br />
| +1<br />
| Independent<br />
| Scripting, Prims/Scene, Life, The Universe, and Everything<br />
|-<br />
|<br />
| [[User:Diva|Diva]]<br />
| Crista Lopes<br />
| Diva Canto<br />
| Crista Lopes / Diva Canto<br />
| -8<br />
| University of California, Irvine<br />
| Everything, except databases<br />
|-<br />
| <br />
| jhurliman<br />
| John Hurliman<br />
| John Hurliman<br />
|<br />
| <br />
| Intel<br />
| <br />
|-<br />
| <br />
| dslake<br />
| Dan Lake<br />
| Dan Lake<br />
|<br />
| <br />
| Intel<br />
| <br />
|-<br />
|<br />
| [[User:Marck|Marck00]]<br />
| M. Kirsch<br />
| Marck Kjeller<br />
| <br />
| +1<br />
| Independent<br />
| Everything that catches my attention and that I can get my head around.<br />
|<br />
|-<br />
|<br />
| [[User:BlueWall|BlueWall]]<br />
| James Hughes<br />
| BlueWall Slade<br />
| BlueWall Slade<br />
| -5<br />
| BlueWall Information Technologies, LLC<br />
| Various parts<br />
|}<br />
<br><br />
<br />
== Core Developers Following the White Rabbit ==<br />
<br />
Core developers who have temporarily (we hope) gone chasing the white rabbit. They are in all similar to the active core developers, except that they haven't been that active lately, so their voting rights are awaiting their come back. <br />
<br />
* '''Only voted in developers are listed here, please do not list yourself'''<br />
<br />
{| border="1" cellpadding="2" cellspacing="0" class="sortable"<br />
|-<br />
!<br />
! IRC Nick <br />
! Name<br />
! SL Avatar<br />
! Other Grid<br />
! Time Zone<br>(UTC)<br />
! Org<br />
! Areas of Interest<br />
|-<br />
| <br />
| [[User:Lbsa71|lbsa71]]<br />
| Stefan Andersson<br />
| Tribal Skytower<br />
| OSG:Stefan Andersson<br>TN:Stefan Andersson<br />
| +1<br />
| [http://tribalmedia.se/ Tribal Media AB]<br />
| Web Integration<br />
|-<br />
| <br />
| [[User:MW|MW]]<br />
| Darren<br />
| Wright Juran<br />
| <br />
| 0<br />
| <br />
| Everything<br />
<br />
|-<br />
| <br />
| ckrinke<br />
| Charles&nbsp;Krinke<br />
| Charlesk&nbsp;Bing<br />
| <br />
| -8<br />
| &nbsp;<br />
| Reliability/Grid servers/ll-functions<br />
|-<br />
| <br />
| [[User:Mikem|mikem]]<br />
| Mike Mazur<br />
| <br><br />
| <br><br />
| +9<br />
| Independent<br />
| Patches, scripting improvements, LSL compiler<br />
|-<br />
|<br />
| [[User:HomerHorwitz|homerh]]<br />
| Homer Horwitz<br />
| Homer Horwitz<br />
| <br><br />
| +2<br />
| Independent<br />
| Rev. engineering, "now, that's funny" problems, but still interested in all parts of it<br />
|-<br />
|<br />
| [[User:Nlin|nlin]]<br />
| N Lin<br />
| Standard Drucker<br />
| <br><br />
| +9<br />
| [http://www.3di.jp/en/ 3Di Inc, Japan]<br>http://www.3di.jp/en/<br />
| Physics, scripting, more to come<br />
|-<br />
|<br />
| [[User:Arthursv|arthursv]]<br />
| Arthur Valadares<br />
| <br />
| NONE<br />
| -8<br />
| University of California, Irvine<br />
| Unit testing, database plugins, bug fixes, general <br />
|-<br />
|<br />
| [[User:DrScofield|drscofld]]<br />
| Dirk Husemann<br />
| Dr Scofield<br />
| <br />
| +1<br />
| [http://xyzzyxyzzy.net/ xyzzyxyzzy.net]<br />
| Reliability, networking protocols, inventory, assets, remote control, voice, and pretty much everything else&nbsp;:-)<br />
|<br />
|-<br />
|<br />
| [[User:Teravus|Teravus]]<br />
| Daniel Olivares<br />
| Teravus Ousley<br />
| <br />
| -5<br />
| W3z<br />
| Physics &amp; Admin tools, A working sim.<br />
|}<br />
<br />
== Retired Core Developers ==<br />
<br />
Core developers who have transcended our mortal plane, i.e. they are no longer directly engaged with the project. Thank you forever for your contributions!<br />
<br />
* '''Only formerly voted in developers are listed here, please do not list yourself'''<br />
<br />
{| border="1" cellpadding="2" cellspacing="0" class="sortable"<br />
|-<br />
!<br />
! IRC Nick <br />
! Name<br />
! SL Avatar<br />
! Other Grid<br />
! Time Zone<br>(UTC)<br />
! Org<br />
! Areas of Interest<br />
|-<br />
| <br />
| [[User:Babblefrog|babblefrog]]<br />
| Brian McBee<br />
| Dogen Coldstream<br />
| Babblefrog Ballistic (osgrid)<br />
| -8<br />
| Disorganized<br />
| &nbsp;<br />
|-<br />
| <br />
| [[User:Danx0r|danx0r]]<br />
| Dan Miller<br />
| Albert Pascal<br />
| <br />
| -8<br />
| squiggle.com<br />
| PHEEZIKS; everything<br />
|-<br />
| <br />
| Tleiades<br />
| &nbsp;<br />
| Tleiades&nbsp;Hax<br />
| <br />
| +1<br />
| &nbsp;<br />
| Grid servers/Database<br />
|-<br />
| <br />
| [[User:Darok|Darok]]<br />
| &nbsp;<br />
| Darok Kaminski<br />
| <br />
| +1<br />
| &nbsp;<br />
| Physics engines (especially BulletX)<br />
|-<br />
| <br />
| Gareth / Gwen<br />
| Gareth Nelson<br />
| Gareth Ellison<br />
| Gareth Nelson (on everywhere but SL)<br />
| BST (UTC+1)<br />
| Litesim Ltd<br />
| Grid servers, sim border crossing, avatar animations<br />
|-<br />
| <br />
| [[User:Dalien|dalien]]<br />
| Dalien Talbot<br />
| Dalien Talbot<br />
| <br />
| +1<br />
| Mostly TCP-based<br />
| Small fixes; rev.eng./prototyping; nightlies; git-keeper <br />
|-<br />
| <br />
| [[Alondria]]<br />
| <br />
| Alondria LeFay<br />
| Alondria LeFay (OSGrid)<br />
| -8<br />
| Independent<br />
| Implementation of LSL functions and other scripting tidbits.<br />
|-<br />
| <br />
| [[User:SeanDague|sdague]]<br />
| Sean Dague<br />
| Neas Bade<br />
| <br />
| -5<br />
| IBM<br />
| Database, Linux, Testing, Misc<br />
|-<br />
|<br />
| [[User:MingChen|MingChen]]<br />
| Mike/Michael Ortman<br />
| Ming Chen<br />
| <br />
| -6 (-5 in Summer)<br />
| DeepThink Pty Ltd<br />
| Estate/Parcel Support/Modules/Keeping things all neat and tidy.<br />
|-<br />
| <br />
| [[User:Tedd|Tedd]]<br />
| Tedd Hansen<br />
| Tedd Maa<br />
| <br />
| +1<br />
| Tedd Hansen<br />
| Programming/Scripting/Architecture<br />
|-<br />
| <br />
| [[User:Adjohn|adjohn]]<br />
| Adam Johnson<br />
| Zeuz Zenovka<br />
| <br><br />
| +9<br />
| [http://www.genkii.com Genkii]<br />
| <br><br />
|-<br />
| <br />
| [[User:Joha1|joha1]]<br />
| Johan Berntsson<br />
| Joppi Brandenburg<br />
| <br><br />
| +9<br />
| &nbsp;<br />
| Performance, packet handling/libSL<br />
|}<br />
<br />
== Additional Developers/Testers/Contributors ==<br />
<br />
These people have contributed and/or are contributing bug reports, patches, testing, and all sorts of other goodies to the project. <br> '''New comers please add yourself to bottom of the list!''' <br> <br />
<br />
{| cellspacing="0" cellpadding="2" border="1" class="sortable"<br />
|-<br />
! IRC Nick <br />
! Name <br />
! SL Avatar <br />
! Other Grid <br />
! Time Zone<br>(UTC) <br />
! Org <br />
! Areas of Interest<br />
|-<br />
| [[User:Nebadon|Nebadon]] <br />
| Michael Cerquoni <br />
| Nebadon Izumi <br />
| Nebadon Izumi <br />
| -7 Arizona <br />
| Oni Kenkon Creations <br />
| Building, Scripting, Testing<br />
|-<br />
| [[User:Jtclark48|jclark4]] <br />
| Jay Clark <br />
| Jay Clarke <br />
| <br />
| -5 <br />
| IBM <br />
| Physics, Grid Host, AI, Scripting, Testing<br />
|-<br />
| [[User:AdamStevenson|BigFootAg]] <br />
| Adam Stevenson <br />
| Adamus Petrov <br />
| <br />
| -6 <br />
| Texas A&amp;M University <br />
| AI, Skynet, Evolving Systems, Biology<br />
|-<br />
| [[User:Jeff1564|Jeff1564]] <br />
| Jeff <br />
| Potter Taurog <br />
| Potter Taurog <br />
| -8 <br />
| http://myopengrid.com <br />
| Building, Scripting, Testing<br />
|-<br />
| Rock_Vacirca <br />
| Colin Withers <br />
| Rock Vacirca <br />
| &nbsp; <br />
| +1 <br />
| http://rock-vacirca.blogspot.com <br />
| Testing, building, scripting, maintaining an opensim blog.<br />
|-<br />
| simsim <br />
| caocao <br />
| &nbsp; <br />
| &nbsp; <br />
| +9 <br />
| &nbsp; <br />
| Testing whole functions of OpenSim system,working with OpenSim-Engine,reporting on OpenSim<br />
|-<br />
| [[User:Vicero Lambert|Vicero Lambert]] <br />
| &nbsp; <br />
| &nbsp; <br />
| <br />
| &nbsp; <br />
| &nbsp; <br />
| &nbsp;<br />
|-<br />
| [[User:Magi|Magi]] <br />
| Andy Agnew <br />
| Magi Merlin <br />
| <br />
| +10 <br />
| Spun Pty Ltd <br />
| 3D Web Integration, Database stuff and playing with the odds and ends box.<br />
|-<br />
| [[User:ClarkZone|ClarkZone]] <br />
| Troy Admin(@ClarkZone) <br />
| Troy Childs <br />
| Troy Admin (ClarkZone) <br />
| -5 <br />
| Http://clarkzone.dyndns.org <br />
| Tester and Grid Host<br />
|-<br />
| [[User:Aiaustin|aiaustin]] <br />
| Ai Austin <br />
| Ai Austin <br />
| Ai Austin <br />
| +0 <br />
| AIAI, Virtual University of Edinburgh<br>http://www.aiai.ed.ac.uk/~ai/<br>http://vue.ed.ac.uk/openvue/ <br />
| Windows tests<br>Content testing<br>Use of multiple VWs<br />
|-<br />
| Marc Manders <br />
| Marc Manders <br />
| &nbsp; <br />
| &nbsp; <br />
| +6 <br />
| marcmanders@gmail.com <br />
| Creative features<br />
|-<br />
| [[User:Balthazar|balthazar]] <br />
| Trevor Brooks <br />
| Balthazar Sin <br />
| <br />
| -5 <br />
| None <br />
| Terrains, testing and some small coding tasks<br />
|-<br />
| [[User:Jimbo2120|jimbo2120]] <br />
| Michael Osias <br />
| Illuminous Beltran <br />
| <br />
| -5 <br />
| IBM <br />
| Grid, AI, Skynet, coding and testing<br />
|-<br />
| ZeroPoint <br />
| &nbsp; <br />
| Guilderoy&nbsp;Dench <br />
| <br />
| -5 <br />
| &nbsp; <br />
| Programming/Database<br />
|-<br />
| [[User:DerekTang|DerekTang]] <br />
| Derek Tang <br />
| Derek Timeless <br />
| Derek Tang (ChineseGrid) <br />
| +8 <br />
| http://ChineseGrid.net <br />
| Running a public WINDOWS sim for testing, Docs, Helping Chinese users to enjoy OpenSim; building Chinese OpenSim communities. In construction...<br />
|-<br />
| [[User:TayB|TayB]] <br />
| Earl Balai <br />
| Taylor Dae <br />
| <br />
| -10 <br />
| WhynGrid <br />
| Grid Host,Networking,Contributions &amp; Testing.<br />
|-<br />
| [[User:JamieDav|JamieDav]] <br />
| Jamie David <br />
| Jamie David <br />
| <br />
| +7 <br />
| Forum <br />
| Grid, Sim, Avitar, Functionality<br />
|-<br />
| [[User:Krtaylor|Krtaylor]] <br />
| Kurt Taylor <br />
| Kurt Stringer <br />
| <br />
| -6 <br />
| IBM <br />
| Grid, Networking, Monitoring, Scripting, Inventory, Testing<br />
|-<br />
| [[User:Nink|Nink]] <br />
| Peter Finn <br />
| Nink Noonan <br />
| <br />
| -5 <br />
| IBM <br />
| Disruptive Influence.<br />
|-<br />
| [[User:Bruce|Bruce]] <br />
| Bruce Meerson <br />
| Bruce Meerson <br />
| <br />
| +8 <br />
| HiPiHi <br />
| Watching.<br />
|-<br />
| [[User:Darb|DarbD]] <br />
| Brian B. Quinn <br />
| Darb Dabney <br />
| regions<br>near Marin <br />
| PST/SLT (-7 or -8) <br />
| County of Marin, California<br> http://blog.3dmap.me <br />
| LiDAR-based sculpties, real-world terrain, <br>pursuit of civic paraverses, virtual Emergency Operations Centers<br />
|-<br />
| [[CharlieO]] <br />
| Dan <br />
| Charlie Omega <br />
| <br />
| &nbsp; <br />
| &nbsp; <br />
| Mild coding/tweaking/simple feature adds, Stress testing/break stuff, Testing limits of existing code. Making sure [[LSL Status]] is up to date<br />
|-<br />
| oobscure <br />
| &nbsp; <br />
| Opensource Obscure <br />
| <br />
| +1 <br />
| http://www.opensim.it <br />
| Running a public Linux sim for testing, Docs, Helping italian users, Building opensim communities, Watching<br />
|-<br />
| pitman <br />
| Mike Pitman <br />
| Rez Tone <br />
| <br />
| &nbsp; <br />
| IBM <br />
| Scientific visualization schemes, virt world product design, persistant workspaces, virt world based big biz<br />
|-<br />
| Shenlei <br />
| Shenlei Winkler <br />
| Shenlei Flasheart, Shenlei Winkler <br />
| <br />
| &nbsp; <br />
| Fashion Research Institute <br />
| Product Design and Development, Apparel industry, and o yes, I wrote the book&nbsp;;)<br />
|-<br />
| cmu <br />
| Christopher Mumme <br />
| Snook Destiny <br />
| <br />
| +1 <br />
| http://www.cmu-develop.de/ and research group "Collaboration Systems and CSCW" at Clausthal University of Technology <br />
| Testing OpenSim, working with OpenSim-Engine, reporting on OpenSim<br />
|-<br />
| [[Silpol]] <br />
| Andriy Tymchenko <br />
| Andy Tir <br />
| <br />
| EET (+2/3) <br />
| http://silpol.blogspot.com/ (also visible at Nokia) <br />
| Highly uncoordinated mess with elements of palace games, under-table diplomacy, rebellion, coup d'état and mutiny. optionally pirate<br />
|-<br />
| [[User:Grumly|Grumly]] <br />
| <br />
| Forest Klaar <br />
| Grumly TheBear <br />
| GMT+1 <br />
| .NET MCAD Dev/Arch/Trainer http://www.devoteam.com <br />
| Trying to get into OpenSim code for now. Particularly interrested in data persistence. blog (Hello, Avatar!): http://lslblog.free.fr<br />
|-<br />
| [[DaTwitch]] <br />
| James G. Stallings II <br />
| <br>Lazarus Longstaff <br />
| Hiro Protagonist (OSGrid) <br />
| -5 <br />
| House Husband <br />
| OSGrid Region owner, OSGrid Operator,<br>Forum Admin, sometime wiki editor<br />
|-<br />
| gryc <br />
| Gryc Ueusp <br />
| Gryc Uriza <br />
| Gryc Uriza(OSGrid) <br />
| -6 <br />
| <br />
| PHP scripting, web interfaces, interconnectivity, cross-platformedness<br />
|-<br />
| [[User:Phrearch|Phrearch]] <br />
| Jeroen van Veen <br />
| Phrearch Miles <br />
| Phrearch Miles(OSGrid) <br />
| Amsterdam/Paris <br />
| <br />
| HWIOS, WiXTD, Wikidoc, Moo, User interfaces<br />
|-<br />
| [[User:Burnman|Burnman]] <br />
| Allen <br />
| Burnman Bedlam <br />
| <br />
| Boston, USA <br />
| <br />
| Testing, testing, and more testing! Getting familiar with the source, interested in all aspects of the project.<br />
|-<br />
| [[User:Krisbfunk|krisbfunk]] <br />
| Kris Bulman <br />
| Krisbfunk Vought <br />
| Krisbfunk Nocturnal(OSGrid) <br />
| PE, Canada (-4) <br />
| Edactive Technologies<br>NocturnalEye Productions<br>UPEI <br />
| Currently: Testing, bug reports, wiki updating, building on OSGrid<br />
|-<br />
| [[User:HashBox|HashBox]] <br />
| &nbsp; <br />
| Sibariel Darkstone <br />
| Sibariel Darkstone (OSGrid) <br />
| New Zealand (+12) <br />
| <br />
| Testing, bug reports, and updating the wiki.<br />
|-<br />
| [[User:Kinoc|Kinoc]] <br />
| Kino Coursey <br />
| Daxxon Jaxxon <br />
| Daxxon Kinoc (OSgrid) <br />
| -6 <br />
| Daxtron Laboratories <br> http://www.daxtron.com<br> University of North Texas <br />
| AI, Semantic web, Ontologies, Natural Laanguage Processing, Cyc, Bots, NPC<br />
|-<br />
| [[User:Trapuh|trapuh]] <br />
| Pedro Ribeiro <br />
| Vaiten Forder <br />
| <br />
| GMT <br />
| University Student, Escola Superior de Educação de Viseu, Portugal <br />
| Testing, eventual bug reports and wiki. Music, web/digital arts and php+sql.<br />
|-<br />
| [[User:SonicViz|SonicViz]] <br />
| Paul Cohen <br />
| Komuso Tokugawa <br />
| <br />
| +9 <br />
| Http://sonicviz.com <br />
| Audio/Music, Interactive Music, Control Protocols, Interfaces, VisualFX, Procedural animation/Generative systems + testing and general dev<br />
|-<br />
| [[User:Mokele|mokele]] <br />
| Scott Norman <br />
| Mokelembembe Mokeev <br />
| <br />
| -8 (Southern California) <br />
| Web Developer (PHP and MySQL) <br />
| Interested in seeing running on PowerPC Macs which it is. So, when I can, I'll compile and test on PowerPC Mac (PowerBook G4) and submit reports and then update the wiki if need on installing on Mac. Also have a Ubuntu 7.10 server that I can do testing on too.<br />
|-<br />
| [[User:Devalnor|devalnor]] <br />
| Devalnor <br />
| M. Watkin <br />
| <br />
| +1 (Belgium) <br />
| <br />
| Small Patch code, bug reports, and updating the wiki.<br />
|-<br />
| [[User:Ezekiel|Ezekiel]] <br />
| Ezekiel <br />
| Ezekiel Zabelin <br />
| <br />
| +1 <br />
| http://www.yosims.com <br />
| Concepts, business aspects of virtual worlds - web developer (PHP, MySQL, Javascript, LSL)<br />
|-<br />
| [[User:Buggmaster|Buggmaster]] <br />
| Mike D <br />
| Bug Master <br />
| None <br />
| -8 <br />
| http://www.adultmetaverse.com <br />
| Grid, Data/Web PHP/PERL/MySQL<br />
|-<br />
| [[User:Nixnerd|nixnerd]] <br />
| <br />
| Dangerously Moody <br />
| None <br />
| GMT <br />
| http://www.integratedtechnologies.eu <br />
| Cross Platform Testing, Feedback, Bug Reporting<br />
|-<br />
| [[User:MoHax|mohax]] <br />
| Mo Hax <br />
| Mo Hax <br />
| <br />
| -5 Eastern <br />
| IBM <br />
| Testing, Feedback, Content Contributions, Bug Reporting, Documenting, Development<br />
|-<br />
| [[User:Webmage|webmage]] <br />
| webmage <br />
| Leyla Masala <br />
| Web Mage <br />
| +1 <br />
| IBM <br />
| Testing, terrain<br />
|-<br />
| [[User:NLStitch|NLStitch]] <br />
| Marijn Oosterveld <br />
| Stitch Seale <br />
| NYA <br />
| GMT +1 Amsterdam <br />
| Twingate Systems (http://www.twingate.nl)<br>HanzeHogeschool Groningen, Netherlands <br />
| Programming, Photography, AI<br />
|-<br />
| [[User:Ideia Boa|Ideia Boa]] <br />
| Joao Lopes <br />
| Ideia Boa <br />
| Ideia Boa or Boa Ideia in some grids <br />
| GTM+1 Stockholm/Sweden <br />
| WorldSimTERRA - Virtual World that speaks Portuguese too<br>http://www.worldsimterra.com <br />
| Testing and more testing! Updating the original wiki and translating the OpenSim Wiki into Portuguese and reporting on OpenSim<br />
|-<br />
| [[User:Lulurun|lulurun]] <br />
| liu <br />
| <br> <br />
| <br> <br />
| +9 <br />
| 3Di Inc, Japan <br>http://www.3di.jp <br />
| Patches, openid, server performance, UGAI<br />
|-<br />
| [[User:Carlosroundel|Carlosrounde]] <br />
| Carlosroundel <br />
| Carlos Roundel <br />
| <br> <br />
| +1 <br />
| Cyberlandia Italy<br>http://www.cyberlandia.net <br />
| Grid, programmer, database, tester<br />
|-<br />
| [[User:Mikebert|Mikebert]] <br />
| Michael Strunck <br />
| Mikebert Miles <br />
| Mikebert M34 <br />
| +1 <br />
| OpenSIM Wiki, Germany<br>http://www.opensim.de <br />
| German Wiki, Translater, Server Performance (Linux/Windows), Tester, Feedback, Bug Reporting, Server-Hosting<br />
|-<br />
| [[User:Fly-man-|Fly-Man-]] <br />
| Laurence <br />
| <br />
| Fly Man <br />
| +1 <br />
| <br />
| Testing, OpenSimSearch, OpenSimProfile<br />
|-<br />
| Taoki <br />
| Mircea Kitsune / Taoki Vixen <br />
| Mircea Kitsune (OSGrid) / Mircea Lobo (LL grid) <br />
| <br> <br />
| GMT +2 <br />
| <br> <br />
| Usually testing and bug reporting but I also make smaller patches where I know what to do.<br />
|-<br />
| [[User:Patnad|Patnad]] <br />
| Patrick <br />
| Patnad Babii <br />
| Patnad Babii (OSGrid) <br />
| GMT -5 <br />
| RezzMe Technologies<br>http://www.rezzme.com <br />
| Bug testing and reporting, I code C# and have submitted a few patches<br />
|-<br />
| [[User:^DarkMan|^DarkMan]] <br />
| Brian Adair <br />
| Patrick Ouachita <br />
| Brian Adair &#124; Patrick Meta <br />
| -6 CST <br />
| RealMetaLife &#124; B&amp;H Networking <br />
| Building, Scripting, Testing, etc.<br />
|-<br />
| [[User:Tlaukkan|Tommi Laukkanen]] <br />
| Tommi Laukkanen <br />
| &nbsp; <br />
| Tommi Laukkanen <br />
| +2 GMT <br />
| http://www.bubblecloud.org <br />
| Protocols ([http://www.bubblecloud.org MXP]), NHibernate, Scrip API, Map Generation, Bug Fixes, Grid Hosting<br />
|-<br />
| [[User:Mystical|Mystical]] <br />
| Kevin Tweedy <br />
| Mystical Demina <br />
| Mystical Demina <br />
| -5 <br />
| Extreme Reality Grid<br>http://www.XRGrid.com <br />
| Windows Communication Framework, Windows Workflow,Entity Framework, MSSQL<br>Enhancements,Commerce, Content,DotNetNuke based portal, development services<br />
|-<br />
| [[User:Godfrey|Godfrey]] <br />
| Jeff Lee <br />
| Warin Cascabel <br />
| <br />
| -5 (EST5EDT) <br />
| <br />
| Testing, minor bugfixes. Scripting, building, animating<br />
|-<br />
| Jamenai <br />
| Christopher Händler <br />
| Jamenai Luik <br />
| Jamenai Luik <br />
| +1 <br />
| Playneko Grid &#124; XIMDEX Jamenai<br>http://www.playneko.de<br>http://www.ximdex.de <br />
| Performance,Bug Reporting, Hosting, Grid-Owner,(PHP, MySQL, Perl, JavaScript, LSL)<br />
|-<br />
| [[User:Bikcmp|bikcmp]] <br />
| Jason <br />
| Jake1500 Allen <br />
| Jason Helios (The Helios Grid) <br />
| EST <br />
| Blue Software <br />
| Search, groups, land, and currency<br />
|-<br />
| [[User:Mark.malewski|Slipaway]] <br />
| Mark Malewski <br />
| Chris Rock <br />
| <br />
| -6 (-5 during summer - CDT) <br />
| NexTECH / Joopla <br />
| Web development &amp; systems integration, terrain, WIKI documentation, tutorials, testing, bug reporting and feedback.<br />
|-<br />
| barakademi <br />
| Steve Topp <br />
| barakademi Barzane <br />
| same avi on baragrid OSgrid Grid4us sciencesim <br />
| utc+1 (CET) paris <br />
| http://xbot-sl.barakademi.org http://vps.barakademi.org/oswi http://vps.barakademi.org/oswi/loginscreen.php <br />
| Music LiveMusic MetaverseMusic Opensim Libomv Mono-2.4 Linux (suse,debian,ubuntu) Admin Scripting Automating Development Intergration php mysql bash nant +++<br />
|-<br />
| [[User:Robert d|robert_d]] <br />
| Robert Dzikowski <br />
| <br />
| OSGrid: robert_d 13 <br />
| UTC+1 <br />
| [http://blog.rd-it.net http://blog.rd-it.net] <br />
| Region Modules, Tutorials<br />
|-<br />
| [[User:Snoopy2|Snoopy2]] <br />
| Snoopy Pfeffer <br />
| Snoopy Pfeffer <br />
| Snoopy Pfeffer <br />
| <br />
| [http://www.3dmetaverse.com/ http://www.3dmetaverse.com/] <br />
| Region Hosting, Open Metaverse, 3D Web, server and viewers, service management<br />
|-<br />
| john_ <br />
| John&nbsp;Moyer <br />
| VAJohn&nbsp;GeekSquad or&nbsp;Matthew&nbsp;Kendal <br />
| <br />
| -5 <br />
| Best&nbsp;Buy/Geek&nbsp;Squad <br />
| Tester<br />
|-<br />
| [[User:W!cKeD|_WicKeD]] <br />
| Maik <br />
| Maik Galaxy <br />
| El Diablo <br />
| +1 Germany <br />
| Creatio Inc. / [http://www.OpenSimGerman.us/ OpenSimGerman.us] <br />
| German Support, Translator, Building, Scripting, Testing, Hosting<br />
|-<br />
| [[User:Stevie Wakowski|Stevie Wakowksi]] <br />
| Steve Roberts <br />
| Stevie Wakowski <br />
| <br />
| +10 Australia <br />
| IBM <br />
| OpenSim builds, Linux, Modrex, bug reporting, evangalist for OpenSim in business applications.<br />
|-<br />
| Revolution <br />
| Matthew <br />
| Revolution Smythe <br />
| Revolution Smythe <br />
| -6 Central USA <br />
| None <br />
| Script engine, physics engine, general odd bugs, interesting and odd things<br />
|-<br />
| [[User:ClemsonGS|clemsonGS]] <br />
| Brian Cass <br />
| BC Sands <br />
| Brian Cass (VWC Grid) <br />
| -5 <br />
| http://www.cvwconline.org/ <br />
| Developing virtual worlds for use in higher education<br />
|-<br />
| <br />
| AlexRa <br />
| <br />
| <br />
| <br />
| Independent <br />
| <br />
|-<br />
| <br />
| <br />
| Robert Adams <br />
| <br />
| <br />
| Looking Glass Viewer <br />
| <br />
|-<br />
| <br />
| <br />
| Mikko Pallari <br />
| <br />
| <br />
| Realxtend <br />
| <br />
|-<br />
| <br />
| StrawberryFride <br />
| Chris Hart <br />
| <br />
| <br />
| ReactionGrid <br />
| <br />
|-<br />
| [[User:RemedyTomm|RemedyTomm]] <br />
| Tom Grimshaw <br />
| Tomm Remedy <br />
| KGrid: Casper Warden OSGrid: Tomm Remedy <br />
| UTC+0 (BST) <br />
| Remedy Communications <br />
| Texture pipeline, Groups, ObjectUpdates<br />
|-<br />
| <br />
| <br />
| Rob Smart <br />
| <br />
| <br />
| IBM <br />
| <br />
|-<br />
| MicheilMerlin <br />
| Micheil Merlin <br />
| Micheil Merlin <br />
| Micheil Merlin <br />
| -6 <br />
| Independent <br> [http://www.iliveisl.com/ http://www.iliveisl.com/] <br />
| Scripting, patches, and testcases<br />
|-<br />
| Pato Donald <br />
| Pato Donald <br />
| Morgam Biedermann <br />
| Pato Donald <br />
| -3 <br />
| Independent [http://www.matheusmk3.co.cc/ http://www.matheusmk3.co.cc/ <br />
| Groups, Scripts, Physics, Communication, Integration<br />
|-<br />
| [[User:Apelles|Apelles]] <br />
| Apelles Noel <br />
| Sungo Inshan <br />
| amrssc - soon <br />
| -5 Eastern <br />
| http://amrssc.com <br />
| Developing Virtual Worlds For Use In Education - Learning - Inventor++<br />
|-<br />
| <br />
| Sera Marx <br />
| Darkfire Soulstar <br />
| <br />
| +12 <br />
| Radiance promotions <br />
| Grid Host, Commissioner. ~ Anyone looking for work related to the development of Opensimulator or Viewers please contact me. Any work undertaken for me will be returned to Opensimulator unless made strictly for my Grid<br />
|-<br />
| <br />
| Doug Osborn <br />
| <br />
| Doug Osborn @ScienceSim <br />
| PST/SLT (-7 or -8) <br />
| CTO, F.R.I. <br />
| Performance testing, scripting, high prim count builds, bots, and running in-world conferences.<br />
|-<br />
| [[User:Hallow Palmer|Hallow Palmer]] <br />
| Markus <br />
| Hallow Palmer <br />
| <br> <br />
| +1 <br />
| Grid4Us<br>http://www.grid4us.net <br />
| Server Performance (Windows), Tester, Feedback, Business concepts,Bug Reporting, Server-Hosting<br />
|-<br />
| [[User:LenaVanilli|LenaVanilli]] <br />
| Lena Vanilli <br />
| Lena Vanilli <br />
| Lena Vanilli <br />
| +1 Germany <br />
| [http://www.hypergrid.org http://www.hypergrid.org] <br />
| Grid-Management, Testing Testing Testing, Region Hosting<br />
|-<br />
| [[User:Aduffy70|aduffy70]] <br />
| Aaron Duffy <br />
| Aeran Stipe <br />
| Aaron Duffy @ScienceSim <br />
| -7 <br />
| USU <br />
| Scientific visualization &amp; education, Region modules, Heavily scripted regions<br />
|-<br />
| <br />
| Erich Bremer <br />
| Erich Bremer <br />
| <br />
Erich Bremer@OSGrid <br />
<br />
| -5 <br />
| http://www.ebremer.com <br />
| Semantic Web, Data Visualization<br />
|-<br />
| [[User:MarkIdcas|MarkIdcas]] <br />
| Mark Bannon<br />
| Mark IDCAS <br />
| 3D Grid Association, AtMeeting and IDCAS. <br />
| GMT<br />
| [http://www.atmeeting.com http://www.atmeeting.com] <br />
| Grid Management & systems integration. Scripting. WIKI documentation, tutorials, bug reporting and feedback.<br />
|-<br />
| [[User:Allquixotic|allquixotic]] <br />
| Sean McNamara<br />
| Tiyuk Quellmalz<br />
| OSG: Tiyuk Quellmalz<br />
| -5<br />
| None <br />
| Bugfixing; networking; performance; data integrity; LSL; auto-backup; null DB (eventual consistency).<br />
|}<br />
<br />
[[Category:Main]] [[Category:Development]] [[Category:Tech_Reference]] [[Category:Help]]</div>Allquixotichttp://opensimulator.org/wiki/Build_InstructionsBuild Instructions2011-05-12T11:43:35Z<p>Allquixotic: </p>
<hr />
<div>{{Template:Quicklinks}}<br />
<br />
[[Category:Users]]<br />
This page covers building OpenSim from source code on multiple platforms. Please help us keep this page up to date as the project progresses. If you just want to run OpenSimulator, [[Download]] and [[Dependencies|run]] the binary build instead. In the most cases, you should be fine with binaries.<br />
<br />
==Download OpenSim ==<br />
<br />
Check out the [[Download]] page for instructions on obtaining an OpenSim source release.<br />
<br />
==General Notes==<br />
<br />
Although this page is long, building is generally quite simple. See the BUILDING.txt file in the distribution itself for simplified instructions. This page discusses what you need to do before actual building. <br />
<br />
===Setting Files===<br />
<br />
Unlike binary distributions, OpenSimulator source distributions are delivered without default configuration files, i.e, '''OpenSim.ini''' and '''StandaloneCommon.ini'''. Therefore you'll need to create them by yourself. Look carefully at [[Configuration]] page not to suffer from the errors like ''"APPLICATION EXCEPTION DETECTED: System.UnhandledExceptionEventArgs Exception: System.Exception: Configuration file is missing the [SimulationDataStore] section"''(= missing "OpenSim.ini") or ''"Error loading plugin from OpenSim.Services.FriendsService.dll, exception System.Exception: No StorageProvider configured"''(= missing "*Common.ini").<br />
<br />
===Crash Course on Linux===<br />
<br />
The easiest platform to get running on the Linux side is Ubuntu 32bit. This is what most of the developers running Linux use. If you are looking for the quick path, start [[#Ubuntu|there]].<br />
<br />
'''Many distros (including Ubuntu) ship with only the "mono-runtime" package installed, however you need to install "mono-complete" for some OpenSimulator features such as LSL script commands.'''<br />
<br />
== MS Windows ==<br />
<br />
OpenSim requires either the [http://msdn.microsoft.com/en-us/netframework/cc378097 .Net Framework version 3.5], or [http://www.go-mono.com/mono-downloads/download.html Mono 2.4.3 or newer]. <br />
<br />
=== Supported Compilers === <br />
* Visual Studio 2010<br />
* Visual Studio 2008<br />
:Any editions should work fine, including free [http://www.microsoft.com/express/downloads/ Microsoft Visual C# Express Edition]. Note that OpenSimulator is written in C#, not C++.<br />
:Note that Visual Studio 2005 or earlier are no longer supported([http://www.mail-archive.com/opensim-dev@lists.berlios.de/msg02674.html opensim-dev proposal], [http://www.mail-archive.com/opensim-dev@lists.berlios.de/msg02673.html opensim-dev approved]).<br />
*[http://www.go-mono.com/mono-downloads/download.html Mono for Windows]<br />
<br />
=== Compiling in IDE ===<br />
# Run "runprebuild.bat"(if 2008) or "runprebuild2010.bat"(if 2010).<br />
# Open the resulting "OpenSim.sln" in any Visual Studio IDE.<br />
# Build -> Build Solution.<br />
<br />
=== Compiling in Command Prompt ===<br />
# Run "runprebuild.bat".<br />
# Run the resulting "compile.bat" file or run "nant". This will build the executable using MSBuild(the former) or nant(the latter).<br />
<br />
=== Additional Notes===<br />
<br />
* It is possible to develop on Windows Vista 64 bits with the following tweaks: <br />
#Select OpenSim project properties from solution and choose platform to be x86. Rebuild solution. <br />
#Select OpenSim.exe properties under solution bin folder and choose windows xp sp 2 compatibility mode + run as administrator.<br />
<br />
*For those that use a Cygwin shell, you may need to fix DLLs permissions issue by typing "<tt>chmod 755 *.dll *.exe</tt>" in the <tt>bin</tt> directory.<br />
<br />
== Mac OS X ==<br />
<br />
=== Mac OS X 10.5 and later, Intel ===<br />
<br />
Only you have to do is to get :<br />
* Mono SDK from [http://www.go-mono.com/mono-downloads/download.html Mono Download Page]<br />
* MonoDevelop package from [http://monodevelop.com/Download MonoDevelop Download Page] <br />
and then install them - now no need to install XCode nor MacPort (you can still install mono dev libraries and nant with MacPort though).<br />
<br />
When you run nano to build OpenSimulator, it may show an error like "Unable to locate 'mono' module using pkg-config. Download the Mono <br />
development packages". I suspect XCode or MacPort causes something wrong (since it worked fine after I removed both), but I'm not sure. Anyway, insert a line into '''/usr/bin/nant''' script file to manage this problem :<br />
<pre><br />
#!/bin/sh<br />
export PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Libraries/pkgconfig # add this!<br />
exec /Library/Frameworks/Mono.framework/Versions/2.10.2/bin/mono \<br />
/Library/Frameworks/Mono.framework/Versions/2.10.2/share/NAnt/bin/NAnt.exe "$@"<br />
</pre><br />
<br />
You can even compile and debug OpenSimulator with MonoDevelop IDE after running "runprebuild.sh". Open the solution file(*.sln) with MonoDevelop IDE then select Build -> Build All from the menu.<br />
<br />
=== Mac OS X 10.4/10.5 on PowerPC ===<br />
OpenSim can run on PowerPC Macs (such as G4, G5). These instructions were tested on 10.5.8. Note that two libraries must also be built from source. Caveat: the OpenSim app was only briefly tested in self-contained mode. There may well be issues with this build. Feel free to note any issues you find below (or in a new wiki page? discussion?). <br />
<br />
Unfortunately, the OpenSim version used here must be compiled on one version of Mono (2.6.7) and run on another (2.8.2). This means either upgrading Mono after the build, or having both versions installed and accessing the older version when you want to build. These instructions let you have both versions installed.<br />
<br />
* Install Xcode 3.1.4 Developer Tools from from http://developer.apple.com/. You must have a free Apple developer account to access the downloads. 3.1.4 was the last PowerPC Xcode.<br />
<br />
* (10.4 only) Install X11 from the Optional Install (or see if it's a Customize option when you install Xcode). 10.5 gets X11 by default (''from OS X or dev tools?'').<br />
* Install Mono 2.6.7 PowerPC Framework from here: http://www.go-mono.com/mono-downloads/download.html (binary OS X Framework, no need to build from source)<br />
* Then install Mono 2.8.2 PowerPC framework. For these instructions to work, you must first install 2.6.7, THEN 2.8.2. (The old framework is not deleted, but "Current" symlinks are updated).<br />
* Download OpenSim 0.7.0.2 source tarball: http://dist.opensimulator.org/opensim-0.7.0.2-source.tar.gz Expand to a suitable folder for development and running.<br />
** Feel free to try a newer version of OpenSim (the repository is on git now).<br />
** If you used a newer OpenSim version, check BUILDING.txt for any changes to build instructions (we fall under "Linux")<br />
* Edit or create .profile or .bash_profile in your OS X home folder, with the following lines:<br />
# remember real PATH<br />
export OSIM_HACK_ORIG_PATH=$PATH<br />
<br />
# normal path for running OpenSim<br />
export PATH=$PATH:/Library/Frameworks/Mono.framework/Versions/Current/bin:/usr/local/mysql/bin<br />
<br />
# Just for nant:<br />
export PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Versions/2.6.7/lib/pkgconfig<br />
alias oldpath="export PATH=$OSIM_HACK_ORIG_PATH:/Library/Frameworks/Mono.framework/Versions/2.6.7/bin"<br />
<br />
* Open a new Terminal window, and cd to your uncompressed OpenSim source folder (shortcut: type "cd " then drag the folder to the Terminal window). The enter these commands:<br />
oldpath<br />
./runprebuild.sh<br />
nant<br />
<br />
* nant should take around 10 minutes to compile your OpenSim. If you get through that without errors, you're halfway there! (I did get 234 warnings).<br />
* *Important* Before we forget, open a new Terminal window (necessary to avoid the effects of "oldpath").<br />
* Now we need PowerPC versions of two libraries. Build each one and replace the compiled .dylib files in the opensim/bin folder. <br />
** libode.dylib http://cdnetworks-us-1.dl.sourceforge.net/project/opende/ODE/0.11.1/ode-0.11.1.zip<br />
** libopenjpeg-dotnet-2.1.3.0-dotnet-1.dylib (checked out with svn:)<br />
svn co http://libopenmetaverse.googlecode.com/svn/libopenmetaverse/trunk/openjpeg-dotnet libopenmetaverse-read-only<br />
cd libopenmetaverse-read-only<br />
** To build, remove the Makefile file, which is for Linux, and rename Makefile.osx to just Makefile, then give the command: make )<br />
** Remove the other versions of the two libraries (similar names, different extensions, like "libode-x86_64.so". Two libode's and three libopenjpeg's).<br />
* Configure your sim: Copy OpenSim.ini.example to OpenSim.ini and customize it per its comments.<br />
* Likewise copy and customize StandaloneCommon.ini in bin/config-include<br />
* Note that the comments say that the current SQLite plugin doesn't work on OS X. Either solve that, or install MySQL, which requires no compiling and is relatively easy to set up:<br />
** From http://downloads.mysql.com/archives.php?p=mysql-5.1&v=5.1.40, download MySQL 5.1.40 for 10.5 PowerPC (installer, not 64-bit) <br />
** Run the installer. (which installs to /usr/local)<br />
** Install MySQL.prefPane into System Preferences by double-clicking it.<br />
** Open the pref pane and start MySQL.<br />
** (Optional:) For unattended startup, install MySQLStartupItem (doesn't always work for me).<br />
** (Recommended:) In Terminal, do the one-time setup of MySQL with this command: mysql_secure_installation<br />
** In MySQL, create the opensim user per the comments in OpenSim.ini. Give it all the create privileges.<br />
*** Since this is a Mac, you could use Sequel Pro (donationware) to do that in a nice GUI. Standard connection, host: 127.0.0.1 (if on the same Mac)<br />
* You're ready to run OpenSim. In that new Terminal window, cd to your OpenSim-source/bin folder.<br />
mono OpenSim.exe<br />
* If all is well, you will be prompted "New region name []: "<br />
* Turn to "Running OpenSim for the first time" on wiki page [[Configuration]]<br />
* When fully up and running, the prompt is "Region (<region-name>) #"<br />
<br />
== Ubuntu ==<br />
<br />
For Ubuntu users on older distributions (7.10, 8.04, 9.10 etc.) '''you need''' to upgrade your version of mono to at least 2.4.3. For anyone who needs to upgrade their Mono, see [[Update Mono on Ubuntu]].<br />
<br />
Ubuntu Karmic (9.10) includes mono 2.4.2.3 packages.<br />
<br />
Ubuntu Lucid (10.04) includes mono 2.4.4 packages.<br />
<br />
Ubuntu Maverick (10.10) includes mono 2.6.7 packages.<br />
<br />
Ubuntu Natty (11.04) includes mono 2.6.7 packages.<br />
<br />
=== Ubuntu 10.04 and later ===<br />
<br />
In this version, one only needs to install mono-complete - this will pull down all the other required packages as dependencies. Thus, to build:<br />
<br />
sudo apt-get install mono-complete<br />
[[Download]] opensim (if you want to build a version from git, also install the '''git-core''' package by adding it to the apt-get install command above.)<br />
cd opensim<br />
./runprebuild.sh<br />
xbuild<br />
<br />
'''OPTIONAL (for developers):''' To run the regression test suite, you will also need to install nunit-console, like so<br />
<br />
sudo apt-get install nunit-console<br />
nant test<br />
<br />
{{anchor|CentOS}}{{anchor|RedHat}}{{anchor|RHEL}}{{anchor|Fedora}}<br />
== RHEL, Fedora, CentOS or other RedHats ==<br />
<br />
After getting run your OpenSimulator binary distributions, you'll need to get mono development library and install nant to build OpenSimulator from the source. See both sections below.<br />
<br />
=== Getting Mono Libraries ===<br />
<br />
If you have installed mono packages from the core repository for your distributions [[Dependencies#RedHat|when you run OpenSim.exe binary distribusion]], just type:<br />
<pre><br />
sudo yum install mono-devel<br />
</pre><br />
<br />
If not, just type (given that [[Dependencies#Installing from Mono Repository|you have already set up yum repository for mono]]) :<br />
<pre><br />
sudo yum install mono-addon-devel<br />
</pre><br />
<br />
Both command will install its dependencies as well.<br />
<br />
=== Installing NAnt ===<br />
<br />
Run "yum info nant" to check the version of nant package. If you find the package, then just type:<br />
<pre><br />
sudo yum install nant<br />
</pre><br />
You can now run nant out-of-the-box.<br />
<br />
<br />
If you can't find nant package in yum repository, or you feel its version is too early for building OpenSimulator, obtain NAnt from [http://nant.sourceforge.net/ NAnt Project Site]. See User Manual there for detailed instruction. As of 0.90, you will need to create startup script like that (given you have expanded NAnt to /usr/local/nant) :<br />
<pre><br />
sudo vi /usr/bin/nant<br />
</pre><br />
Then inside this file :<br />
<pre><br />
#!/bin/sh<br />
exec mono /usr/local/nant/bin/NAnt.exe "$@"<br />
</pre><br />
After that, make it executable :<br />
<pre><br />
sudo chmod +x /usr/bin/nant<br />
</pre><br />
<br />
You can now run runprebuild.sh and nant to compile OpenSimulator.<br />
<br />
== openSUSE ==<br />
<br />
Install an openSUSE 11.1, 11 or 10.3 with its default options, add the online repositories<br />
when finished installing do an online update with all the latest packages.<br />
<br />
In yast install these packages, for running Opensim in standalone mode.<br />
(there is a slight diffrence between 10.3 and 11/11.1 but following should be same)<br />
subversion<br />
nant<br />
mono-jscript<br />
- check that mono-core is installed<br />
<br />
just in case you do not already have it installed <br />
<br />
sudo zypper install mono-data-oracle<br />
<br />
A tip for OpenSuSE 11.1 users - you can install packages from the command line using the 'zypper' tool. For example, to install 'nant', use this command:<br />
<br />
sudo zypper install nant<br />
<br />
If you just want to use SQLite then jump to last section <br />
within this post.<br />
<br />
* Optional mysql - for Opensim running in Grid mode:<br />
Install these mysql packages via yast<br />
mysql<br />
mysql-client<br />
mysql-administrator<br />
mysql-gui-tools<br />
mysql-query-browser<br />
<br />
(note that selecting mysql in the Yast2 Installer will select the other packages automatically)<br />
<br />
Before building create the mysql database.<br />
/etc/init.d/mysql start<br />
mysql -u root -p -h localhost<br />
(when asked for password just hit enter)<br />
<br />
mysql> create database opensim;<br />
mysql> use opensim;<br />
mysql> create user 'opensim'@'localhost' identified by 'thePassword';<br />
mysql> grant all on *.* to 'opensim'@'localhost';<br />
mysql> quit<br />
<br />
*note that the '''grant all''' command may differ if you're adding the opensim database to an existing mysql installation.<br />
<br />
On current builds set the connection string inside bin/OpenSim.ini after coppying the OpenSim.ini.example file.<br />
If you are changing to MySQL from SQLite, the connection string for mysql also exists in the bin/Region/*xml files.<br />
* It is '''important''' to remember this if you start out using the built-in SQLite database engine.<br />
<br />
Build after installation of above in bash terminal. I save it in /opt<br />
<br />
su -<br />
cd /opt<br />
[[Download]] opensim<br />
cd opensim<br />
./runprebuild.sh<br />
nant<br />
<br />
Or, if you have a current (0.6+), you can simply execute:<br />
<br />
make<br />
<br />
After this you should be able to continue on starting the diffrent Servers, look in the mysql-config section,or<br />
just run your OpenSim as a Standalone.<br />
<br />
== FreeBSD ==<br />
<br />
On FreeBSD 6.2,<br />
<br />
su<br />
cd /usr/ports/devel/subversion/ && make install clean (you may also need to rebuild apr-svn if this step fails)<br />
cd /usr/ports/lang/mono/ && make install clean<br />
cd /usr/ports/devel/nant/ && make install clean<br />
cd /usr/ports/databases/sqlite3/ && make install clean<br />
cd /usr/ports/x11-toolkits/libgdiplus/ && make install clean<br />
cd /opensim/installation/directory/<br />
[[Download]] opensim<br />
cd opensim<br />
./runprebuild.sh<br />
nant<br />
<br />
Note: [[Troubleshooting#System.DllNotFoundException:_..2Flibopenjpeg-libsl-2.1.2.0.so|Follow the instructions on the FAQ to fix the]]<br />
"System.DllNotFoundException: ./libopenjpeg-libsl-2.1.2.0.so" issue, but use "gmake" instead of "make"<br />
<br />
For ODE Physics you must do the following:<br />
cd /usr/ports/graphics/libGL/ && make install clean<br />
cd /usr/ports/graphics/libGLU/ && make install clean<br />
cd /opensim/installation/directory/<br />
svn co http://opensimulator.org/svn/opensim-libs/trunk opensim-libs<br />
cd opensim-libs/unmanaged/OpenDynamicsEngine2/<br />
sh autogen.sh<br />
./configure --enable-shared --enable-release --disable-demos<br />
make<br />
mv ./ode/src/.libs/libode.so /opensim/installation/directory/opensim/bin/<br />
<br />
== Debian ==<br />
<br />
=== Debian 4 ===<br />
<br />
For detailed instructions please see [[Debian 4 Build Instructions]]<br />
<br />
=== Debian 5 ===<br />
<br />
1. Install Debian in the usual way. In the package list choose just the last option - 'Standard system' Leave all other install options unchecked unless you have other reason to install them.<br />
<br />
2. Log in as your root user make sure it works.<br />
<br />
3. type: aptitude update (or apt-get update)<br />
<br />
4. type: aptitude install nant and answer 'y' to 'Do you want to continue'- This will install nant and all of its dependancies.<br />
<br />
5. type: apt-get install git-core and answer 'y' to 'Do you want to continue'.<br />
<br />
6. type: aptitude install build-essential swig autoconf gawk mono-common binfmt-support bison libglib2.0-dev gettext and answer 'y' to 'Do you want to continue'<br />
<br />
7. type: wget http://ftp.novell.com/pub/mono/sources/mono/mono-2.4.3.tar.bz2 to download mono<br />
<br />
8. type: tar xf mono-2.4.3.tar.bz2 to extract the mono source code to a directory (substitute the latest build)<br />
<br />
9. type: cd mono-2.4.3 to change int the directory you just created<br />
<br />
10. type: ./configure --with-libgdiplus=yes - wait for it to finish<br />
<br />
11. type: make - and wait some more as this takes a bit - moreso on older machines<br />
<br />
12. type: make install<br />
<br />
13. type: cd /<br />
<br />
14 type: git clone git://opensimulator.org/git/opensim<br />
<br />
15 type: cd opensim<br />
<br />
16. type: git checkout -b 0.6.8-post-fixes origin/0.6.8-post-fixes (substitute the latest build)<br />
<br />
17. type: git pull<br />
<br />
18. type: apt-get -u upgrade and answer 'y' to 'do you want to continue?'. This will update all packages to their latest versions via apt (it will not upgrade opensim or mono as they were compiled seperately)<br />
<br />
19. Reboot, just to make sure it all comes up cleanly (type: shutdown -r now)<br />
<br />
20. Login, type: cd /<br />
<br />
21. type: cd opensim<br />
<br />
22. type: ./runprebuild.sh<br />
<br />
23 type: nant - wait for this to finish<br />
<br />
24. type: cd bin<br />
<br />
25. type: cp OpenSim.ini.example OpenSim.ini<br />
<br />
26. type: mono OpenSim.exe<br />
<br />
27. Answer the onscreen wizard promts and Opensim will start in standalone mode.<br />
<br />
To add MySql support type: apt-get install mysql-server and answer 'y' to 'Do you want to Continue'. You will be prompted for a password for the MySQL root user, enter it twice as requested. Edit OpenSim.ini to use MySql as directed elsewhere.<br />
<br />
=== Debian testing/unstable (will be Debian 7) ===<br />
<br />
Updated 2011 April 19 <br />
<br />
#Get root access on a Debian/Linux machine or install a fresh copy yourself. see http://www.debian.org/ This is the most difficult and longest step in our list, but there are many resources to help you through if this is your first time. <br />
#Log in as your root user. <br />
#Check <tt>/etc/debian_version</tt> to be sure of what release you are working with, by typing: `<tt>cat /etc/debian_version</tt>'. As of this writing it should reply "<tt>wheezy/sid</tt>". <br />
#type: `<tt>apt-get update</tt>' <br />
#type: `<tt>apt-get dist-upgrade</tt>' This will upgrade all packages to their latest versions and will handle conflicts which may arise. See: `<tt>man apt-get</tt>' for more information. If you did not install from scratch this will bring the system up to date. For more information about running and maintaining a Debian system enter: `<tt>apt-get install debian-reference</tt>' and point a web browser at <tt>/usr/share/doc/debian-reference-common/html/index.en.html</tt> This is a book length document (read it later). <br />
#type: `<tt>apt-get install mono-complete nant git build-essential swig autoconf gawk binfmt-support bison gettext</tt>' and answer 'y' to 'Do you want to continue'. <br />
#Reboot, just to make sure it all comes up cleanly (type: `<tt>shutdown -r now</tt>') <br />
#Login again, type: `<tt>cd /usr/src</tt>' <br />
#type: `<tt>git clone git://opensimulator.org/git/opensim</tt>' <br />
#type: `<tt>cd opensim</tt>' <br />
#type: `<tt>git branch -r</tt>' will show you the available branches in the remote repository. You want the most recent release which will be listed as something like "<tt>origin/0.7.0.2-release</tt>" <br />
#type: `<tt>git checkout -b 0.7.0.2-release origin/0.7.0.2-release</tt>' <br />
#type: `<tt>git pull</tt>' <br />
#type: `<tt>./runprebuild.sh</tt>' <br />
#type: `<tt>nant</tt>' <br />
#type: `<tt>cd bin</tt>' to switch directories to <tt>/usr/src/opensim/bin</tt> <br />
#type: `<tt>cp OpenSim.ini.example OpenSim.ini</tt>' (The <tt>[Architecture]</tt> section is what determines if you will be running a standalone or grid server. You want the default standalone variant to get started with.) <br />
#type: `<tt>cd config-include</tt>' you are now in <tt>/usr/src/opensim/bin/config-include</tt> <br />
#type: `<tt>cp StandaloneCommon.ini.example StandaloneCommon.ini</tt>' See [[Configuration]] for more information on configuring OpenSim. <br />
#type: `<tt>cd ..</tt>' to change directories back to <tt>/usr/src/opensim/bin</tt> <br />
#type: `<tt>mono OpenSim.exe</tt>' <br />
#The startup wizard will ask you a number of questions. The defaults are fine but you can fill these in to your taste:<br />
<br />
region name, estate name, owner first name, owner last name, owner password, and owner email <br />
<br />
Remember the external host name and port number, you need these to construct the login URI to connect to with your client. http://hostname:portnumber/ <br />
<br />
Opensim will then finish starting and leave you at a prompt which looks like: <br />
<br />
Region (regionName) #<br />
<br />
----<br />
<br />
Where to go from here: <br />
<br />
*[[Connecting]] to your server using a client.<br />
<br />
*[[Upgrading]] to mySQL from mySQLite.<br />
<br />
*[[Server Commands]] for creating users and controlling the system.<br />
<br />
*Fix the bent knees bug: [[FAQ#Why_are_my_knees_bent_when_I_stand_idle.3F]]<br />
<br />
<br />
[[Category:Users]]<br />
[[Category:Getting Started]]</div>Allquixotichttp://opensimulator.org/wiki/DependenciesDependencies2011-05-12T11:33:38Z<p>Allquixotic: </p>
<hr />
<div>{{Template:Quicklinks}}<br />
<br />
In addition to the OpenSim code itself, certain other packages need to be installed on different platforms in order to get OpenSim binaries to run. <br />
<br />
As well as the information on this page (which should be expanded), you may find more information on dependencies in [[Build Instructions]] though this will also contain dependencies required only for building. This are also more hints in [[Troubleshooting]] <br />
<br />
<br />
= Windows =<br />
<br />
OpenSim now requires '''.NET Framework 3.5''' when running under Windows. If you run OpenSimulator on '''Windows 7''' or '''Windows Server 2008 R2''', it is already bundled so you can run OpenSim 0.7.1 out-of-the-box. On '''Windows Vista''', '''Windows Server 2008''', '''Windows Server 2003''' or '''Windows XP''', you'll need to upgrade it to 3.5(or later, but NET Framework 4.0 not officially supported by OpenSim yet), downloading from [http://msdn.microsoft.com/en-us/netframework/cc378097 Microsoft .NET Framework Download Page@.NET Framework Developer Center]. Note that prior versions of Windows(ex. NT or 2000) are NOT supported.<br />
<br />
If you run on Windows XP ensure it is updated to at least Service Pack 2 (SP2). <br />
<br />
Double-click or execute on command prompt:<br />
*32-bit version of Windows: '''OpenSim.exe'''<br />
*64-bit version of Windows: '''OpenSim.32BitLaunch.exe'''<br />
Depending on your installation, you may have to run the program as administrator(right click -> 'Run as administrator'). It will pop up a window asking permission, select "Allow".<br />
<br />
<br />
= Linux =<br />
<br />
OpenSimulator requires Mono 2.4.3 or later. '''WARNING:''' OpenSim is known to have significant performance and scalability problems with Mono versions 2.8.x, 2.10.0 and 2.10.1. As of Mono 2.10.2, the scalability problems appear to have been resolved. Therefore you should either use Mono 2.6.x or Mono 2.10.2 or later. You can also use Mono 2.4.3, but it is fairly old now.<br />
<br />
== Ubuntu ==<br />
<br />
sudo apt-get install mono-complete git-core<br />
<br />
'''xbuild''' or '''nant''' is required if you need to build OpenSim. As of mono 2.6 series, xbuild works well enough to drive a complete build of OpenSim. Since xbuild is included within the '''mono-complete''' package on Ubuntu, you don't have to install any additional packages if you don't have any particular reason to prefer nant over xbuild. They are just two different build systems that invoke the same C# compiler based on two different build script formats.<br />
<br />
'''git''' is required if you need to check out OpenSimulator from source code. The '''git-core''' package provides this on Ubuntu.<br />
<br />
<br />
{{anchor|CentOS}}{{anchor|RedHat}}{{anchor|RHEL}}{{anchor|Fedora}}<br />
== RHEL, Fedora, CentOS or Any Other RedHat-based Distributions ==<br />
<br />
First, run "yum info mono-core" to see the version of the mono packages in the core repository for your distribution. If it shows '''2.4.3''' or later, proceed to [[#Installing from Core Repository]]. If not, skip to [[#Installing from Mono Repository]]. Note that the current version you can get from yum repository for some distributions is lower than requirement (ex. '''1.2.4''' on CentOS). Unlike Ubuntu, RedHat-based distributions should be always conservative, therefore it is natural that they don't so often update their repository. What you can do to manage this problem is to add an extra repository for mono.<br />
<br />
=== Installing from Core Repository ===<br />
<br />
Just type:<br />
<pre><br />
sudo yum install mono-core mono-data-sqlite mono-extras libgdiplus<br />
</pre><br />
It will also install dependent modules. After that you can launch OpenSim.exe with mono out-of-the-box.<br />
<br />
=== Installing from Mono Repository ===<br />
<br />
This procedure is tested on CentOS 5.5 & 5.6 box with OpenSim 0.7.1.<br />
<br />
Go to yum config file folder and create new one for mono.<br />
<pre><br />
cd /etc/yum.repos.d<br />
sudo vi mono.repo<br />
</pre><br />
<br />
And then in mono.repo :<br />
<pre><br />
[mono]<br />
name = novell-mono<br />
baseurl=http://ftp.novell.com/pub/mono/download-stable/RHEL_5/<br />
enabled=1<br />
gpgcheck=0<br />
</pre><br />
<br />
Now, you can yum install the later version of mono from this repository. Additional note that make sure all of mono packages are i386(not IA64 build). If your box is 32bit, don't care and you can even install properly without ".i386" suffix.<br />
<pre><br />
sudo yum install mono-addon-core.i386 mono-addon-data.i386 mono-addon-data-sqlite.i386 \<br />
mono-addon-extras.i386 mono-addon-web.i386 mono-addon-winforms.i386 mono-addon-libgdiplus0.i386<br />
</pre><br />
<br />
Yum will install mono into /opt/novell/mono, so you can create a symbolic link to /usr/bin :<br />
<pre><br />
sudo ln -s /opt/novell/mono/bin/mono /usr/bin/mono<br />
</pre><br />
<br />
After that, you should be able to launch OpenSim.exe without any errors.<br />
<br />
<br />
= Mac OS X =<br />
<br />
All you have to do is to fetch Mono '''Runtime''' package from [http://www.go-mono.com/mono-downloads/download.html Mono Download Page] and install it.<br />
<br />
<br />
= Locales and Regional Settings =<br />
OpenSimulator will only work properly when you run it with an English locale or regional setting. With other settings than English, you are likely to see a variety of issues, ranging from misbehaving scripts to crashes.<br />
<br />
== Linux ==<br />
In Linux, you can easily use the standard "C" locale just for running OpenSim.exe, as explained in [[Troubleshooting#ScriptEngine Issues]]:<br />
<pre><br />
env LANG=C mono OpenSim.exe<br />
</pre><br />
<br />
For information about changing your locale in a more general way, see [[Troubleshooting#Locales Issues]]<br />
<br />
== Windows ==<br />
If you are not using an English regional setting in Windows by default, then there is not a solution as easy as for Linux, unfortunately. I did it with an additional user account that I created just for OpenSim in which I set the regional setting to "English (US)". I run OpenSim.exe from my normal user account with "Run as..." (or check "Run with different credentials" in a shortcut's advanced properties) and specify the OpenSim account as the one to be used.<br />
<br />
<br />
= Additional Resources =<br />
<br />
OSGrid Technical Support Forum with many installation tutorials:&nbsp; [http://osgrid.org/forums/viewforum.php?f=14 osgrid.org/forums/viewforum.php] <br />
<br />
MONO&nbsp;Project:&nbsp; [http://www.mono-project.com/Main_Page www.mono-project.com/Main_Page]</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-05-12T04:08:35Z<p>Allquixotic: /* Basic Info */</p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic], [http://opensimulator.org/wiki/User:Justincc justincc]<br />
* '''Start Date''': February 18, 2011<br />
* '''Status''': Committed to git master as of May 12, 2011<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': Maintained in OpenSim git master<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': Only the OpenSimDefaults.ini has to be modified to add the disable by default setting, outside of the AutoBackupModule code itself.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Global (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
** AutoBackupModuleEnabled: '''True/False'''. Default: False. If False, every function in the module is as no-op as possible: just return as soon as realizing that we're not enabled. Otherwise it will try to get as far as it can with auto backup for each region.<br />
* Global (in '''OpenSim.ini''') '''or''' Per-Region (in '''Regions/Regions.ini''' under the region's name's section)<br />
* '''IMPORTANT:''' Settings declared per-region in Regions/Regions.ini override settings in OpenSim.ini. Settings in OpenSim.ini, in turn, override hard-coded defaults.<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupNaming: string. Default: Time.<br />
*** One of three strings (case insensitive):<br />
*** "Time": Current timestamp is appended to file name. An existing file will never be overwritten.<br />
*** "Sequential": A number is appended to the file name. So if RegionName_x.oar exists, we'll save to RegionName_{x+1}.oar next. An existing file will never be overwritten.<br />
*** "Overwrite": Always save to file named "RegionName.oar", even if we have to overwrite an existing file.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
** AutoBackupDilationThreshold: float. Default: 0.5. Lower bound on time dilation required for BusyCheck heuristics to pass.<br />
*** If the time dilation is below this value, don't take a backup right now.<br />
** AutoBackupAgentThreshold: int. Default: 10. Upper bound on # of agents in region required for BusyCheck heuristics to pass.<br />
*** If the number of agents is greater than this value, don't take a backup right now.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
'''Implementation note''': As of May 2, we don't halve the interval each time we PROCRASTINATE. Not sure if we need to worry about this.<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-05-02T08:24:05Z<p>Allquixotic: /* Configuration Settings */ -- Another bump to the settings layout of AutoBackup. See http://opensimulator.org/mantis/view.php?id=5440</p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic], [http://opensimulator.org/wiki/User:Justincc justincc]<br />
* '''Start Date''': February 18, 2011<br />
* '''Status''': Active development as of May 2, 2011 (Beta)<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': Only the OpenSimDefaults.ini has to be modified to add the disable by default setting, outside of the AutoBackupModule code itself.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Global (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
** AutoBackupModuleEnabled: '''True/False'''. Default: False. If False, every function in the module is as no-op as possible: just return as soon as realizing that we're not enabled. Otherwise it will try to get as far as it can with auto backup for each region.<br />
* Global (in '''OpenSim.ini''') '''or''' Per-Region (in '''Regions/Regions.ini''' under the region's name's section)<br />
* '''IMPORTANT:''' Settings declared per-region in Regions/Regions.ini override settings in OpenSim.ini. Settings in OpenSim.ini, in turn, override hard-coded defaults.<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupNaming: string. Default: Time.<br />
*** One of three strings (case insensitive):<br />
*** "Time": Current timestamp is appended to file name. An existing file will never be overwritten.<br />
*** "Sequential": A number is appended to the file name. So if RegionName_x.oar exists, we'll save to RegionName_{x+1}.oar next. An existing file will never be overwritten.<br />
*** "Overwrite": Always save to file named "RegionName.oar", even if we have to overwrite an existing file.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
** AutoBackupDilationThreshold: float. Default: 0.5. Lower bound on time dilation required for BusyCheck heuristics to pass.<br />
*** If the time dilation is below this value, don't take a backup right now.<br />
** AutoBackupAgentThreshold: int. Default: 10. Upper bound on # of agents in region required for BusyCheck heuristics to pass.<br />
*** If the number of agents is greater than this value, don't take a backup right now.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
'''Implementation note''': As of May 2, we don't halve the interval each time we PROCRASTINATE. Not sure if we need to worry about this.<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-05-02T08:19:58Z<p>Allquixotic: /* Busy Heuristics */</p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic], [http://opensimulator.org/wiki/User:Justincc justincc]<br />
* '''Start Date''': February 18, 2011<br />
* '''Status''': Active development as of May 2, 2011 (Beta)<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': Only the OpenSimDefaults.ini has to be modified to add the disable by default setting, outside of the AutoBackupModule code itself.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Global (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
** AutoBackupModuleEnabled: '''True/False'''. Default: False. If False, every function in the module is as no-op as possible: just return as soon as realizing that we're not enabled. Otherwise it will try to get as far as it can with auto backup for each region.<br />
* Per Region (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
* '''IMPORTANT:''' These settings use "RegionName.Setting" notation to construct the key name. So, to specify the AutoBackupInterval key for region "Foo", your key would be named '''Foo.AutoBackupInterval'''.<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupNaming: string. Default: Time.<br />
*** One of three strings (case insensitive):<br />
*** "Time": Current timestamp is appended to file name. An existing file will never be overwritten.<br />
*** "Sequential": A number is appended to the file name. So if RegionName_x.oar exists, we'll save to RegionName_{x+1}.oar next. An existing file will never be overwritten.<br />
*** "Overwrite": Always save to file named "RegionName.oar", even if we have to overwrite an existing file.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
** AutoBackupDilationThreshold: float. Default: 0.5. Lower bound on time dilation required for BusyCheck heuristics to pass.<br />
*** If the time dilation is below this value, don't take a backup right now.<br />
** AutoBackupAgentThreshold: int. Default: 10. Upper bound on # of agents in region required for BusyCheck heuristics to pass.<br />
*** If the number of agents is greater than this value, don't take a backup right now.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
'''Implementation note''': As of May 2, we don't halve the interval each time we PROCRASTINATE. Not sure if we need to worry about this.<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-05-02T08:18:54Z<p>Allquixotic: /* Criteria */</p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic], [http://opensimulator.org/wiki/User:Justincc justincc]<br />
* '''Start Date''': February 18, 2011<br />
* '''Status''': Active development as of May 2, 2011 (Beta)<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': Only the OpenSimDefaults.ini has to be modified to add the disable by default setting, outside of the AutoBackupModule code itself.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Global (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
** AutoBackupModuleEnabled: '''True/False'''. Default: False. If False, every function in the module is as no-op as possible: just return as soon as realizing that we're not enabled. Otherwise it will try to get as far as it can with auto backup for each region.<br />
* Per Region (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
* '''IMPORTANT:''' These settings use "RegionName.Setting" notation to construct the key name. So, to specify the AutoBackupInterval key for region "Foo", your key would be named '''Foo.AutoBackupInterval'''.<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupNaming: string. Default: Time.<br />
*** One of three strings (case insensitive):<br />
*** "Time": Current timestamp is appended to file name. An existing file will never be overwritten.<br />
*** "Sequential": A number is appended to the file name. So if RegionName_x.oar exists, we'll save to RegionName_{x+1}.oar next. An existing file will never be overwritten.<br />
*** "Overwrite": Always save to file named "RegionName.oar", even if we have to overwrite an existing file.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
** AutoBackupDilationThreshold: float. Default: 0.5. Lower bound on time dilation required for BusyCheck heuristics to pass.<br />
*** If the time dilation is below this value, don't take a backup right now.<br />
** AutoBackupAgentThreshold: int. Default: 10. Upper bound on # of agents in region required for BusyCheck heuristics to pass.<br />
*** If the number of agents is greater than this value, don't take a backup right now.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-05-02T08:17:11Z<p>Allquixotic: /* Basic Info */</p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic], [http://opensimulator.org/wiki/User:Justincc justincc]<br />
* '''Start Date''': February 18, 2011<br />
* '''Status''': Active development as of May 2, 2011 (Beta)<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': The only existing modules that could conceivably be affected are the IRegionArchiverModule, and any files dealing with the options in the Regions.ini config file.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Global (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
** AutoBackupModuleEnabled: '''True/False'''. Default: False. If False, every function in the module is as no-op as possible: just return as soon as realizing that we're not enabled. Otherwise it will try to get as far as it can with auto backup for each region.<br />
* Per Region (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
* '''IMPORTANT:''' These settings use "RegionName.Setting" notation to construct the key name. So, to specify the AutoBackupInterval key for region "Foo", your key would be named '''Foo.AutoBackupInterval'''.<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupNaming: string. Default: Time.<br />
*** One of three strings (case insensitive):<br />
*** "Time": Current timestamp is appended to file name. An existing file will never be overwritten.<br />
*** "Sequential": A number is appended to the file name. So if RegionName_x.oar exists, we'll save to RegionName_{x+1}.oar next. An existing file will never be overwritten.<br />
*** "Overwrite": Always save to file named "RegionName.oar", even if we have to overwrite an existing file.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
** AutoBackupDilationThreshold: float. Default: 0.5. Lower bound on time dilation required for BusyCheck heuristics to pass.<br />
*** If the time dilation is below this value, don't take a backup right now.<br />
** AutoBackupAgentThreshold: int. Default: 10. Upper bound on # of agents in region required for BusyCheck heuristics to pass.<br />
*** If the number of agents is greater than this value, don't take a backup right now.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-04-27T12:39:31Z<p>Allquixotic: </p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic]<br />
* '''Start Date''': February 18, 2011<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': The only existing modules that could conceivably be affected are the IRegionArchiverModule, and any files dealing with the options in the Regions.ini config file.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Global (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
** AutoBackupModuleEnabled: '''True/False'''. Default: False. If False, every function in the module is as no-op as possible: just return as soon as realizing that we're not enabled. Otherwise it will try to get as far as it can with auto backup for each region.<br />
* Per Region (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
* '''IMPORTANT:''' These settings use "RegionName.Setting" notation to construct the key name. So, to specify the AutoBackupInterval key for region "Foo", your key would be named '''Foo.AutoBackupInterval'''.<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupNaming: string. Default: Time.<br />
*** One of three strings (case insensitive):<br />
*** "Time": Current timestamp is appended to file name. An existing file will never be overwritten.<br />
*** "Sequential": A number is appended to the file name. So if RegionName_x.oar exists, we'll save to RegionName_{x+1}.oar next. An existing file will never be overwritten.<br />
*** "Overwrite": Always save to file named "RegionName.oar", even if we have to overwrite an existing file.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
** AutoBackupDilationThreshold: float. Default: 0.5. Lower bound on time dilation required for BusyCheck heuristics to pass.<br />
*** If the time dilation is below this value, don't take a backup right now.<br />
** AutoBackupAgentThreshold: int. Default: 10. Upper bound on # of agents in region required for BusyCheck heuristics to pass.<br />
*** If the number of agents is greater than this value, don't take a backup right now.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/TroubleshootingTroubleshooting2011-04-12T11:53:29Z<p>Allquixotic: added info about NotImplementedException</p>
<hr />
<div>{{Template:Quicklinks}}<br />
<br /><br />
This page gives any system-specific configuration settings that may be useful, and advice for problems that might be encountered.<br />
__TOC__<br />
{{clear}}<br />
[[Category:Users]]<br />
<br />
== General tips ==<br />
<br />
If OpenSim does startup to a point where you can type commands in the region console, then you can find out what your current configuration is by using the "config get" and "config save" commands as detailed at [[Server_Commands]] (and by typing help on the console).<br />
<br />
This can be useful for eliminating a bad configuration when diagnosing some issues.<br />
<br />
== System-specific configuration ==<br />
=== CentOS 5 ===<br />
<br />
To install mono and nant, you can use the "Linux Installer for x86" found at http://www.mono-project.com/Downloads.<br />
<br />
SVN can be installed by:<br />
<br />
yum install subversion<br />
<br />
Mono defaults to installing into <tt>/opt</tt>, so you may have to add this path to your environment variables, for example, in your <tt>~/.bashrc</tt>:<br />
<br />
export PATH="/opt/mono-1.2.5/bin:$PATH"<br />
export PKG_CONFIG_PATH="/opt/mono-1.2.5/lib/pkgconfig:$PKG_CONFIG_PATH"<br />
export MANPATH="/opt/mono-1.2.5/share/man:$MANPATH"<br />
export LD_LIBRARY_PATH="/opt/mono-1.2.5/lib:$LD_LIBRARY_PATH"<br />
<br />
After changing <tt>LD_LIBRARY_PATH</tt>, you should update the dynamic linker cache:<br />
<br />
ldconfig<br />
<br />
You may still encounter the "The current runtime framework 'mono-2.0' is not correctly configured in the NAnt configuration file." error listed below. In that case, this may fix this:<br />
<br />
yum install glib<br />
<br />
If you are running a firewall as well (i.e., if <tt>iptables -L</tt> shows a list of ACCEPT and REJECT rules), you'll have to open the necessary ports if you want to access the sim from other machines. For standalone mode:<br />
<br />
iptables -I RH-Firewall-1-INPUT -p tcp --dport 9000 -j ACCEPT<br />
iptables -I RH-Firewall-1-INPUT -p udp --dport 9000 -j ACCEPT<br />
<br />
If you are running Mono 2.2 compiled from source on CentOS 5.2 64bit (not sure if it applies to other scenarios as well), you need to take these steps:<br />
sudo yum install libgdiplus<br />
sudo yum install libexif<br />
sudo ln -s /usr/lib64/libgdiplus.so.0 /usr/lib64/libgdiplus.so<br />
ldconfig<br />
<br />
That finally enabled me to run OpenSim without errors, and even connect to other grids.<br />
<br />
=== Debian 4.0r0 ===<br />
<br />
If you set your system to use unstable sources, and then install some packages listed below, everything should just work. To use unstable sources, modify your <tt>/etc/apt/sources.list</tt> file, replacing 'etch' or 'stable' with 'unstable':<br />
<br />
deb ftp://ftp.debian.org/debian/ unstable main<br />
deb-src ftp://ftp.debian.org/debian/ unstable main<br />
<br />
Then update your packages to the new versions:<br />
<br />
apt-get update<br />
apt-get dist-upgrade<br />
<br />
This will probably change a large number of packages, and may break things.<br />
In my experience, however, if you do not use unstable sources then the packages are not up to date enough, and you run into version issues, which lead to two DllNotFoundException errors below appearing in the console output: gdiplus.dll and libopenjpeg-libsl-2.1.2.0.so.<br />
<br />
Once the sources are updated, we need to install the necessary packages to be able to build OpenSim:<br />
<br />
apt-get install subversion mono nant mono-gmcs mono-mjs libmono-microsoft8.0-cil libmono-system-runtime2.0-cil<br />
<br />
If any of these packages are missing, you'll probably encounter one of the errors listed below. However, with these packages, OpenSim should build cleanly.<br />
<br />
Please note: If you are using mysql as storage on unstable you may get the following error:-<br />
<br />
Exception: System.NotSupportedException: CodePage 1252 not supported<br />
at System.Text.Encoding.GetEncoding (Int32 codePage) [0x00000] <br />
<br />
To get it to work, try installing the libmono-i18n2.0-cil package<br />
<br />
apt-get install libmono-i18n2.0-cil<br />
<br />
=== Gentoo ===<br />
some Mono dependency & latest Mono itself may use "~x86" masked packages (assuming x86 is your platform, change may be made to reflect your ex:"~amd64" for 64bits). You could check for USE parameter with:<br />
<br />
ACCEPT_KEYWORDS="~x86" emerge -vp subversion nant mono libgdiplus<br />
<br />
Then install with:<br />
<br />
ACCEPT_KEYWORDS="~x86" emerge subversion nant mono libgdiplus<br />
<br />
N.B: The ACCEPT_KEYWORDS="~x86" can be set in Gentoo /etc/make.conf file, but that turn up all the emerges in testing/unstable, using it at the begining of emerge command line use it only for current emerge process<br />
<br />
=== Mac OS X ===<br />
This assumes you're using the universal binary for mono from the [http://www.mono-project.com/ Mono Project] site.<br />
<br />
If you are using OS X 10.4, you should also install X11 from the OS X install CDs.<br />
In OS X 10.5, this is not required.<br />
<br />
If you get errors about the 2.0 framework not being supported, you may need to update your <tt>pkg-config</tt> path.<br />
I set this in <tt>~/.bash_profile</tt>:<br />
export PKG_CONFIG_PATH="/Library/Frameworks/Mono.framework/Versions/Current/lib/pkgconfig/:${PKG_CONFIG_PATH}"<br />
<br />
== Errors and fixes ==<br />
<br />
=== Build workarounds due to non-functionality or bugs: ===<br />
<br />
==== Disappearing prims due to duplicate UID's ====<br />
<br />
Generally this problem occurs when a save-xml/load-xml file is loaded into the same sim without using the -newUID switch to generate new UUID's for the objects. See [[Server_Commands]] for detailed information. (<nowiki>load-xml <filename> -newUID</nowiki>). But if this does not work, the other way is to shift-copy your build and drag it up into the air.. then delete the one in the air, (which is actually the copy). This will generate new UID's on all your prims.. you can now leave that build, and load your original load-xml file in another region. <br />
<br />
----<br />
<br />
=== Exception and loss of ode physics (System.EntryPointNotFoundException: dSpaceLockQuery) ===<br />
<br />
The following error is usually caused by using the wrong version of ''libode'': <br />
<br />
{|<br />
|-<br />
| style="background: none repeat scroll 0% 0% LavenderBlush; color: black;" | <br />
[SCENE] [02-01 22:20:40] System.EntryPointNotFoundException: dSpaceLockQuery <br />
<br />
:at (wrapper managed-to-native) Ode.NET.d:SpaceLockQuery (intptr) <br />
:at OpenSim.Region.Physics.OdePlugin.OdeScene.waitForSpaceUnlock (IntPtr space) [0x00000] <br />
:at OpenSim.Region.Physics.OdePlugin.OdeCharacter.AvatarGeomAndBodyCreation (Single npositionX, Single npositionY, Single npositionZ, Single tensor) [0x00000] <br />
:at OpenSim.Region.Physics.OdePlugin.OdeCharacter..ctor (System.String avName, OpenSim.Region.Physics.OdePlugin.OdeScene parent_scene, OpenSim.Region.Physics.Manager.PhysicsVector pos) [0x00000] <br />
:at OpenSim.Region.Physics.OdePlugin.OdeScene.AddAvatar (System.String avName, OpenSim.Region.Physics.Manager.PhysicsVector position) [0x00000] <br />
:at OpenSim.Region.Environment.Scenes.ScenePresence.AddToPhysicalScene () [0x00000] <br />
:at OpenSim.Region.Environment.Scenes.ScenePresence.MakeRootAgent (LLVector3 pos, Boolean isFlying) [0x00000] <br />
:at OpenSim.Region.Environment.Scenes.Scene.AgentCrossing (UInt64 regionHandle, LLUUID agentID, LLVector3 position, Boolean isFlying) [0x00000]<br />
<br />
|}<br />
<br />
First try searching your filesystem to see if you have other copies of the ode physics engine: <br />
<br />
find / -name "libode.so"<br />
<br />
Then make sure you have the latest version. <br />
<br />
=== MySQL connection errors after about 6-8 hours ===<br />
<br />
MySQL has a timeout which drops the connection after 28,800 seconds (8 hours) of inactivity, which will probably result in failure to login after the User server has been sitting idle for an extended period. If you have this problem, increase the timeout to something larger, like 604800 (1 week) or 31536000 (1 year). From the mysql console, type: <br />
<br />
set global wait_timeout=604800;<br />
<br />
=== System.DllNotFoundException: gdiplus.dll ===<br />
<br />
First, check to make sure that <tt>libgdiplus.so</tt> is known to the dynamic linker: <br />
<br />
/sbin/ldconfig -p | grep libgdiplus<br />
<br />
If nothing is found, make sure that the directory libgdiplus.so exists in is either in your <tt>LD_LIBRARY_PATH</tt> environment variable or listed in a *.conf file (e.g., gdiplus.conf) in /etc/ld.so.conf.d/. Then run <tt>ldconfig</tt> to update the cache. Then it should be able to find the library. <br />
<br />
You may still have the above error, however, since libgdiplus also depends on other dynamic libraries, and if they fail to load, libgdiplus will fail. To test for this, run OpenSim with debugging information turned on: <br />
<br />
MONO_LOG_LEVEL=debug mono OpenSim.exe<br />
<br />
On Mac OS X - check the following file exists... /opt/local/lib/libgdiplus.dylib if it does then as root user edit the file /opt/local/etc/mono/config and add the line <br />
<br />
<dllmap dll="gdiplus.dll" target="/opt/local/lib/libgdiplus.dylib" os="!windows"/><br />
<br />
=== Migrating Opensim / MySQL database from Windows to Linux ===<br />
<br />
==== MySql.Data.MySqlClient.MySqlException: Table 'opensim.UserAccounts' doesn't exist ====<br />
<br />
'''Environment:''' Opensim Server 0.7.0.2 behind Linux Ubuntu 8.0.4 with mono 2.8 and MySQL 5.0 installed. <br />
<br />
When you migrates a Opensim 0.7 database working with MySQL 5.0 on Windows to Linux, when logging a user in Opensim server, you may receive the following exception in the Opensim server console: <br />
<br />
{|<br />
|-<br />
| style="background: none repeat scroll 0% 0% LavenderBlush; color: black;" | <br />
03:11:10 - [LLOGIN SERVICE]: Exception processing login for (user_name): MySql.Data.MySqlClient.MySqlException: Table 'opensim.UserAccounts' doesn't exist<br />
at MySql.Data.MySqlClient.MySqlStream.OpenPacket () [0x00000] in <filename unknown>:0<br />
at MySql.Data.MySqlClient.NativeDriver.ReadResult (System.UInt64&amp; affectedRows, System.Int64&amp; lastInsertId) [0x00000] in <filename unknown>:0<br />
at MySql.Data.MySqlClient.MySqlDataReader.GetResultSet () [0x00000] in <filename unknown>:0<br />
at MySql.Data.MySqlClient.MySqlDataReader.NextResult () [0x00000] in <filename unknown>:0 at MySql.Data.MySqlClient.MySqlStream.OpenPacket () [0x00000] in <filename unknown>:0<br />
at MySql.Data.MySqlClient.NativeDriver.ReadResult (System.UInt64&amp; affectedRows, System.Int64&amp; lastInsertId) [0x00000] in <filename unknown>:0<br />
at MySql.Data.MySqlClient.MySqlDataReader.GetResultSet () [0x00000] in <filename unknown>:0<br />
at MySql.Data.MySqlClient.MySqlDataReader.NextResult () [0x00000] in <filename unknown>:0<br />
<br />
|}<br />
<br />
On the client, you also receive the following error: <br />
<br />
Login Failed<br />
Error generating Login Response<br />
<br />
This exception is caused by the way MySQL store the table names. On a Windows MySQL server, the table names are not case sensitive, but '''all tables in MySQL Linux are case sensitive by default''', so when OpenSim will find them in the database with names in first capital letters, it can not find it. <br />
<br />
One solution would be to change the names of the tables required by opensim (ALTER TABLE's), but the cleanest solution is changing MySQL config, checking the option “'''lower_case_sensitive = 1'''” in the file "'''/etc/mysql/my.cnf'''", section '''[mysqld]'''. <br />
<br />
# sudo nano /etc/mysql/my.cnf<br />
<br />
..........................<br />
[mysqld]<br />
..........................<br />
lower_case_sensitive=1<br />
..........................<br />
<br />
This makes MySQL translate to lowercase the table names automatically. After restarting MySQL server and OpenSim, the tables are loaded without problems. <br />
<br />
Warning: don’t try to clear the table '''migration''' to force opensim re-migrate your database, because '''it will provoke a blight on your database'''.<br />
<br />
=== Errors from incomplete data migrations ===<br />
<br />
This can happen during version upgrades if for some reason a database migration fails when there is a change in the way OpenSim stores data. <br />
<br />
You may see errors on the OpenSim console like: <br />
<br />
[LLOGIN SERVICE]: Exception processing login for [username]: MySql.Data.MySqlClient.MySqlException: Table 'opensim.UserAccounts' doesn't exist<br />
at MySql.Data.MySqlClient.MySqlStream.OpenPacket () [0x00000] <br />
at MySql.Data.MySqlClient.NativeDriver.ReadResult (System.UInt64&amp; affectedRows, System.Int64&amp; lastInsertId) [0x00000] <br />
at MySql.Data.MySqlClient.MySqlDataReader.GetResultSet () [0x00000] <br />
at MySql.Data.MySqlClient.MySqlDataReader.NextResult () [0x00000] at MySql.Data.MySqlClient.MySqlStream.OpenPacket () [0x00000] <br />
at MySql.Data.MySqlClient.NativeDriver.ReadResult (System.UInt64&amp; affectedRows, System.Int64&amp; lastInsertId) [0x00000] <br />
at MySql.Data.MySqlClient.MySqlDataReader.GetResultSet () [0x00000] <br />
at MySql.Data.MySqlClient.MySqlDataReader.NextResult () [0x00000] <br />
<br />
In this case the 'users' table had not been migrated to the 'UserAccounts' table which OpenSim was expecting, also resulting in the viewerside error: <br />
<br />
Login Failed<br />
Error generating Login Response<br />
<br />
I solved by fixing the filesystem permissions that were causing the migration to fail (on my Linux box '/var/lib/mysql/...' had got itself messed up), then dropping the 'migration' table and running the server again (from the [non-critical] migration warnings encountered there was probably a more precise way to do this, but I was fully backed up so I did it quick-and-dirty). Other than loosing terrain data refs. and current shape/clothing/attachment data (easily restored in-sim) all was now good for me.<br />
<br />
=== When installing mono or libgdiplus0 you may get dependency missing libexif.so.9 === <br />
<br />
This was noticed on Centos5 but may occur on other systems, download ftp://rpmfind.net/linux/conectiva/snapshot/i386/RPMS.extra/libexif9-0.5.12-47547cl.i386.rpm and install problem solved. You will now be able to install mono (as long as nothing else goes wrong )<br />
<br />
=== The assembly mscorlib.dll was not found or could not be loaded ===<br />
<br />
This indicates that you are missing one of the mscor libs that comes with nant. This is easily solved by getting NAnt, which comes with both versions 1.0 and 2.0 of the required lib.<br />
<br />
apt-get install nant<br />
<br />
=== External Program Failed: /usr/lib/pkgconfig/../../lib/mono/2.0/gmcs.exe === <br />
<br />
This is quickly fixed by retrieving mono-gmcs.<br />
<br />
apt-get install mono-gmcs<br />
<br />
=== The type or namespace name JScript does not exist in the namespace Microsoft ===<br />
<br />
Note that it says JScript over and over again. Hint perhaps?<br />
<br />
apt-get install mono-mjs libmono-microsoft8.0-cil<br />
<br />
On Fedora and OpenSUSE, the needed package is "mono-jscript".<br />
<br />
=== The type or namespace name Tcp does not exist in the namespace System.Runtime.Remoting.Channels ===<br />
<br />
This one is taken care of with a quick install:<br />
<br />
apt-get install libmono-system-runtime2.0-cil<br />
<br />
=== Missing: libopenjpeg-libsl-2.1.2.0-x86_64.so ===<br />
<br />
You are probably on a 64-bit linux machine and may need to follow these instructions:<br />
<br />
* [[Installing_and_running_on_x86-64 |Installing and running on x86-64 ]]<br />
<br />
=== error while loading shared libraries: libgthread-2.0.so.0: cannot open shared object file ===<br />
<br />
If you start with a base Debian system as we did at the top of the page, but instead of using the apt version of mono you use the installer from their website, then you may encounter this issue.<br />
<br />
After getting the .bin file from http://www.mono-project.com/Downloads, and executing it as per its instructions, upon finishing, you may find that if you try to run `mono --version` you are presented with this message. This one means you need to install libglib2.0-0.<br />
<br />
apt-get install libglib2.0-0<br />
<br />
=== The current runtime framework 'mono-2.0' is not correctly configured in the NAnt configuration file. ===<br />
<br />
This one seems to be fixed by retrieving the apt version of nant.<br />
<br />
apt-get install nant<br />
<br />
This can also be due to <tt>pkg-config</tt> not being able to locate the <tt>mono.pc</tt> file. Adding the directory containing this file to the environment variable <tt>PKG_CONFIG_PATH</tt> may solve this.<br />
<br />
== Networking and config issues ==<br />
<br />
See also the wiki page:<br />
* [[Network Settings]]<br />
* [[Configuration]]<br />
<br />
=== You are able to log in, but not connect to a Region from a remote client ===<br />
<br />
Look in your OpenSimulator/bin/Regions folder: <br />
<br />
In 0.6.7 or later,<br />
# Try '''0.0.0.0''' for the InternalAddress in your Regions.ini file.<br />
# '''ExternalHostName=127.0.0.1''' will be needed to change its name to the asscssable DNS name such as "opensim.example-host.com" or "71.6.131.152" (your public accessable ip)<br />
In 0.6.6 or earlier,<br />
# Try '''0.0.0.0''' for the internal_ip_address in your region.xml(default.xml) file.<br>(you'll have one of these files for each region you have created)<br />
# '''external_host_name="127.0.0.1"''' will be needed to change its name to the accessable DNS name such as "opensim.example-host.com" or "71.6.131.152" (your public accessable ip)<br />
<br />
==Building OpenSim==<br />
===I can't find any build files or solution files===<br />
* If you're on Windows, run<br />
runprebuild.bat<br />
* on Linux/Mac/FreeBSD, run <br />
runprebuild.sh<br />
<br />
=== VS2005 won't open the .sln file ===<br />
* Try running VS2005 C#. You are probably running VS2005 C++. This is a C# project.<br />
<br />
==Running OpenSim==<br />
=== Running OpenSim.exe from a Cygwin shell has access denied for some dll's ===<br />
* Do a '<tt>cd bin</tt>' followed by '<tt>chmod a+x *</tt>' to make all dll files executable.<br />
===I cannot start my sim===<br />
* See [[Configuration]]<br />
<br />
==Something Has Gone Wrong!==<br />
=== I get errors concerning 'owner_uuid' when starting up my grid after updating from svn beyond r3254 ===<br />
When updating to recent revisions after r3254, we are now using the unused owner_uuid. There are some grids whose mysql tables were created during a time when this field was inadvertently removed from the .sql script that initializes the regions table. Logging in to your mysql instance and executing this SQL query to add the missing owner_uuid should solve this issue:<br />
alter table `regions` add column `owner_uuid` varchar(36) default '00000000-0000-0000-0000-000000000000' not null, comment 'Rev.2';<br />
The punctuation around regions and owner_uuid is "grave accent". The punctuation around the default value and the comment is the single quote. The "grave accent" is the one generally to the left of the One button, under the tilde and the single-quote, is, well, underneath the double quote. I think this matters to mysql.<br />
<br />
=== I get errors concerning 'State' when starting up my grid after updating from svn beyond r3786 ===<br />
After r3786, a new 'State' field has been added to the 'primshapes' table on SQLite. This field is used to persist trees and grass.<br />
You may have an empty region at startup, because OpenSim does not find this 'State' field and does not know what to do.<br />
The best is to use SQLiteBrowser or another SQLite table editor (download it at [http://sqlitebrowser.sourceforge.net/ http://sqlitebrowser.sourceforge.net/]) to create the missing field:<br />
alter table primshapes add column State integer default 0<br />
Just launch SQLiteBrowser, use File/Open database, then browse to OpenSim.db file and open it. Then, go to the "Execute SQL" tab, copy/paste the command above in the "SQL string" textbox, then hit the "Execute query" button.<br />
<br />
=== I get a timeout during region handshake ===<br />
* Do you have the correct IP in your Regions\* config files?<br />
* Do you have multiple interfaces on the server running OpenSim? OpenSim will not bind outgoing UDP packets to a specific IP, its default IP to reach you will be what the Region answers UDP with. If you have configured the region for another IP you will get a timeout during connect.<br />
<br />
=== I cannot connect to my OpenSim ===<br />
* See [[OpenSim: Connecting]]<br />
<br />
===I can connect but cannot move===<br />
If the client connects but the avatar can only spin in place and not move, then the sim is not correctly configured. It completed the initial login function, but packets are not being exchanged between the client and the sim, probably due to a network configuration error on the sim.<br />
* See [[OpenSim: Configuration]]<br />
<br />
=== From time to time my Avatar seems to get stuck ===<br />
Right now there is a bottle neck when syncing prims off to the database. This will cause small (5 - 10 second) apparent hangs of the Avatar, but it will recover fine once the data is synced. It is a known issue based on legacy architecture of some of the data storage code. We hope this will be removed soon.<br />
<br />
=== I have problems with viewing the worldmap ===<br />
* This may happen when running OpenSim on a Linux server, both in grid or standalone mode.<br />
* Symptoms: when opening the worldmap window in the SL-viewer, the sims are not displayed grahically in the worldmap, the server console shows some error related to openjpeg, the current session freezes...<br />
* Reason: your svn source trunk does not have the correct (or whatever...) <tt>libopenjpeg-libsl</tt> library.<br />
* Other reason: the file "defaultstripe.png" does not exists in the same OpenSim folder, or is corrupted.<br />
* Solution: get the newest code from libsecondlife (<tt>svn co svn://opensecondlife.org/libsl/trunk</tt>), '<tt>make</tt>' manually in the subdir <tt>openjpeg-libsl</tt>, and copy the resulting <tt>libopenjpeg-libsl-2.1.2.0.so</tt> into your OpenSim <tt>bin</tt> subdir, overwriting the existing one.<br />
* Recompile & restart OpenSim<br />
<br />
==Exceptions on the Console==<br />
This is a list of Exceptions that you may see on the console, what they mean, and if they are a problem.<br />
<br />
===System.DllNotFoundException: ./libopenjpeg-libsl-2.1.2.0.so===<br />
<br />
{|<br />
| style="background:LavenderBlush; color:black" |<br />
Failed generating terrain map: System.DllNotFoundException: ./libopenjpeg-libsl-2.1.2.0.so<br />
: at (wrapper managed-to-native) OpenJPEGNet.OpenJPEG:LibslAllocDecoded OpenJPEGNet.OpenJPEG/LibslImage&)<br />
: at OpenJPEGNet.OpenJPEG.Encode (System.Byte[] decoded, Int32 width, Int32 height, Int32 components, Boolean lossless) [0x00000]<br />
:at OpenJPEGNet.OpenJPEG.EncodeFromImage (System.Drawing.Bitmap bitmap, Boolean lossless) [0x00000]<br />
:at OpenSim.Region.Terrain.TerrainEngine.ExportJpegImage (System.String gradientmap) [0x00000]<br />
|}<br />
<br />
You are on Linux, and the native lib libopenjpeg-libsl-2.1.2.0.so is not compatible with your system for one of the following reasons:<br />
* You have an old processor (libopenjpeg has been compiled with optimizations)<br />
* You are running in 64bit mode (none of the native libs are built for 64bit)<br />
<br />
You can rebuild your own libopenjpeg from source, or run in a compatible environment.<br />
You can do this by:<br />
svn co svn://openmv.org/libsl/libopenmetaverse/trunk libsl<br />
cd libsl/openjpeg-libsl/<br />
make<br />
<br />
then copy libopenjpeg-libsl-2.1.2.0.so into OpenSim bin-folder.<br />
<br />
=== System.NullReferenceException at OpenSim.Region.Communications.Local.LocalLoginService.PrepareLoginToRegion ===<br />
{|<br />
| style="background:LavenderBlush; color:black" |<br />
[LOGIN END]: XMLRPC Login failed, System.NullReferenceException: Object reference not set to an instance of an object<br />
:at OpenSim.Region.Communications.Local.LocalLoginService.PrepareLoginToRegion (OpenSim.Framework.RegionInfo regionInfo, OpenSim.Framework.UserProfileData user, OpenSim.Framework.Communications.LoginResponse response) [0x00000] in /home/sim/svn/opensim/OpenSim/Region/Communications/Local/LocalLoginService.cs:293<br />
:at OpenSim.Region.Communications.Local.LocalLoginService.CustomiseResponse (OpenSim.Framework.Communications.LoginResponse response, OpenSim.Framework.UserProfileData theUser, System.String startLocationRequest) [0x00520] in /home/sim/svn/opensim/OpenSim/Region/Communications/Local/LocalLoginService.cs:253<br />
:at OpenSim.Framework.Communications.LoginService.XmlRpcLoginMethod (Nwc.XmlRpc.XmlRpcRequest request) [0x00369] in /home/sim/svn/opensim/OpenSim/Framework/Communications/LoginService.cs:252<br />
|}<br />
<br />
Your first startup of OpenSim has failed for example due to giving non existent domain name when prompted for region external host name. This causes only partial initialization. You need to delete bin folder, do svn update, rebuild and purge database to resolve this issue.<br />
<br />
=== Exception: System.NotImplementedException: The requested feature is not implemented. ===<br />
<br />
If your exception starts as follows:<br />
<br />
{|<br />
| style="background:LavenderBlush; color:black" |<br />
|Exception: System.NotImplementedException: The requested feature is not implemented.<br />
at (wrapper managed-to-native) System.Threading.Interlocked:Add (int&,int)<br />
at System.Threading.ReaderWriterLockSlim.TryEnterReadLock (Int32 millisecondsTimeout) [0x000e3] in<br />
|}<br />
<br />
You probably unwittingly passed the option '''--optimize=-all''' to mono. The problem is that Mono compiles in an "optimized" version of the System.Threading.Interlocked class's methods; these optimizations are done using raw assembler for your architecture (automatically detected at build time). When you pass '''--optimize=-all''', the runtime detects that these functions are optimized, and disables them. So the next time a class tries to call these functions, the runtime finds that there is no native implementation of the methods! This affects almost all synchronization primitives System.Threading. Since OpenSimulator relies heavily on threading and locking mechanisms, we can't do without this functionality. Perhaps a future Mono version will allow you to pass '''--optimize=-all''', and provide an unoptimized implementation (e.g. pthreads), rather than throwing an exception.<br />
<br />
If you're looking to debug a low level problem with mono (such as an error in native code), passing '''--optimize=-all''' is not the way to go about it. Instead, set the environment variable MONO_LOG_LEVEL=debug and run your program with the '''--debug''' switch passed to mono. You can also run mono under gdb, just like any other process.<br />
<br />
==Grid Mode==<br />
<br />
=== I start the sim and it doesn't connect to any grid ===<br />
<br />
When OpenSim is first started, it needs configuration.<br />
<br />
* See [[OpenSim: Configuration]].<br />
<br />
=== My grid works fine with one user but when two users login in the same time both get stuck ===<br />
* Make sure you have export MONO_THREADS_PER_CPU="100" in your environment<br />
<br />
=== After ~20 minutes my region starts to take 100% cpu and region(s) hang ===<br />
* If you have mono 1.9.1 or lower upgrade to mono 2.2.<br />
<br />
==Hypergrid==<br />
===After starting OpenSim with Hypergrid enabled my inventory wont load!===<br />
*If you're running in grid mode, first check your OpenSim.ini to make sure that the dns names or addresses for your grid servers are accessible to both you and the public.<br />
*Check the XML config files for your UGAIM servers to make sure that everything is running off of a publicly accessible IP address.<br />
**If this is the case and you have to change your UGAIM addresses you will need to run a few quick and dirty SQL queries on your database in order to update your grid's user accounts so that they now point to the new IP addresses of your UGAIM.<br />
<br />
Log into your sql server and change over to the database for your grid. The following will update your user's home inventory and asset URIs after changing the addresses of your UGAIM services in the XML configuration files.<br />
<br />
<div align = center><B>!!!!WARNING!!!! - Be smart! Always make a backup of your databases before making any changes to OpenSim! - !!!!WARNING!!!!</b></div><br />
<pre><br />
update users set userInventoryURI="http://new.UGAIM.address:8004" where userInventoryURI = "http://old.UGAIM.address:8004";<br />
</pre><br />
<br />
<pre><br />
update users set userAssetURI="http://new.UGAIM.address:8003" where userAssetURI = "http://old.UGAIM.address:8003";<br />
</pre><br />
*If you're running in standalone mode... - Anyone familiar with standalone want to fill this in? -<br />
[[Category:Users]]<br />
<br />
== ScriptEngine Issues ==<br />
=== Got "Primitive: Error compiling script: unknown char: . error" when compiling script ===<br />
When trying to compile a script ( using [[DotNetEngine]] or [[XEngine]] ) you could have this error :<br />
{|<br />
| style="background:LavenderBlush; color:black" |<br />
Primitive: Error compiling script:<br />
unknown char: .<br />
|}<br />
<br />
And on the console :<br />
{|<br />
| style="background:LavenderBlush; color:black" |<br />
11:06:37 - [ScriptEngine.DotNetEngine]: Unloading script<br><br />
11:06:37 - Exception in MaintenanceLoopThread. Thread will recover after 5 sec throttle. Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.<br />
:at System.Collections.Generic.Dictionary`2[OpenSim.Region.ScriptEngine.Interfaces.IEventReceiver, OpenSim.Region.ScriptEngine.Shared.Api.Plugins.Dataserver].get_Item (IEventReceiver key) [0x00000]<br />
:at OpenSim.Region.ScriptEngine.Shared.Api.AsyncCommandManager.RemoveScript (IEventReceiver engine, UInt32 localID, UUID itemID) [0x00000]<br />
:at OpenSim.Region.ScriptEngine.DotNetEngine.ScriptManager._StopScript (UInt32 localID, UUID itemID) [0x00000]<br />
:at OpenSim.Region.ScriptEngine.DotNetEngine.ScriptManager.DoScriptLoadUnload () [0x00000]<br />
:at OpenSim.Region.ScriptEngine.DotNetEngine.MaintenanceThread.MaintenanceLoop () [0x00000]<br />
11:06:37 - [ScriptEngine.DotNetEngine]: Loading script<br><br />
11:06:37 - [ScriptEngine.DotNetEngine]: ScriptManager StartScript: localID: 720001, itemID: 88c9d28c-6004-4609-a707-717190de044a<br><br />
11:06:37 - [Compiler]: Compiled new assembly for fad15951-f9aa-493f-be68-2aaf5ff8a3c9<br><br />
11:06:37 - [SCRIPT]: Compiled assetID fad15951-f9aa-493f-be68-2aaf5ff8a3c9: ScriptEngines/a83150da-1ab1-11dd-89fb-0014853ee9da/CommonCompiler_compiled_fad15951-f9aa-493f-be68-2aaf5ff8a3c9.dll<br><br />
11:06:37 - [ScriptEngine.DotNetEngine]: AppDomain Loading: OpenSim.Region.ScriptEngine.Shared, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null<br />
|}<br />
<br />
This happens on '''linux''' when your locales are not set to default ( "C" ).<br />
* You could refer to [http://opensimulator.org/mantis/view.php?id=2088 Mantis #2088] and [http://opensimulator.org/mantis/view.php?id=2015 Mantis #2015] for a workaround to run opensim.<br />
<pre><br />
env LANG=C mono --debug OpenSim.exe<br />
</pre><br />
* You could also change your locale setup. Here is what I use in my '.bash_profile' :<br />
<pre><br />
export LC_ALL=C<br />
export LANG=C<br />
</pre><br />
I know it's a ugly way to setup locales on a linux box, but it works fine on my '''Linux From Scratch''' box.<br />
<br />
'''Rq''': I saw Melanie has corrected some parts of the source code a few weeks ago to avoid such problems.<br />
<br />
=== Get "Primitive: Error compiling script: ApplicationName='gmcs', ..." when compiling script ===<br />
When trying to compile a script ( using DotNetEngine or XEngine ) you have an error something like :<br />
<br />
{| width="100%"<br />
| style="background:LavenderBlush; color:black" |<br />
Primitive: Error compiling script:<br><br />
ApplicationName='gmcs', CommandLine='/target:library /debug+ /optimize- /out:<br />
:"ScriptEngines/430c29d0-c5c6-11dd-ad8b-0800200c9a66/CommonCompiler_compiled_fbe5e682-afae-4f1a-805b-0125031101f7.dll" <br />
:/r:"/usr/lib/opensim/bin/OpenSim.Region.ScriptEngine.Shared.dll"<br />
:/r:"/usr/lib/opensim/bin/OpenSim.Region.ScriptEngine.Shared.Api.Runtime.dll" -- <br />
:"/tmp/11b81aac/594d02ce.0.cs" ', CurrentDirectory=''<br />
|}<br />
<br />
Other features include "Touch" being disabled on the right click menu wheel.<br />
<br />
You might have a broken mono install (i.e. discovered as mono but not gmcs installed on a Ubuntu 8.10 Intrepid machine.)<br />
<br />
Check mono-gmcs (sudo apt-get install mono-gmcs) is correctly installed.<br />
<br />
== Locales Issues ==<br />
Well, some of us, OpenSim users, ran into random crash of the OpenSim Region server in grid mode ... <br />
<br />
I have made many tests to find a solution about that problem.<br />
<br />
I first ran into this problem with OpenSIM SVN.6660 ... Even if I have no users connected, my OpenSim region server randomly crash ( after 1 hour, or 5 hours, ... ).<br />
<br />
My first idea was to upgrade to the latest SVN release, no chance, same problem. So I made a test with a previous SVN release ( SVN.6575 ) which is running fine on another server ( same OS, same parameters, same mono release, ... ) : No chance, same problem.<br />
<br />
Then, I tried to play with locales, recompile the '''screen''' unix command line utility I use to run my servers, ... No chance again.<br />
<br />
So, I checked the memory usage on my Server, and I discovered that with the last SVN release, the amount of memory needed to run OpenSim server in multi-region/grid mode increased :) ... So, I have tuned my MySQL server to use less memory. Was better, but my OpenSim region server still randomly crash ( but could stay alive longer than before ).<br />
<br />
Then, trying to play with the '''screen''' command line options ... And all my tests shows that the '''--debug''' option impact the stability of the server.<br />
<br />
Initially, I used such command line to run OpenSim :<br />
<pre><br />
/screen -S Region-service -d -m --debug mono OpenSim.exe<br />
</pre><br />
<br />
Without the '''--debug''' option, everything seems to be more stable.<br />
<br />
About locales, if you read mantis and threads in opensim-dev / opensim-users, you know that there are issues on system that are not "en_US" or "C" local compliant.<br />
<br />
I have re-setup my server to be full "en_US.UTF8".<br />
<br />
On my Ubuntu 8.0.4 server :<br />
<pre><br />
# cat /etc/default/locale<br />
LANG="en_US.UTF-8"<br />
<br />
# cat /var/lib/locales/supported.d/local<br />
fr_FR.UTF-8 UTF-8<br />
en_US.UTF-8 UTF-8<br />
<br />
# cat /etc/environment<br />
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"<br />
LANG="en_US"<br />
LANGUAGE="en_US"<br />
</pre><br />
And maybe you should need :<br />
<pre><br />
# sudo dpkg-reconfigure locales<br />
</pre><br />
<br />
So, the resulting '''screen''' command line options should be :<br />
<pre><br />
screen -S Region-service -d -m -U mono OpenSim.exe<br />
</pre><br />
<br />
This allow me to run OpenSim SVN.6575 without crash during more than 48 hours, and also SVN.6735 ... <br />
<br />
Hope those informations could help peoples.<br />
<br />
Just for your information : <br />
<br />
Here is my '''OpenSim Startup script''' :<br />
<pre><br />
#!/bin/bash<br />
<br />
echo "User-Service..."<br />
/usr/local/bin/screen -S User-service -d -m -U mono OpenSim.Grid.UserServer.exe<br />
sleep 5<br />
echo "Grid-Service..."<br />
/usr/local/bin/screen -S Grid-service -d -m -U mono OpenSim.Grid.GridServer.exe<br />
sleep 5<br />
echo "Asset-Service..."<br />
/usr/local/bin/screen -S Asset-service -d -m -U mono OpenSim.Grid.AssetServer.exe<br />
sleep 10<br />
echo "Inventory-Service..."<br />
/usr/local/bin/screen -S Inventory-service -d -m -U mono OpenSim.Grid.InventoryServer.exe<br />
sleep 5<br />
echo "Region-Service..."<br />
/usr/local/bin/screen -S Region-service -d -m -U mono OpenSim.exe<br />
sleep 5<br />
echo " "<br />
echo " "<br />
/usr/local/bin/screen -list<br />
</pre><br />
<br />
Here is also a small script that give you a menu to connect to the '''screen(s)''' sessions :<br />
<pre><br />
#!/usr/bin/perl<br />
<br />
use strict;<br />
use Term::Menu;<br />
<br />
my $EXIT = 1;<br />
<br />
my $MainTitle = "+-----------------------------------------------------+\n";<br />
$MainTitle .= "| Connexion SCREEN aux Serveurs OPENSIM |\n";<br />
$MainTitle .= "| |\n";<br />
$MainTitle .= "| ( Type CTRL+A+D to exit the Screen Console. ) |\n";<br />
$MainTitle .= "+-----------------------------------------------------+\n";<br />
<br />
while ( $EXIT == 1 )<br />
{<br />
<br />
system("screen -list | grep service > /tmp/osg.services");<br />
my %LIST = ();<br />
open(IN, "/tmp/osg.services");<br />
while ( my $i = <IN> )<br />
{<br />
chomp($i);<br />
<br />
$i =~ s/\./#/g;<br />
$i =~ s/\-service\t/#/g;<br />
$i =~ s/\t//g;<br />
$i =~ s/\(//g;<br />
$i =~ s/\)//g;<br />
<br />
my @STATUS = split(/#/, $i);<br />
$LIST{$STATUS[1]} = $STATUS[2];<br />
}<br />
close(IN);<br />
<br />
my %LIST2 = ();<br />
my @indices = ('User', 'Grid', 'Asset', 'Inventory', 'Region');<br />
<br />
foreach my $key ( @indices )<br />
{<br />
# print "$key --> $LIST{$key}\n";<br />
if ( $LIST{$key} =~ /Attached/ )<br />
{<br />
$LIST2{$key} = "[X]";<br />
}<br />
else<br />
{<br />
$LIST2{$key} = "[ ]";<br />
}<br />
}<br />
<br />
if ( $LIST{'User'} =~ /Attached/ )<br />
{<br />
$LIST2{'USER'} = "X";<br />
}<br />
else<br />
{<br />
$LIST2{'USER'} = "-";<br />
}<br />
<br />
system ('clear');<br />
my $prompt = new Term::Menu (<br />
spaces => 3,<br />
aftertext => "\nChoisir une option : ",<br />
beforetext => ${MainTitle},<br />
delim => ". ",<br />
);<br />
<br />
my $SEP = " ";<br />
<br />
my $answer = $prompt->menu(<br />
osg_user => ["OpenSim User Server $SEP$LIST2{'User'}", '1'],<br />
osg_grid => ["OpenSim Grid Server $SEP$LIST2{'Grid'}", '2'],<br />
osg_asset => ["OpenSim Asset Server $SEP$LIST2{'Asset'}", '3'],<br />
osg_inventory => ["OpenSim Inventory Server $SEP$LIST2{'Inventory'}", '4'],<br />
osg_region => ["OpenSim Region Server $SEP$LIST2{'Region'}\n", '5'],<br />
osg_shutdown => ["Shutdown Servers (Manual)",'6'],<br />
osg_shutdown2 => ["Shutdown Servers (Hard)\n",'7'],<br />
quit => ["Quitter", 'q'],<br />
);<br />
<br />
if ( "${answer}" eq "quit" )<br />
{<br />
$EXIT = 0;<br />
}<br />
<br />
if ( "${answer}" eq "osg_user" )<br />
{<br />
system("screen -d -r -S User-service");<br />
$EXIT = 1;<br />
}<br />
<br />
if ( "${answer}" eq "osg_grid" )<br />
{<br />
system("screen -d -r -S Grid-service");<br />
$EXIT = 1;<br />
}<br />
<br />
if ( "${answer}" eq "osg_asset" )<br />
{<br />
system("screen -d -r -S Asset-service");<br />
$EXIT = 1;<br />
}<br />
<br />
if ( "${answer}" eq "osg_inventory" )<br />
{<br />
system("screen -d -r -S Inventory-service");<br />
$EXIT = 1;<br />
}<br />
<br />
if ( "${answer}" eq "osg_region" )<br />
{<br />
system("screen -d -r -S Region-service");<br />
$EXIT = 1;<br />
}<br />
<br />
if ( "${answer}" eq "osg_shutdown" )<br />
{<br />
system("screen -d -r -S Region-service");<br />
system("screen -d -r -S Inventory-service");<br />
system("screen -d -r -S Asset-service");<br />
system("screen -d -r -S Grid-service");<br />
system("screen -d -r -S User-service");<br />
$EXIT = 1;<br />
}<br />
<br />
if ( "${answer}" eq "osg_shutdown2" )<br />
{<br />
# system("/OPENSIM/shutdownGrid.py");<br />
system("screen -S Region-service -r -m -X quit");<br />
system("screen -S Inventory-service -r -m -X quit");<br />
system("screen -S Asset-service -r -m -X quit");<br />
system("screen -S Grid-service -r -m -X quit");<br />
system("screen -S User-service -r -m -X quit");<br />
$EXIT = 0;<br />
}<br />
}<br />
</pre><br />
<br />
Regards, <br />
Ursula Matova.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-02-28T16:49:27Z<p>Allquixotic: </p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic]<br />
* '''Start Date''': February 18, 2011<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': The only existing modules that could conceivably be affected are the IRegionArchiverModule, and any files dealing with the options in the Regions.ini config file.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Global (in '''OpenSim.ini''' under '''[Modules]''' section)<br />
** AutoBackupModule: '''True/False'''. Default: False. If False, every function in the module is as no-op as possible: just return as soon as realizing that we're not enabled. Otherwise it will try to get as far as it can with auto backup for each region.<br />
* Per Region (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
* '''IMPORTANT:''' These settings use "RegionName.Setting" notation to construct the key name. So, to specify the AutoBackupInterval key for region "Foo", your key would be named '''Foo.AutoBackupInterval'''.<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupNaming: string. Default: Time.<br />
*** One of three strings (case insensitive):<br />
*** "Time": Current timestamp is appended to file name. An existing file will never be overwritten.<br />
*** "Sequential": A number is appended to the file name. So if RegionName_x.oar exists, we'll save to RegionName_{x+1}.oar next. An existing file will never be overwritten.<br />
*** "Overwrite": Always save to file named "RegionName.oar", even if we have to overwrite an existing file.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
** AutoBackupDilationThreshold: float. Default: 0.5. Lower bound on time dilation required for BusyCheck heuristics to pass.<br />
*** If the time dilation is below this value, don't take a backup right now.<br />
** AutoBackupAgentThreshold: int. Default: 10. Upper bound on # of agents in region required for BusyCheck heuristics to pass.<br />
*** If the number of agents is greater than this value, don't take a backup right now.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-02-25T13:51:08Z<p>Allquixotic: </p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic]<br />
* '''Start Date''': February 18, 2011<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': The only existing modules that could conceivably be affected are the IRegionArchiverModule, and any files dealing with the options in the Regions.ini config file.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Global (in '''OpenSim.ini''' under '''[Modules]''' section)<br />
** AutoBackupModule: '''True/False'''. Default: False. If False, every function in the module is as no-op as possible: just return as soon as realizing that we're not enabled. Otherwise it will try to get as far as it can with auto backup for each region.<br />
* Per Region (in '''OpenSim.ini''' under '''[AutoBackupModule]''' section)<br />
* '''IMPORTANT:''' These settings use "RegionName.Setting" notation to construct the key name. So, to specify the AutoBackupInterval key for region "Foo", your key would be named '''Foo.AutoBackupInterval'''.<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupNaming: string. Default: Time.<br />
*** One of three strings (case insensitive):<br />
*** "Time": Current timestamp is appended to file name. An existing file will never be overwritten.<br />
*** "Sequential": A number is appended to the file name. So if RegionName_x.oar exists, we'll save to RegionName_{x+1}.oar next. An existing file will never be overwritten.<br />
*** "Overwrite": Always save to file named "RegionName.oar", even if we have to overwrite an existing file.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-02-19T14:37:50Z<p>Allquixotic: </p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic]<br />
* '''Start Date''': February 18, 2011<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': The only existing modules that could conceivably be affected are the IRegionArchiverModule, and any files dealing with the options in the Regions.ini config file.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Per Region (in e.g. Regions/Regions.ini)<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupNaming: string. Default: Time.<br />
*** One of three strings (case insensitive):<br />
*** "Time": Current timestamp is appended to file name. An existing file will never be overwritten.<br />
*** "Sequential": A number is appended to the file name. So if RegionName_x.oar exists, we'll save to RegionName_{x+1}.oar next. An existing file will never be overwritten.<br />
*** "Overwrite": Always save to file named "RegionName.oar", even if we have to overwrite an existing file.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-02-19T13:23:49Z<p>Allquixotic: </p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic]<br />
* '''Start Date''': February 18, 2011<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': The only existing modules that could conceivably be affected are the IRegionArchiverModule, and any files dealing with the options in the Regions.ini config file.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Per Region (in e.g. Regions/Regions.ini)<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
** AutoBackupOverwrite: True/False. Default: False. If true, each auto-backup overwrites a single file named "${AutoBackupDir}/RegionName.oar". If false, the current timestamp is appended to the file name, thus creating a new file each backup.<br />
** AutoBackupDir: String. Default: "." (the current directory). A directory (absolute or relative) where backups should be saved. If the path is not a directory, or insufficient permissions are available, a warning will be printed to the console and no backups will be taken.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-02-19T11:46:12Z<p>Allquixotic: /* Configuration Settings */</p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic]<br />
* '''Start Date''': February 18, 2011<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': The only existing modules that could conceivably be affected are the IRegionArchiverModule, and any files dealing with the options in the Regions.ini config file.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Per Region (in e.g. Regions/Regions.ini)<br />
** AutoBackup: '''True/False'''. Default: False. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region, and all other AutoBackup* settings are ignored.<br />
** AutoBackupInterval: '''Integer''', non-negative value. Default: 720 (12 hours). The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. Default: True. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. Default: not specified (disabled). File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR. If the process can't be spawned for some reason (file not found, no execute permission, etc), write a warning to the console.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-02-19T11:41:44Z<p>Allquixotic: </p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic]<br />
* '''Start Date''': February 18, 2011<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': The only existing modules that could conceivably be affected are the IRegionArchiverModule, and any files dealing with the options in the Regions.ini config file.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
=== Configuration Settings ===<br />
<br />
* Per Region (in e.g. Regions/Regions.ini)<br />
** AutoBackup: '''True/False'''. If True, activate auto backup functionality. This is the only '''required''' option for enabling auto-backup; the other options have sane defaults. If False, the auto-backup module becomes a no-op for the region.<br />
** AutoBackupInterval: '''Integer''', non-negative value. The number of minutes between each backup attempt. If a negative or zero value is given, it is equivalent to setting AutoBackup = False.<br />
** AutoBackupBusyCheck: '''True/False'''. If True, we will only take an auto-backup if a set of conditions are met. These conditions are heuristics to try and avoid taking a backup when the sim is busy.<br />
** AutoBackupScript: '''String'''. File path to an executable script or binary to run when an automatic backup is taken. argv[1] of the executed file/script will be the file name of the generated OAR.<br />
<br />
=== Busy Heuristics ===<br />
<br />
PROCRASTINATE means "don't save an OAR right now; wait '''AutoBackupInterval / 2''' minutes and then try again."<br />
PROCEED means "try the next heuristic" -- all heuristic conditions must evaluate to "PROCEED" to actually save an OAR.<br />
<br />
* Ideas for busy heuristics include:<br />
** Is the Time Dilation at the present time < 0.50? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupDilationThreshold''' to allow the user to set the minimum time dilation required for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Are there more than 10 Main Agents on the region right now? If so, PROCRASTINATE. Otherwise, PROCEED. At the risk of option bloat, introduce '''AutoBackupAgentThreshold''' to allow the user to set the maximum number of agents that can be present for a PROCEED on this heuristic. Implementation difficulty: '''Low'''. Performance cost: '''Low'''.<br />
** Avatar "density" (calculated by the average proximity between avatars on the sim)? This seems expensive for a test to avoid a big performance hit, so we may not want to do this. But this would be a pretty good heuristic for smartly detecting meetings and events, since that usually involves avatars in relatively close proximity. Implementation difficulty: '''Medium'''. Performance cost: '''Unknown/High'''.<br />
<br />
=== Reducing Impact Of OAR Backup ===<br />
<br />
This is slightly out of the scope of this feature, but it could certainly ease acceptance of this feature and make the general practice of saving OARs more acceptable on busy sims, which would in turn reduce the need for the heuristics, and allow more users to set AutoBackupBusyCheck = False and not worry about it. Here are a few brainstormed ideas for improving the performance of OAR saving; this might even belong in its own feature proposal:<br />
<br />
* Faster compression. Use a lower compression ratio for Gzip, or use a faster algorithm like LZO. Reference credible papers on lossless compression performance; find the codec with a compatibly-licensed implementation (BSD/MIT) with the least compression performance cost; implement. Changing the OAR file format might require some kind of transition, e.g., detect which format the `load oar' is in, and automatically support both Gzip and the new format (whichever that turns out to be). That shouldn't be too hard with the use of extremely conspicuous file format magic numbers that are very common with these formats.<br />
* JSON instead of XML. I've heard from sources in the embedded world that you can save quite a lot of CPU cycles by using JSON instead of XML, because there are fewer and less complex structural elements to parse (on the read) and generate (on the write).<br />
* Faster asset serialization -- this is probably where a lot of the time is consumed, writing out assets. We should really profile this code and figure out where most of the time is spent. Are images being encoded into compressed file formats, and then compressed again in the OAR? Note that compressing already-compressed data is a spectacular waste of time, because you bring out worst-case behavior in the outer compression codec as it tries to extract a little more entropy out of the already-compressed data. Usually it ends up making the file size even larger due to file format overhead.<br />
** My recommendation is that we leave already-compressed assets as-is and just tar them up together, and have a .gz file inside the tar with the compressible data, like XML or JSON. This will minimize file size and possibly speed up compression, since the outer compression codec won't have to sweat the high-entropy compressed data.<br />
* Use the operating system scheduler to our advantage. Instead of writing the GZipStream data as quickly as possible, use asynchronous writes, and put some yields in at appropriate places. This would effectively make the archive process take longer, but give up some scheduling slots for other threads to execute. The other option would be to offload the most resource-intensive parts of the operation to a separate process (e.g. compression), and set that process's scheduling priority to minimal. The improvement you'd see from this would be extremely dependent on the OS: on Windows, starting a process has an extremely high overhead, especially with virus scanners and having to load another instance of .NET. Recent Linux 2.6 is much more efficient at sharing data and spawning processes quickly, and low priority scheduling has a noticeable impact on resource usage on Linux.<br />
* Amortize the cost of preparing data for archiving by using spare cycles to prepare the assets' memory stream. This could open up a whole different opportunity for activity-based backup scheduling: when the region is at a particularly low point of activity, you could just take a backup whenever you are able to reach a high level of confidence that things are not busy.</div>Allquixotichttp://opensimulator.org/wiki/Feature_ProposalsFeature Proposals2011-02-18T14:41:38Z<p>Allquixotic: formatting</p>
<hr />
<div>= Feature Proposals =<br />
<br />
This is a list of feature proposals for future work on OpenSimulator. <br />
<br />
The purpose of feature proposals is to provide a semi-formal "write-up" of features that are actively being investigated/worked on, for developers and power users to read and provide feedback. The criteria for creating a Feature Proposal should be the following:<br />
<br />
* The feature should be as modular as possible, and designed in such a way as to have minimal intrusiveness on the rest of the system.<br />
* The feature proposal should pertain only to OpenSimulator. You may mention how this will affect other software (such as viewers), but technical details and progress should remain focused on OpenSimulator.<br />
* The feature should have at least one developer sponsor. Users (who are not also developers) wishing to request a new feature may do so on Mantis.<br />
* The feature should be software-oriented, not content-oriented. Content creation has its own section on the Wiki and elsewhere.<br />
* The feature should not describe a '''defect''' in the software. A defect is where a feature ''has'' been implemented, and ''should'' work correctly, but due to technical difficulties it doesn't work properly or at all.<br />
* The feature should require at least a few hours of work for a seasoned developer. Items that can be trivially completed should be submitted as a bug on Mantis, or come up with a patch outright.<br />
<br />
The general process of developing a new feature can be described as follows:<br />
<br />
1. Get an idea.<br />
<br />
2. Refine the idea, and brainstorm on how it could be implemented technically.<br />
<br />
3. Write up a feature proposal describing in detail how you would implement the idea in OpenSimulator.<br />
<br />
4. Solicit user and developer feedback about the idea: is it generally useful? Is the design clean and modular? Is there sufficient interest to warrant the work, versus the implementation difficulty?<br />
<br />
5. Incorporate feedback into proposal as necessary.<br />
<br />
6. Implement feature, updating proposal as necessary.<br />
<br />
7. ???<br />
<br />
8. Get feature merged to trunk.<br />
<br />
9. Update feature proposal page one last time, indicating completion, and providing links (if any) to user documentation describing the final instructions for how to use the feature.<br />
<br />
== Active Feature Proposals ==<br />
<br />
These feature proposals are actively being worked on. This just means that the developer sponsor(s) consider the feature a work in progress; they intend to complete the feature; and we are still able to contact them. "Active" status has nothing to do with the frequency of code commits, and everything to do with the intentions of the developer sponsor(s).<br />
<br />
*[[Feature_Proposals/AutoBackup|AutoBackup]]<br />
<br />
== Stalled Feature Proposals ==<br />
<br />
These are feature proposals that have been abandoned, either voluntarily by the developer sponsor(s), or due to other reasons. A stalled feature proposal can and should be resumed by volunteer developers who find the proposal to be worthy of their time and effort, because we are reasonably certain that the original developer is no longer working on the feature.<br />
<br />
== Completed Feature Proposals ==<br />
<br />
The features listed below are here for historical reasons, but they are done and implemented into OpenSim in some form or another.<br />
<br />
<br />
== Example Feature Proposal ==<br />
<br />
Here is an [[Feature_Proposals/Example|Example]] feature proposal. Feel free to deviate from this format, but I found that it works for me.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/AutoBackupFeature Proposals/AutoBackup2011-02-18T14:24:18Z<p>Allquixotic: New page: = Automatic Region Backup = == Basic Info == * '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini. * '''Developer Sponso...</p>
<hr />
<div>= Automatic Region Backup =<br />
<br />
== Basic Info ==<br />
<br />
* '''Summary''': A new module for periodically saving per-region backup OARs according to rules defined in Regions.ini.<br />
* '''Developer Sponsor(s)''': [http://opensimulator.org/wiki/User:Allquixotic allquixotic]<br />
* '''Start Date''': February 18, 2011<br />
* '''Branches Targeted''': git master<br />
* '''Commercial''': No<br />
* '''Code Repository''': https://github.com/allquixotic/opensim-autobackup<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
Currently, saving OARs in an organized manner requires significant hackery in the way of scripts or other external wrappers. This project is an attempt to get automatic OAR backup as a core capability of OpenSim.<br />
<br />
* On a '''Per-Region''' basis, we want to give the user the opportunity:<br />
** To enable/disable automatic periodic backups of their region to an OAR.<br />
** To specify the length of time between automatic backups.<br />
** To invoke an external shell script or binary when a backup is taken (e.g. to transport to an offsite backup over FTP or S3).<br />
** To choose between overwriting a single file over and over, or saving a series of files whose name includes the timestamp of the OAR.<br />
** To enable or disable some simple logic that attempts to determine whether the sim is "busy", in which case no backup will be taken (because starting a backup can cause performance degradation).<br />
<br />
Just to emphasize, all of these choices will be available completely separately for each region, regardless of whether the regions run in multiple instances or in one instance.<br />
<br />
Ideally, users will be able to customize these settings in Regions.ini to conveniently specify when to take backups, and for which regions.<br />
<br />
=== Criteria ===<br />
<br />
* '''Scope''': The primary focus of the feature will be a new region module that keeps track of when regions need to be OARed, and other various state as gleaned from Regions.ini.<br />
* '''Software Requirements''': No additional third-party dependencies or version bumps will be required.<br />
* '''Impact''': The only existing modules that could conceivably be affected are the IRegionArchiverModule, and any files dealing with the options in the Regions.ini config file.<br />
* '''Blockers''': No blockers yet, but I'm sure as time goes on...<br />
<br />
=== Implementation Overview ===<br />
<br />
* Proposed Module Name: IRegionAutoBackupModule<br />
* Functionality Pseudocode:<br />
** Parse out the options from Regions.ini for each region<br />
** Set timers to wake up when the elapsed time for each region has expired. ''Optimization'': Merge timers into one with a list of regions to process if the time is the same. Cuts down on the number of timers.<br />
** In a timer handler:<br />
*** If the user wants us to check for busy conditions, then go through the conditions and make sure they all pass. Haven't determined what those conditions should be yet, but an obvious start is to set a reasonable avatar threshold, and examine the sim time dilation. If there are either "a lot" of avatars, or "a very low" time dilation, we probably don't want to kill the sim with an oar backup right now. But the user can bypass our logic if they want. Maybe we could add yet more options for the thresholds themselves, if we settle on e.g. time dilation and avatar count.<br />
*** If we checked some conditions and one or more of them failed, put off the oar backup for (interval / 2) seconds and then try again, where "interval" is the original interval specified in Regions.ini, not the interval we were just asleep for.<br />
*** Else: 1. Get the Scene object for the region(s) associated with this timer; get the IRegionArchiverModule interface; call HandleSaveOarConsoleCommand (or one of the other functions in the module?). The file name will either be the name of the region + ".oar", or the name of the region + a friendly-formatted timestamp + ".oar".<br />
*** 2. Invoke the shell script associated with the region's backup event, as given in Regions.ini. Possible security issue, but then, allowing sysadmins to set threat level severe is not exactly secure...<br />
*** 3. Reset the timer.<br />
<br />
The only functions that other modules need to call into this one will be the initialization stuff: creating the implementation object and setting it up to do its work. Then it basically runs in an infinite loop, periodically doing stuff. I anticipate being able to do everything in a single thread, but I'm not sure how threading is worked into the other modules. In particular, I need to know if IRegionArchiverModule is thread-safe, or if I need to enter into a specific thread or take some locks to use it.<br />
<br />
=== User Experience ===<br />
<br />
This shouldn't be visible to end-users at all, but it will be very visible to OpenSim sysadmins. Sysadmins will edit Regions.ini to manage the config settings on a per-region basis. Maybe, for user-friendliness, we can have global config options in OpenSim.ini that serve as "default" options for the ones in Regions.ini, if they are not specified. The default will be to disable auto-backup altogether, but if a user enables auto-backup without specifying any other auto-backup config options, it'd be nice if they could set the rest of the options globally in OpenSim.ini. This would reduce the size of Regions.ini for very large numbers of regions, and make it trivial to merge the timers into one.<br />
<br />
== Low-Level Design ==<br />
<br />
TBD! I am still learning about the OpenSim architecture, so pardon any layering violations / false assumptions I've made in my write-up :)</div>Allquixotichttp://opensimulator.org/wiki/User:AllquixoticUser:Allquixotic2011-02-18T13:55:56Z<p>Allquixotic: </p>
<hr />
<div>== About Me ==<br />
<br />
* 25 years old<br />
* Male<br />
* From Maryland, USA<br />
* Software Engineer / Information Security Engineer<br />
* Wide array of interests spanning most software development domains<br />
* Focussed knowledge in GNU/Linux, Gstreamer, GTK+, Java, C#, and TCP/IP networking and protocols<br />
* Have worked in a general IT setting; in a software engineering setting for smartphones; and presently in information security<br />
<br />
== Contact ==<br />
<br />
* IRC (freenode): allquixotic<br />
* Email: smcnam. Oh, you were wondering what domain I'm at, too, weren't you? Well, you'd have be a pretty smart spambot to get this far! I use Google's e-mail service -- the shortened version of "googlemail".<br />
* Yahoo: Same as IRC<br />
* Google Talk/Jabber: Same as Email<br />
* Secondlife (Agni) and OSgrid: Tiyuk Quellmalz<br />
<br />
== Why? ==<br />
<br />
Why am I interested in OpenSim? Because it's very hackable, being a high-level language with automatic memory management and objects, and written in a very modular way; and because I run a bunch of sims on OSgrid that I want to help flourish. Turns out we could really use certain features to get our sims working well, so I'm willing to put in the effort.</div>Allquixotichttp://opensimulator.org/wiki/User:AllquixoticUser:Allquixotic2011-02-18T13:55:24Z<p>Allquixotic: New page: == About Me == * 25 years old * Male * From Maryland, USA * Software Engineer / Information Security Engineer * Wide array of interests spanning most software development domains * Focuss...</p>
<hr />
<div>== About Me ==<br />
<br />
* 25 years old<br />
* Male<br />
* From Maryland, USA<br />
* Software Engineer / Information Security Engineer<br />
* Wide array of interests spanning most software development domains<br />
* Focussed knowledge in GNU/Linux, Gstreamer, GTK+, Java, C#, and TCP/IP networking and protocols<br />
* Have worked in a general IT setting; in a software engineering setting for smartphones; and presently in information security<br />
<br />
== Contact ==<br />
<br />
* IRC (freenode): allquixotic<br />
* Email: smcnam. Oh, you were wondering what domain I'm at, too, weren't you? Well, you'd have be a pretty smart spambot to get this far! I use Google's e-mail service -- the shortened version of "googlemail".<br />
* Yahoo: Same as IRC<br />
* Google Talk/Jabber: Same as Email<br />
<br />
== Why? ==<br />
<br />
Why am I interested in OpenSim? Because it's very hackable, being a high-level language with automatic memory management and objects, and written in a very modular way; and because I run a bunch of sims on OSgrid that I want to help flourish. Turns out we could really use certain features to get our sims working well, so I'm willing to put in the effort.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/ExampleFeature Proposals/Example2011-02-18T13:36:51Z<p>Allquixotic: </p>
<hr />
<div>= Example Feature =<br />
<br />
(''Guideline text is in italics like this.'')<br />
<br />
(''Please '''do not''' edit this example directly; instead, make a copy of the page from the edit window, and start your own page under the Feature_Proposals section!'')<br />
<br />
== Basic Info ==<br />
<br />
(''You should be able to completely fill out this section during your first edit of your proposal.'')<br />
<br />
* '''Summary''': (''A one- or two-sentence description of what your feature does. Be VERY brief!'')<br />
* '''Developer Sponsor(s)''': (''Your Wiki name, email, etc.'')<br />
* '''Start Date''': (''The date when you first started work on this feature'')<br />
* '''Branches Targeted''': (''e.g. trunk, 0.6.x, etc.'')<br />
* '''Commercial''': (''Yes/No: Is this feature directly driven by a business or commercial venture running on OpenSimulator?'')<br />
* '''Code Repository''': (''A repository URL (SVN or Git preferred) where interested parties can get your code. If you haven't committed anything yet, that's fine; but please at least create your repository and make it public before you submit your proposal.'')<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
(''This is where you pitch your idea in detail. Paragraphs of prose, bullet points, and so forth are appropriate here. At a minimum, you should cover the following bases:<br />
* What the purpose of the feature is<br />
* Why users would want to use the feature<br />
* Describe how users would use the feature in the ideal scenario<br />
* Describe the status quo, i.e. what users currently have to live with'')<br />
<br />
=== Criteria ===<br />
<br />
(''This is where you draw a box around the bounds of your project, letting us know where your feature starts and ends, how it impacts the rest of the system, etc. A few examples are provided.'')<br />
<br />
* '''Scope''': (''Define what is and isn't within the scope of work you are willing to take on as part of the feature implementation.'')<br />
* '''Software Requirements''': (''Mention any new third-party dependencies, version bumps or build system changes that would be necessary for implementation.'')<br />
* '''Impact''': (''List which existing modules in the code-base may have to be modified to integrate with your feature.'')<br />
* '''Blockers''': (''List any open issues, outside the scope of your feature, which may be required or strongly recommended before your feature can integrate with the rest of the system. Bonus points for links to Mantis bugs!'')<br />
<br />
=== Implementation Overview ===<br />
<br />
(''This is where you can start to think about things like: naming your module(s) and interface(s), defining an API, and describing how other modules in the system should change to work with your code. Including Unified Modelling Languages (UML) diagrams for complex systems is much appreciated!'')<br />
<br />
=== User Experience ===<br />
<br />
(''How will the user interact with your feature? Assume that there is a compiled binary distribution of OpenSim with your fully-implemented feature, and assume an audience of a reasonably-experienced OpenSim sysadmin who is not necessarily experienced with software development. You should document things like console commands, configuration settings, script functions, etc. in this space.'')<br />
<br />
== Low-Level Design ==<br />
<br />
(''Your actual code will be in your repository, but you can include additional details on design here if you want. For example, if your module exposes a complex API that other modules will want to use, you can list that API here. Other developers may be interested in working with you to revise the API before you start working on the implementation.'')</div>Allquixotichttp://opensimulator.org/wiki/Feature_ProposalsFeature Proposals2011-02-18T13:35:15Z<p>Allquixotic: New page: = Feature Proposals = This is a list of feature proposals for future work on OpenSimulator. The purpose of feature proposals is to provide a semi-formal "write-up" of features that are ...</p>
<hr />
<div>= Feature Proposals =<br />
<br />
This is a list of feature proposals for future work on OpenSimulator. <br />
<br />
The purpose of feature proposals is to provide a semi-formal "write-up" of features that are actively being investigated/worked on, for developers and power users to read and provide feedback. The criteria for creating a Feature Proposal should be the following:<br />
<br />
* The feature should be as modular as possible, and designed in such a way as to have minimal intrusiveness on the rest of the system.<br />
* The feature proposal should pertain only to OpenSimulator. You may mention how this will affect other software (such as viewers), but technical details and progress should remain focused on OpenSimulator.<br />
* The feature should have at least one developer sponsor. Users (who are not also developers) wishing to request a new feature may do so on Mantis.<br />
* The feature should be software-oriented, not content-oriented. Content creation has its own section on the Wiki and elsewhere.<br />
* The feature should not describe a '''defect''' in the software. A defect is where a feature ''has'' been implemented, and ''should'' work correctly, but due to technical difficulties it doesn't work properly or at all.<br />
* The feature should require at least a few hours of work for a seasoned developer. Items that can be trivially completed should be submitted as a bug on Mantis, or come up with a patch outright.<br />
<br />
The general process of developing a new feature can be described as follows:<br />
<br />
1. Get an idea.<br />
2. Refine the idea, and brainstorm on how it could be implemented technically.<br />
3. Write up a feature proposal describing in detail how you would implement the idea in OpenSimulator.<br />
4. Solicit user and developer feedback about the idea: is it generally useful? Is the design clean and modular? Is there sufficient interest to warrant the work, versus the implementation difficulty?<br />
5. Incorporate feedback into proposal as necessary.<br />
6. Implement feature, updating proposal as necessary.<br />
7. ???<br />
8. Get feature merged to trunk.<br />
9. Update feature proposal page one last time, indicating completion, and providing links (if any) to user documentation describing the final instructions for how to use the feature.<br />
<br />
== Active Feature Proposals ==<br />
<br />
These feature proposals are actively being worked on. This just means that the developer sponsor(s) consider the feature a work in progress; they intend to complete the feature; and we are still able to contact them. "Active" status has nothing to do with the frequency of code commits, and everything to do with the intentions of the developer sponsor(s).<br />
<br />
*[[Feature_Proposals/AutoBackup|AutoBackup]]<br />
<br />
== Stalled Feature Proposals ==<br />
<br />
These are feature proposals that have been abandoned, either voluntarily by the developer sponsor(s), or due to other reasons. A stalled feature proposal can and should be resumed by volunteer developers who find the proposal to be worthy of their time and effort, because we are reasonably certain that the original developer is no longer working on the feature.<br />
<br />
== Completed Feature Proposals ==<br />
<br />
The features listed below are here for historical reasons, but they are done and implemented into OpenSim in some form or another.<br />
<br />
<br />
== Example Feature Proposal ==<br />
<br />
Here is an [[Feature_Proposals/Example|Example]] feature proposal. Feel free to deviate from this format, but I found that it works for me.</div>Allquixotichttp://opensimulator.org/wiki/Feature_Proposals/ExampleFeature Proposals/Example2011-02-18T13:34:56Z<p>Allquixotic: Created example feature proposal</p>
<hr />
<div>= Example Feature =<br />
<br />
(''Guideline text is in italics like this.'')<br />
<br />
== Basic Info ==<br />
<br />
(''You should be able to completely fill out this section during your first edit of your proposal.'')<br />
<br />
* '''Summary''': (''A one- or two-sentence description of what your feature does. Be VERY brief!'')<br />
* '''Developer Sponsor(s)''': (''Your Wiki name, email, etc.'')<br />
* '''Start Date''': (''The date when you first started work on this feature'')<br />
* '''Branches Targeted''': (''e.g. trunk, 0.6.x, etc.'')<br />
* '''Commercial''': (''Yes/No: Is this feature directly driven by a business or commercial venture running on OpenSimulator?'')<br />
* '''Code Repository''': (''A repository URL (SVN or Git preferred) where interested parties can get your code. If you haven't committed anything yet, that's fine; but please at least create your repository and make it public before you submit your proposal.'')<br />
<br />
== High-Level Design ==<br />
<br />
=== Idea ===<br />
<br />
(''This is where you pitch your idea in detail. Paragraphs of prose, bullet points, and so forth are appropriate here. At a minimum, you should cover the following bases:<br />
* What the purpose of the feature is<br />
* Why users would want to use the feature<br />
* Describe how users would use the feature in the ideal scenario<br />
* Describe the status quo, i.e. what users currently have to live with'')<br />
<br />
=== Criteria ===<br />
<br />
(''This is where you draw a box around the bounds of your project, letting us know where your feature starts and ends, how it impacts the rest of the system, etc. A few examples are provided.'')<br />
<br />
* '''Scope''': (''Define what is and isn't within the scope of work you are willing to take on as part of the feature implementation.'')<br />
* '''Software Requirements''': (''Mention any new third-party dependencies, version bumps or build system changes that would be necessary for implementation.'')<br />
* '''Impact''': (''List which existing modules in the code-base may have to be modified to integrate with your feature.'')<br />
* '''Blockers''': (''List any open issues, outside the scope of your feature, which may be required or strongly recommended before your feature can integrate with the rest of the system. Bonus points for links to Mantis bugs!'')<br />
<br />
=== Implementation Overview ===<br />
<br />
(''This is where you can start to think about things like: naming your module(s) and interface(s), defining an API, and describing how other modules in the system should change to work with your code. Including Unified Modelling Languages (UML) diagrams for complex systems is much appreciated!'')<br />
<br />
=== User Experience ===<br />
<br />
(''How will the user interact with your feature? Assume that there is a compiled binary distribution of OpenSim with your fully-implemented feature, and assume an audience of a reasonably-experienced OpenSim sysadmin who is not necessarily experienced with software development. You should document things like console commands, configuration settings, script functions, etc. in this space.'')<br />
<br />
== Low-Level Design ==<br />
<br />
(''Your actual code will be in your repository, but you can include additional details on design here if you want. For example, if your module exposes a complex API that other modules will want to use, you can list that API here. Other developers may be interested in working with you to revise the API before you start working on the implementation.'')</div>Allquixotic