## ARM - Benchmarking floating-point precision in mobile GPUs

Started by Stefan, May 29, 2013, 10:56:58 PM

0 Members and 1 Guest are viewing this topic.

#### Stefan

QuoteWhen we talk about GPU performance (which we do a lot, here at Mali Central), we usually talk about speed. In previous blogs we've talked about how many pixels per second you can put on the screen, how many triangles per second you can pretend to draw (don't ask), and most recently, how many floating-point operations per second you can issue. Talking about speed is great fun, and we love doing it, but it isn't the only interesting GPU performance metric; quality also counts. After all, it doesn't matter how fast you compute something if you get the wrong answer. In my next few blogs, I'll let go (temporarily) of my obsession with speed, and talk about benchmarking the quality of GPU floating-point arithmetic. I have a lot to cover, so this is unavoidably long. Save it up for when you can concentrate.

But first, a rant...
Using floating point arithmetic is tricky. A lot of programmers, even some very good ones, don't really understand it. Quite innocent-looking pieces of code can turn around and bite you, and it is often very hard to figure out why you're getting bitten. That's a problem even when you're coding for nice, well-behaved, IEEE-754-compliant CPUs. When you're targeting devices with more, shall we say, character (cough GPUs cough), it's tempting to assume that anything strange you see is the result of some flaw in how they are doing arithmetic. But that is not necessarily the case; it could just be that your intuitive notion of what the result should be... is wrong.

If you're going to do anything remotely edgy with floating-point – and certainly, quality benchmarking falls into that category – you'd better get used to thinking about exactly what's happening inside the floating-point unit, which means understanding how floating-point works in a lot more detail than, perhaps, you really wanted to. Get over it, hacker!