I'm not seeing this bug on OS X 64 bit, probably it's specific to some specific operating systems or build settings.

Could you attach the output of Help > System Info, along with a .blend file that renders like this? Make it easier for me to track down where the problem is.

Thanks for the reply, I attached the files you requested.

I cannot see those dots either. Tested in Windows 7 x64 with:
- CPU (SVM and OSL)
- GPU (CUDA, Geforce 540M)
-OpenCL (CPU, GPU)

I also tested the 2.68 x86 binary, same result.

So maybe a specific problem on x32 OS or Linux?!

What CPU do you have?

As you have a Radeon x800 (which was released 2004) I think that your CPU may be too old. The minimum requirement for Blender is a Dual Core CPU with 2GHZ and SSE2. http://www.blender.org/features-gallery/requirements/

Thank's all for reply!
My cpu is: Intel(R) Pentium(R) 4 CPU 2.40GHz and it support sse2.
Today I download blender 2.68a_win32 and run it in WINE. Render work good without dots but very slow.
I want use native version blender for Linux without any emulation. Any Idea?

Dots - little square like a shadow of tiles.
If i set performance tiles size to 1920x1080, i have no dots, but is tile size it not optimal for me.
Look at new attached file: Render with tile size 64x64.

Do the dots appear still on the image after you save it from the image editor as PNG or so and observe it in some other viewer / program?

After render i save it from the image editor as png(see attached image dot_bug.png) and dots have stayed there.

Number of dots depends on the size of the tiles. Enable Progressive Refine in Perfomance tab remove all dots.

Opened you blend file in 2.68a (on Linux 32bit) and rendered with F12. I see no dots.
Thomas' suggestion that this might be a Linux or 32bit issue therefore does not appear to be true,
although there is a duplicate bug (#36480) which is also on 32bit Linux. Odd.

For the record - I see the same black dots - both in preview - 2.68 and 2.68a

Ubuntu 13.04
4 gb memory
AMD Phenom(tm) II X4 945 Processor x 4
Graphics GeForce 8800 GT/PCIe/SSE2/3DNOW!
OS type 32bit

CPU rendering

Files uploaded BlackDots.blend and BlackDots.png

More info:

I added a plain color to the world background and rendered - See BlackDots2.png. While some of the black dots appear on the background, they do no extend to areas where there is no boject to render. In other words, if any part of the render square is over an object, a black dot is created at each corner, but in areas where there is no object, only background, there are no black dots.

Latest update here: I couldn't yet reproduce this issue, on Ubuntu Linux 32 bit. But that's in a virtual machine, probably it's related to SSE optimizations which may are not getting used entirely there. I'll try to get this tested on a direct 32 bit linux installation.

Hi Brecht,

I tried it with 2.68a on a ubuntu 12.04 32bit installation (CPU (Intel dual core CULV) rendering only) and on a Lubuntu 13.04 64bit installation (GPU (GTX680) and
CPU (Opteron) ) and I get no dots. If you need me to perform some extra tests (change settings, or whatever) to try to reproduce this, please let me know.

Hello All,

Just a follow up - I just downloaded the latest test build from http://download.blender.org/release/Blender2.69/ and I see the same results - black dots in cycles render.

I could reproduce the issue now, it happens with the SSE2 code path. I've been trying to find a fix for a while but with no luck, I am suspecting a compiler bug. I've committed a change now to disable the SSE optimizations from 2.68 on 32 bit GCC builds, which fixes the dots.

If you want the full optimizations, you should be using 64 bit, many 3D applications nowadays only have 64 bit builds even.

Fix in svn, builds with revision 60509 or newer should have the fix:
http://builder.blender.org/download/

Without the optimizations, render time increased - on my test scene, from 8:58.29 to 12:23.40. Also the render result has artifacts that I cannot explain - I verified that they are not due to surface normals.

Also - using the original release of 2.68a - build r58536, the time difference using progressive at the commad line was very small. Results below:
From the command line - using tiles - 8:51.29
From the command line using progressive - 9:06:44
From within Blender using tiles - 8:58.29
From within Blender using progressive - 10:54.24

And, since Blender doesn't seem to mind rendering from the command line while the same file is open, it may be a viable option. However, I imagine a file save operation would cause issues - in which case, you could always render from one of the backup blends - blend1, blend2 etc. I have attached the blend file as well as the annotated image showing the artifacts from using the latest linux32 build - r60555.

Ron, I committed a modified fix in revision 60573 now, can you test if that solves your issue? If it doesn't, can you mention which CPU and graphics card you are using?

In general though, I've given up on trying to optimize things for 32 bit. I try to ensure it works correct, but I don't have time to optimize for every possible configuration.