Random clang testing results

I tried building Blender with clang today for fun. Went without a hitch, although I had to use gcc for two files from ffmpeg with nasty inline asm. Blender has about 600k lines of C code internally, and another 600k from external libraries (like FFTW, ffmpeg, qhull, …).

Some results from comparing renders on the two binaries are here:
http://t1.minormatter.com/~ddunbar/blender/times.html

A lot of rendering artifacts, but it is remotely possible this is a Blender bug not a clang one. Several files show obvious flaws, on the other hand.

  • Daniel

Daniel Dunbar wrote:

I tried building Blender with clang today for fun. Went without a
hitch, although I had to use gcc for two files from ffmpeg with nasty
inline asm. Blender has about 600k lines of C code internally, and
another 600k from external libraries (like FFTW, ffmpeg, qhull, ...).

How do compile times compare?

Some results from comparing renders on the two binaries are here:
http://t1.minormatter.com/~ddunbar/blender/times.html
<http://t1.minormatter.com/~ddunbar/blender/times.html&gt;

A lot of rendering artifacts, but it is remotely possible this is a
Blender bug not a clang one. Several files show obvious flaws, on the
other hand.

These artifacts look like floating point inaccuracies to me. Could it be
that Clang generates code that makes these worse?

Sebastian

Daniel Dunbar wrote:

I tried building Blender with clang today for fun. Went without a
hitch, although I had to use gcc for two files from ffmpeg with nasty
inline asm. Blender has about 600k lines of C code internally, and
another 600k from external libraries (like FFTW, ffmpeg, qhull, …).

How do compile times compare?

I didn’t look; I’m close enough to having the new driver working that it isn’t worth trying to compare timings with the Python driver.

Some results from comparing renders on the two binaries are here:
http://t1.minormatter.com/~ddunbar/blender/times.html

<http://t1.minormatter.com/%7Eddunbar/blender/times.html>

A lot of rendering artifacts, but it is remotely possible this is a
Blender bug not a clang one. Several files show obvious flaws, on the
other hand.

These artifacts look like floating point inaccuracies to me.

The edge rendering ones, yes. The red cube verse gray cube is probably something else though. :slight_smile:

Could it be that Clang generates code that makes these worse?

Maybe, although aside from constant folding, IRgen doesn’t do too much in this area. If I was going to hunt these things I would probably do a build with llvm-gcc first to get a feel for frontend verse backend issue. My guess is that the edge artifacts will also show up with llvm-gcc.

  • Daniel

Another way to view these would be to use clang at -O0. If they improve, we can then bugpoint them down to the optimization pass that did it?

To follow up on this:

Daniel Dunbar wrote:

I tried building Blender with clang today for fun. Went without a
hitch, although I had to use gcc for two files from ffmpeg with nasty
inline asm. Blender has about 600k lines of C code internally, and
another 600k from external libraries (like FFTW, ffmpeg, qhull, …).

How do compile times compare?

With a Release-Asserts build of clang:
482.57user 34.79system 9:51.38elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (106major+10080717minor)pagefaults 0swaps

With gcc-4.3.3:
714.04user 36.75system 12:28.26elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (14major+9324539minor)pagefaults 0swaps

This is a complete configure / build / install test, so there is some amount of shared overhead. The under CPU utilization is interesting, possibly due to the driver not honoring -pipe yet.

  • Daniel