4 ms·

The cost of doing this would be enormous - program shader for each pixel would have to calculate this function for every line segment. Instead, only triangles t

by m1el 9y ago

The cost of doing this would be enormous - program shader for each pixel would have to calculate this function for every line segment. Instead, only triangles that cover the segment are evaluated.

banachtarski 9y ago
no... it really depends on the function being evaluated and frag shaders operate in warps. Furthermore, on certain CPUs, vertex shading is emulated on the CPU which is worse than a fragment shader.
- dahart 9y ago
  I found an existing example of a similar algorithm to the OP's using a fragment shader: https://www.shadertoy.com/view/ldSfWV https://www.shadertoy.com/view/ldSfWV Notice that the default settings in the shader are 300 audio samples (lines) per frame, which is skipping 80% of the audio samples. You are right that it does depend on the function being evaluated. The function in this article is a set of ~22k arbitrary lines (~44k audio samples) per second, so the fragment shader has to calculate the distance to every line at every pixel. At 30fps, that's around 750 point-to-line distance calculations per pixel. So turn up the ShaderToy example to 750 iterations, and see how fast it goes. (#define NBITERATIONS 750 in Buf A) I tried that, and my GPU goes down to 10fps in the small window (~600x400) and about 1fps at full screen. And this shader is using a much cheaper intensity function than @m1el used. So, while it is possible to do this in a fragment shader at interactive speeds (especially if you skip samples), it is more expensive than drawing lines. Keep in mind that a full screen quad also has a greater fill rate than drawing thin lines. If there were a way to reduce the number of lines you have to check, then you might be right that a fragment shader would be faster. But in this particular case, there's no obvious way to quickly skip checking some of the lines, so drawing lines directly with quads is a lot faster than using a shader, even if vertex shading is CPU bound.

by m1el 9y ago

The cost of doing this would be enormous - program shader for each pixel would have to calculate this function for every line segment. Instead, only triangles that cover the segment are evaluated.

banachtarski 9y ago

no... it really depends on the function being evaluated and frag shaders operate in warps. Furthermore, on certain CPUs, vertex shading is emulated on the CPU which is worse than a fragment shader.

dahart 9y ago
I found an existing example of a similar algorithm to the OP's using a fragment shader: https://www.shadertoy.com/view/ldSfWV https://www.shadertoy.com/view/ldSfWV Notice that the default settings in the shader are 300 audio samples (lines) per frame, which is skipping 80% of the audio samples. You are right that it does depend on the function being evaluated. The function in this article is a set of ~22k arbitrary lines (~44k audio samples) per second, so the fragment shader has to calculate the distance to every line at every pixel. At 30fps, that's around 750 point-to-line distance calculations per pixel. So turn up the ShaderToy example to 750 iterations, and see how fast it goes. (#define NBITERATIONS 750 in Buf A) I tried that, and my GPU goes down to 10fps in the small window (~600x400) and about 1fps at full screen. And this shader is using a much cheaper intensity function than @m1el used. So, while it is possible to do this in a fragment shader at interactive speeds (especially if you skip samples), it is more expensive than drawing lines. Keep in mind that a full screen quad also has a greater fill rate than drawing thin lines. If there were a way to reduce the number of lines you have to check, then you might be right that a fragment shader would be faster. But in this particular case, there's no obvious way to quickly skip checking some of the lines, so drawing lines directly with quads is a lot faster than using a shader, even if vertex shading is CPU bound.