Is SpriteBatch Turing complete?

Is SpriteBatch Turing complete?

  • Comments 6

Time for some end-of-year silliness...

Inspired by this recent Twitter exchange:

Scionwest - @shawnhargreaves @nickgravelyn How about post processing for WP7? I've seen people do Bloom effects and thought P.P. was not part of WP7?

nickgravelyn - @Scionwest Shaders aren't available, but I've seen some clever post-processing done without custom shaders.  You theoretically could do CPU based "shaders", but you can also use blend states in fun ways to achieve effects

(which is actually an interesting topic that I may someday return to)

I found myself thinking "well, of course you could implement bloom, because the no-programmable-shaders Reach graphics subset on Windows Phone is Turing complete, so can do anything you can imagine given sufficient ingenuity. It might not be easy, efficient, or sensible, but anything is possible..."

And then I found myself thinking, is that really true?

We can add and subtract via blend states, and perform comparisons with AlphaTestEffect, which seems like it should be enough to enable arbitrary algorithms (at least if we ignore mundane practicalities such as time and space constraints :-)  But can I prove that XNA on Windows Phone is enough to enable Turing complete GPU computation?

Conway's Game of Life is already proven to be a form of universal Turing machine, so I set out to see if I could implement that on the GPU without custom shaders.

Starting with the default Game template, I declared two rendertargets to hold the state of my simulation:

    const int width = 256;
    const int height = 128;

    RenderTarget2D currentState;
    RenderTarget2D nextState;

Plus two helper objects:

    AlphaTestEffect alphaTestEffect;

    Texture2D singleWhitePixel;

These are initialized in LoadContent:

    currentState = new RenderTarget2D(GraphicsDevice, width, height, false, SurfaceFormat.Color, DepthFormat.Depth24Stencil8);
    nextState    = new RenderTarget2D(GraphicsDevice, width, height, false, SurfaceFormat.Color, DepthFormat.Depth24Stencil8);

    alphaTestEffect = new AlphaTestEffect(GraphicsDevice);

    singleWhitePixel = new Texture2D(GraphicsDevice, 1, 1);
singleWhitePixel.SetData(new Color[] { Color.White });

In order for it to do anything interesting, the Game of Life must be initialized to more than just zeros. This code (at the end of LoadContent) creates a single glider that will move diagonally across the screen:

    Color[] initialData = new Color[width * height];

    initialData[3 + 1 * width] = Color.White;
    initialData[3 + 2 * width] = Color.White;
    initialData[3 + 3 * width] = Color.White;
    initialData[2 + 3 * width] = Color.White;
    initialData[1 + 2 * width] = Color.White;

    currentState.SetData(initialData);

For a more interesting initial state, add this (before the currentState.SetData call) to randomize the cells:

    Random random = new Random();

    for (int i = 0; i < 10000; i++)
    {
        initialData[random.Next(width * height)] = Color.White;
    }

My Draw code is simple.  It uses SamplerState.PointClamp to scale up the current simulation state to fill the entire screen, without any filtering:

    SimulateLife();

    GraphicsDevice.Clear(Color.CornflowerBlue);

    spriteBatch.Begin(SpriteSortMode.Deferred, null, SamplerState.PointClamp, null, null);
    spriteBatch.Draw(currentState, GraphicsDevice.Viewport.Bounds, Color.White);
    spriteBatch.End();

Ok, that's the boilerplate taken care of.  How are we actually going to implement this SimulateLife method?  Wikipedia defines the rules as:

Any live cell with fewer than two live neighbours dies, as if caused by under-population
Any live cell with two or three live neighbours lives on to the next generation
Any live cell with more than three live neighbours dies, as if by overcrowding
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction

But I found it useful to rearrange this to a different (equivalent) form:

Rule 1:  If there are two live neighbours, preserve the current state of the cell
Rule 2:  If there are three live neighbours, set the cell to alive
Rule 3:  Otherwise set the cell to dead

Ok, let's do it!  SimulateLife starts by drawing onto the nextState rendertarget, and setting up the AlphaTestEffect to only accept pixels with alpha greater than 128, i.e.. cells that are currently alive:

    GraphicsDevice.SetRenderTarget(nextState);

    GraphicsDevice.Clear(Color.Transparent);

    Viewport viewport = GraphicsDevice.Viewport;

    Matrix projection = Matrix.CreateOrthographicOffCenter(0, viewport.Width, viewport.Height, 0, 0, 1);
    Matrix halfPixelOffset = Matrix.CreateTranslation(-0.5f, -0.5f, 0);

    alphaTestEffect.Projection = halfPixelOffset * projection;

    alphaTestEffect.AlphaFunction = CompareFunction.Greater;
    alphaTestEffect.ReferenceAlpha = 128;

We are going to count how many alive neighbours each cell has, accumulating this value in the stencil buffer (which was previously cleared to zero).  We do this by drawing the current simulation state texture 8 times, shifted one pixel to the top left, top, top right, left, etc.  We use a blend state that prevents drawing anything to the color buffer, because we are only interested in generating stencil values.  This code combines AlphaTestEffect (which rejects dead neighbour pixels) and the stencil buffer (which counts how many neighbour pixels pass the alpha test):

    spriteBatch.Begin(SpriteSortMode.Deferred, blendNone, null, stencilAdd, null, alphaTestEffect);

    spriteBatch.Draw(currentState, new Vector2(-1, -1), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 0, -1), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 1, -1), Color.White);
    spriteBatch.Draw(currentState, new Vector2(-1,  0), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 1,  0), Color.White);
    spriteBatch.Draw(currentState, new Vector2(-1,  1), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 0,  1), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 1,  1), Color.White);

    spriteBatch.End();

This uses two custom state objects:

    static readonly BlendState blendNone = new BlendState
    {
        ColorSourceBlend = Blend.Zero,
        ColorDestinationBlend = Blend.One,

        AlphaSourceBlend = Blend.Zero,
        AlphaDestinationBlend = Blend.One,

        ColorWriteChannels = ColorWriteChannels.None,
    };

    static readonly DepthStencilState stencilAdd = new DepthStencilState
    {
        DepthBufferEnable = false,
        StencilEnable = true,
        StencilFunction = CompareFunction.Always,
        StencilPass = StencilOperation.Increment,
    };

We now have our rendertarget cleared to zero (which means all dead, so we have already implemented rule #3),  while stencil contains a count of live neighbour cells.  It is but the work of a moment to draw a copy of the current simulation state, using stencil to only accept cells that have 2 live neighbours, thus implementing rule #1:

    spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.Opaque, null, stencilDrawIf2, null);
    spriteBatch.Draw(currentState, Vector2.Zero, Color.White);
    spriteBatch.End();

The last draw call implements rule #2 by rendering solid white (which means alive) over only those cells which have 3 live neighbours:

    spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.Opaque, null, stencilDrawIf3, null);
    spriteBatch.Draw(singleWhitePixel, viewport.Bounds, Color.White);
    spriteBatch.End();

This requires two new state objects:

    static readonly DepthStencilState stencilDrawIf2 = new DepthStencilState
    {
        DepthBufferEnable = false,
        StencilEnable = true,
        StencilFunction = CompareFunction.Equal,
        ReferenceStencil = 2,
    };

    static readonly DepthStencilState stencilDrawIf3 = new DepthStencilState
    {
        DepthBufferEnable = false,
        StencilEnable = true,
        StencilFunction = CompareFunction.Equal,
        ReferenceStencil = 3,
    };

Finally, the end of SimulateLife unsets our output rendertarget, then swap the two rendertargets, replacing the current state with the new one we just computed:

    GraphicsDevice.SetRenderTarget(null);

    Swap(ref currentState, ref nextState);

Swap is a handy little helper, implemented like so:

    static void Swap<T>(ref T a, ref T b)
    {
        T temp = a;
        a = b;
        b = temp;
    }

So, does it work?

image

Tada!  SpriteBatch is Turing complete :-)

Exercise for the reader: is it possible to do the same thing without using stencil?

  • Is it possible to do the same thing without using stencil? ... Yes  

    You would have to use alpha and do a bunch more copies in a tree structure I suppose.  I don't have time to implement this but I think it would work.

  • I believe it can be done with the same number of Draw calls, but an alpha-only implementation involves some less obvious tricksyness..

  • I think you lost your point somewhere. Yes you were able to implement a touring machine, but what relation does that have to being able to implement any shader effect with it? For that you'd need to be able to execute the touring program every frame, not just once, and you'd also need to be able to extract the output of the touring program.

    The mistake you made was stretching the touring-computation across an unlimited number of frames.

  • > but what relation does that have to being able to implement any shader effect with it?

    Theoretically, every relation. If a computational system is Turing complete, it can be used to implement any imaginable computation.

    In practice, no relation at all. This is a theoretical/joke/hack technique, not a sensible way to implement graphical rendering effects.

    > For that you'd need to be able to execute the touring program every frame, not just once, and you'd also need to be able to extract the output of the touring program.

    That's an irrelevant detail. Once you have a working algorithm, it's a trivial change whether you want to call it at 60 fps or some other rate, and where you want to send its output.

    It's 'Turing', not 'touring', btw.

  • Liked the read, most programmers can appreciate such theoretical subjects :D

  • Hehe awesome :) And you DID mention that it was a joke in your first line, not a way to implement bloom... :)

Page 1 of 1 (6 items)
Leave a Comment
  • Please add 8 and 1 and type the answer here:
  • Post