3 ms·
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
by erikpukinskis 8y ago
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.
- a1369209993 8y ago> 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 8y agoThat’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 8y agoStep 0) is be an Intel or AMD. Nobody else has the money to do what you're talking about.
- rys 8y agoTake 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).