Tag Archives: multi-core

Proposal for a graphics pipeline DSL

Geomerics are making a proposal to the UK Technology Stategy Board (TSB) for "disruptive technology" funding to germinate an idea we've been discussing for a long while now. The proposal is a very public one via a youtube video submission, and the "5th judge" will be public feedback! So I'm looking for as much input as possible to improve this idea. Naturally, this is funding proposal, rather than a tech one, so apologies if it's short on tech details.

UPDATE: The video has been submitted. Thanks to all that contributed! Please check it out and leave feedback on the TSB site - you are the 5th judge so your opinion matters!

Here is the final text for the 2 minute video.

Efficient Real-Time Graphics Through A Domain Specific Language

Parallel computing is the next major challenge for software development as chip manufacturing has hit physical limits that require us to go parallel to do more. However, writing parallel software is a hard problem, and requires a new approach.

Computer graphics leads parallel hardware development and is the best known parallel application. But the same hardware and software that drives the graphics in your modern PC is also used by the scientific and medical imaging communities. Advances in graphics frequently have a wider impact in these fields. But despite its apparent suitability, graphics still suffers from a serious programmability gap. There is not yet a good way of driving the hardware effectively. It is widely accepted that without further innovation, faster hardware will not deliver comparatively improved visual quality.

So our goal is to bridge the programmability gap for graphics. By doing so we will tap the unexploited potential of the new power-efficient parallel hardware, providing an important product for the games and graphics industry, while making progress into the wider parallel programming problem.

With full TSB funding, we would draw on our expertise to prototype an alternative graphics pipeline, taking the novel approach of structuring it as a domain specific language (DSL). We will show that new graphics algorithms can be efficiently developed in this language and provide solutions to a range of outstanding problems affecting game and graphics developers that are hard or impossible to realise with existing approaches.

These challenges include:
- higher fidelity images (anti-aliasing)
- cinematic lens effects (bokeh, depth of field)
- complex illumination and shadowing
- semi-transparent materials, such as glass or water
- volumetric rendering, such as fog and smoke

We intend to show a step-change in visual quality, and demonstrate a new parallel programming model with wider applicability. The TSB funding would allow us to build the foundation for a middleware product Geomerics would commercialise in the games and graphics industry. With partial funding we will scale the prototype to deliver a vertical slice focussing on a single rendering challenge.

With its worldwide reputation for game graphics, its close ties with hardware manufacturers and its relationships with academia, Geomerics is ideally placed to carry out this development.

There is some good background material on this topic from this year's Beyond Programmable Shading Course from SIGGRAPH 2010. Of particular relevance is, Johan Andersson's "5 Major Challenges in Interactive Rendering" - another crowd-sourced proposal.

Input and feedback appreciated! If you would prefer not to post publicly, feel free to email me directly (sam.martin@geomerics.com).

Haskell For Games!

I've been head-down in a big stack of papers since around March this year. That was the point at which I first started to get excited about the idea of Haskell becoming a plausible language for use in games development. More recently I decided to start doing something about it and gave a talk to a group of dedicated Haskellers at AngloHaskell 2009. The event turned out to be a lot of fun and I think it's safe to say the talk went pretty well. Here's the abstract.

Functional Languages in Games: Plotting the Coup

[Slides as PDF]

As a games developer by trade, my experience of the industry leads me to suspect games development is approaching a tipping point where functional languages could enact a successful coup. The revolution would claim a chunk of C++-owned territory for the victor and mark an important milestone in the development of functional languages. It will not be easy. Games development is notoriously demanding and the successful functional language would need to meet stringent performance requirements, have clearly demonstrable 'killer apps', jump through hoops of fire and tell jokes at parties. This talk will discuss how close Haskell is to meeting these demands, the challenges that remain, evidence of functional languages already in games, and how Haskell compares against its nearest competitors.

Haskell For Games!

At first glance it sounds like a crazy idea. One to file away with the other crazy ideas to replace C++ with Java/C#/Python/etc. Most alternatives to C++ are so unlikely to succeed in practice that they appear to taint the very idea of replacing C++. I've written before about my high regard for C++,  but as powerful and effective as it is for games development, it does not represent an impossible challenge and we don't have to look to replace it entirely. Finding it a suitable companion would be a major step forward and is the goal I'd choose to focus on.


There are powerful currents moving in modern computer hardware, pulling us inevitably into murky multi-core waters. However this movement also begins to make the idea of doing games development in an alternative language more plausible. What do we do when large multi-core systems become a standard hardware platform? (A reality that I note is only a handful of years away.) I have yet to see a parallelisation option that don't make me think life in this new age in C++ will be rather hard. And would it be any easier in C# or Java? No. Multi-core life there will likely be just as tough. However, these aren't the only options.

Functional languages

I'm far from the first to notice this, but pure functional languages - as opposed to the imperative languages most of us are used to - do at least have a theoretical advantage. Pure functional code does not have side effects. If you call it with the same parameters you will always get the same answer. It is thread-safe at a fundamental level giving opportunities for optimisation and parallel evaluation that are either infeasible or impossible with imperative code. They aren't so alien as you may immediately think. You may well already work with such a language without really realising it. Ignoring some syntactical obfuscations, both CG and HLSL are essentially pure, referentially transparent languages. Neither language can wipe your hardrive or save state in global variables, and it's no coincidence that they both optimise exceptionally well.

As you can well imagine, this is not an open-and-shut success case. Achieving good parallelism, even from a functional starting point, is still hard. In the previous example of CG/HLSL, the hard parallelism work is still done by the programmer by setting up the GPU pipeline, rather than magically derived from the CG/HLSL. Doing complicated, dependent operations in a GPU architecture is tricky and the subject of many GPGPU articles, although to be fair many of these obstacles are due to the current GPU architecture than the more fundamental issues in utilising parallelism.

Achieving parallel code that includes grubby details like nesting and runtime data dependencies are hard problems. But in the long term I think it's more plausible to turn these problems into successes in functional languages than anywhere else. Compiler-parallelised code, even if partly programmer controlled, would be a Killer App for any alternative language, and one feature that C++ is unlikely to ever have. Without this feature, there are many other benefits for games development to adopt a functional sister-language, but the cost of doing so may cancel out the cost of the adoption.

Multi-core Haskell

I'm championing Haskell from the functional language pack for a variety of reasons, several of which are noted briefly in my talk and the rest I'll expand on further in the future. I hope many of the benefits of Haskell will be apparent to anyone prepared to spend the time learning it, and I'd urge anyone interested to get stuck in immediately. There are several decent tutorials referenced from the Haskell Wiki, and I can highly recommend, "Learn You A Haskell For Great Good!", as a great starting point. One other very notable highlight is the on-going research into extending the language to support Nested Data Parallelism. Although not complete, this research does look very promising and where I'm hoping some of the magic may take place.

Haskell for Games is by no means a done deal, but my enthusiasm for this project has at least withstood it's first challenge - presenting these ideas to members of the Haskell community - and if anything has grown as a result.