# Floating Point Operations in Line Drawing Algorithms

When it comes to line drawing, DDA is the simplest and most intuitive algorithm, the core idea being:

• compute the slope of the line
• for every increment in x, increment y by the slope

However, DDA is not favored due to its use of floating point operations. In fact, avoiding floating point operations is a common theme in graphics. I am wondering about the relative cost of floating point operations versus integer operations in modern GPU's

I could do some benchmarking but my CUDA is rusty. There is a question on SO and the common wisdom there seems to be, "it depends".

My question is specific to computer graphics and line drawing. If a more general answer can be given, that will also be appreciated.

To state my question specifically, is it important with modern GPU architectures to avoid floating point operations in favor of integer operations?

• Hi and welcome. Slightly offtopic but still worth knowing. Line drawing algorithms may be intuitive. But they tend to lead people astray when you move up this way to try to implement antialiasing. For these kinds of reasons antialiasing is essentially broken in mostly all 2D vector rendering engines. Apr 11, 2019 at 5:53
• @joojaa That's really interesting. Do you have a link where I could read more about that? Apr 12, 2019 at 2:29

is it important with modern GPU architectures to avoid floating point operations in favor of integer operations?

Almost certainly not. CPUs have a long history where for many years they only handled integers natively and floating point operations were all done with slow math libraries. That changed about 20-25 years ago, but the thinking has remained entrenched for many years. (And certain applications like finance may require it for other reasons.)

Modern GPUs, though, have always been about doing lots of floating point calculations in parallel. If you think about how most 3D rasterizers (like OpenGL, Metal, DirectX, etc.) work, they take all the vertices, transform them into normalized device coordinates, and then interpolate between them to draw the actual geometry. While you certainly could do that all with fixed point math, it probably wouldn't gain you much. But you also aren't doing those calculations yourself, unless you've written your own rasterizer as a compute kernel.

Now depending on what type of work you're doing, the precision of the floating point operations may be reduced. In a language like glsl (in OpenGL ES, anyway) you can specify the precision of the uniforms. On mobile hardware, it might be worth doing the calculations as floating point, but with only 16 or 24 bits instead of 32 because it saves power, for example. (And even some desktop GPUs have used lower-precision floating point in the past.) But the desktop hardware of today is optimized for doing floating point work.

In short, I don't see a compelling reason to stick to integer math when working on the GPU.

• It should be noted that, on the hardware-side, the picture will look different. GPU cores are purpose-built for floating point because they are there to run shaders and float is what shaders do. In fact, it's only recently that we're seeing integer performance on-par with float. So when we're talking about software on the GPU, float is king. I'm not a hardware engineer, but based on all I know, the cost of floating point in terms of area and power is much, much higher. So when you're building a hardware rasterizer, you will want to stick with fixed-point (i.e. integer) arithmetic if you can… Apr 13, 2019 at 1:42