Tuesday, September 16, 2014

::operator new[] overloading.

Let's try to run Foo and Bar classes under ARM Linux platform:


// Foo class
class Foo {
  public:
    Foo() { vec = my_value; }
    float32x4_t vec;
};

// Bar class
class Bar {
  public:
    Bar() { vec = my_value; }
    ~Bar() { } // this destructor is important
    float32x4_t vec;
};

// 16-byte alignment allocation
// this approach will work on all platforms!
void *operator new(size_t size) {
    return memalign(16,size);
}
void *operator new[](size_t size) {
    return memalign(16,size);
}

// everything is OK...
Foo *f0 = new Foo();
Bar *b0 = new Bar();
Foo *f1 = new Foo[1];

// Hello SIGBUS! where are you from?
Bar *b1 = new Bar[1];
// I'm from 8-byte cookie.

The f1 pointer has 16-byte alignment. But b1 pointer has 8-byte alignment. For a Bar class with non-default destructor compiler will save allocation size and class size inside the cookie.
The cookie size on non-__ARM_EABI__ platforms is max(sizeof(size_t) * 2,sizeof(Foo)).
The cookie size of __ARM_EABI__ platform is sizeof(size_t) * 2 and we can't change it.

We you should do with all your code which is using this approach on __ARB_EABI__??
The stupid straightforward solution is to return the wrong 8-byte alignment instead of 16-byte one for all Bar classes:


void *operator new[](size_t size) {
  #if defined(_LINUX) && defined(__ARM_EABI__)
    if(sizeof(size_t) == 4 && !IS_ALIGNED16(size)) {
      size += sizeof(size_t) * 2;
      return static_cast<size_t*>(memalign(16,size)) + 2;
    }
  #endif
  return memalign(16,size);
}

void operator delete(void *ptr) {
  #if defined(_LINUX) && defined(__ARM_EABI__)
    if(sizeof(size_t) == 4 && !IS_ALIGNED16(ptr)) {
      return free(static_cast<size_t*>(ptr) - 2);
    }
  #endif
  free(ptr);
}

Monday, June 17, 2013

Oculus Rift compatible video with Unigine benchmarks without DOF effect and correct FOV:

Sunday, June 16, 2013

Oculus Rift compatible video with Unigine benchmarks:

Thursday, February 21, 2013

Real-time 180-degree panorama rendering of new Unigine benchmarks:

Wednesday, October 12, 2011

Valley demo preview

Work in progress, upcoming demo of Unigine engine:

Friday, September 9, 2011

Unigine crew links

We are still unsure regarding the format of this blog, so you can track some stuff regarding Unigine crew in the following places for now:

PS: by the way, check out our new shiny website: unigine.com

Monday, January 3, 2011

Global illumination II

The previous post about Global Illumination demonstrated a modification of real-time screen space ambient occlusion (SSDO) algorithm. This is a good post-processing effect for modern and powerful hardware. We use this approach in the new version of Heaven benchmark, which will be released soon. But low-level hardware still requires lightmaps...

I have improved lightmap rendering in Unigine by using directional lightmaps. They can be easily calculated by the engine render pipeline (simple ray tracing). Unfortunately the result of directional lightmaps without environment or indirect lighting looks ugly. So I created a tool for indirect lighting calculation. Our approach is very simple: we use built-in LightProb (light source based on spherical harmonics) facilities to grab environment lighting:
* we generate a heap of LightProb objects all across the scene
* each LightProb grabs nearby lighting info
* indirect component from LightProbs is combined with direct one from ray tracing into the lightmap textures

Performance of such global illumination solver is awesome. Calculation time for the shown scene (based on the old "Site" Unigine demo) is only 2-3 minutes on dual core PC. GPU power is also utilised during LightProb generation.

Dynamic forward lights:


Backed lightmaps with direct term:


Backed lightmaps with direct and indirect terms:


Backed lightmaps with indirect term:

Tuesday, November 23, 2010

Continuous Integration

We use TeamCity as a continuous integration server to build different configurations of Unigine engine, tools, SDKs and so on. We also use Trac as an issue tracker. The problem was lack of their native integration, but it's solved: Max wrote a TeamcityIntegration plugin, feel free to use it.

BTW, it takes about 5 minutes to make full rebuild of Unigine (engine+tools, both release and debug) on a Linux build node, while the Windows one (which has more powerful hardware) spends 12+ minutes for the same build type. So ccache rules, we do miss it for Visual Studio.

Thursday, October 21, 2010

Thursday, September 30, 2010