[erikpukinskis]

I would approach it like this:

1) find some graphics problems which people say are not possible on any near-term hardware

2) study the algorithms and identify low level calculations which, if you could do orders of magnitude more of them, would allow you to solve the problem.

3) get a bunch of FPGAs and try to design a machine which can (very slowly) run that architecture

4) once you’ve got it working, slowly replace the FPGAs with ASICs

5) build a box with 16-64 of everything.

I would avoid polygons, since the current architectures are all extremely good at filling polygons. SDFs and raytracing are where you may find the “not on current gen” problems.

[rys]

Take a look at the game Claybook. Fully raytraced visuals at 60fps against a dynamically updated SDF scene representation, complete with fluid sim for the main game mechanics. All on current hardware, including stuff most people consider “slow” these days (Xbox One).

[a1369209993]

> SDFs and raytracing

An easy one would be: have each GPU raytrace a (say) 320x240 scene, each offset by fractions-of-a-pixel[0] or multiples-of-a-screen from each other, then have a final GPU stitch them together into a full-res video.

0: If you this with 60x1080 resolution, you might be able to replace the final GPU with a dumb hardware multiplexer, though that would make compositing painful at best.

[jamesfmilne]

That’s literally what we used to do for our cluster colour grading systems for films.

We had hardware that the would merge DVI from up to 8 GPUs, in separate nodes, and produce a single image.

[gammatrigono]

Step 0) is be an Intel or AMD. Nobody else has the money to do what you're talking about.