pouët.net

hi there,

i was wondering if its feasable to build a software rendering engine using gpu acceleration like cuda or openCL or whatever api is hot at the moment? maybe even for sound? would it make any sense?

I think Unreal's Nanite feature uses compute shaders to render when triangle density is really high (like 1 triangle per pixel). But please don't take my word for it and rather read up on official Nanite Powerpoints/videos/papers instead.

Not sure if you will have any luck with this method on mobile though, but I guess you are targeting destkop GPUs

Nanite uses compute shaders rather than hardware rasterization up to surprisingly big sizes (IIRC something like 64x64). Of course, a GPU “software” renderer will look very different from a single-threaded CPU software renderer, but it is doable, as Nanite shows. The presentation is fantastic (there's also a video).

The answer is yes, but whether it would "make any sense" (which likely means that the result has good performance and quality) depends on what you want to render. Generally though, a software rasterizer running on GPU is written for parallel execution and usually doesn't resemble the scanline-conversion type of rasterizer. That said, you can totally execute a CUDA kernel with just one active thread and do it that way if you want to.

I should clarify: It doesn't resemble the typical scanline-conversion type of rasterizer from the 90s.

GPUs are pretty good at this, so it only makes practical sense if you can exploit something the GPU can't or if you hit the GPU's limitations (e.g. lots and lots of tiny - perhaps subpixel - tris).

that said, i wrote a compute based rasteriser a few weeks ago :) it was for a special reason (rendering to lots of small buffers in parallel) and could use the advantage of only filling bit masks, not shading pixels - so it was worth doing in "software" compute.

See also: directx work graphs. AMD has a proof of concept polygon renderer on top of that.

https://gpuopen.com/learn/work_graphs_learning_sample/ there's the linky

Another way in which it would make sense if you want to render to a target which isn't the usual 2D framebuffer and would be too costly to force the GPU's pinhole-camera projection into rendering to. An example would be a 3D texture for a voxelisation. Also, there are hybrid approaches where the hardware-accelerated rasterisation is used essentially for coarse scheduling while the pixel shader does the per-pixel work, for example this can be used to quickly cull tiles of pixels for primary raytracing of implicit surfaces. As mentioned though, dynamic work generation in modern APIs provides a way to do that in compute anyway.

"Software rendering using GPU" ... this could be a big thing!! Instead of triangles etc you could do all kinds of things like raymarching, implicit surfaces, write your own shading and stuff. It could even be suitable for 4k intros. Someone should definitely try that.

*cough*larrabee*cough*

Just carve out the 3D-accelerator chip out of your graphics card and throw it in the bin. Then use directdraw to blit stuff to the drawing context directly.

You were probably thinking 3d but here's a 2D software gpu render

https://github.com/linebender/vello

are you saying that ddraw bypasses the gpu

I think we are confusing a Renderer with an Engine.

Unless you haven't paid attention to the last decade+ of intros and demos, you know you can implement a renderer in software in the GPU. Not only raymarchers, but people often do software rasterizers (for conservative z-prepasses), bypass their HW bilinear texture filtering with their own, same with custom blending modes etc. Basically, developers regularly bypass any piece of hardware with a custom software version, as needed.

An Engine on the other hand is a lot more than a renderer; it loads assets, builds a scenegraph, performs collisions, has an animation system... I imagine this is what the original question is about?

If so, I understand GPUs can do their own scheduling these days, but I haven't used it myself yet. But maybe one can indeed implement some sort of engine in the GPU, except for the asset loading since GPUs can't see the hard drive?

Hasn't Direct Draw been emulated in software since Windows Vista? My understanding is that this "direct blit to the drawing context" essentially is the CPU rendering to a buffer in system memory, which is then uploaded to video memory as a texture so the GPU can render it.

my question was mainly about skipping apis like dx/ogl or even vulkan while still using the gpu resources, but i see now its not that simple. some things are already calculated by other means on the gpu regardless of the gfx api and that may be more than it tought it is...

still one question remains: is it feasable to softsynth audio on the gpu? on the one hand its kinda linear and sequential but on the other hand its also pretty predictable so why not chunk it up and precalc everything into ram and then play the song? ;=)

Yes, yes it was, but never let reality intrude a comfortable delusion.

Yes, has been done in intros before afaik. I don't remember which ones exactly, though.

One of several examples: DC Offset

The earliest one that I could remember (from 2010): Bubblin Under (IIRC, it was written on the partyslide, but the comments also alude to it)

cpu:s are so crazy fast that it's hard to think of an audio case that would benefit from gpu rendering. I'm probably wrong, though.

Large FIR reverbs, for one.

Yes Adapt - Bubbin Under used a GPU based FM synth, though we ran out of time with it.