[Bf-cycles] osx + ati + cycles, looking for insights in debugging
Brecht Van Lommel
brechtvanlommel at pandora.be
Wed Dec 7 01:51:01 CET 2011
On Wed, Dec 7, 2011 at 12:49 AM, Dalai Felinto <dfelinto at gmail.com> wrote:
> (1) camera is always in Z 0.
> (CPU matches blender camera, GPU matches blender camera but with Z = 0)
What does this mean exactly, that Pcamera.z is always 0? If that is
the case, either rastertocamera is wrong, or (raster_x, raster_y) is
wrong, or something goes wrong in the execution of transform(). But
it's also not clear to me how ray->D can then match the cpu version,
since Pcamera is used to compute it, and Z being 0 there would break
The way I would debug this is try to find exactly the point where
things are different between the CPU and GPU, which value or operation
is different between the two. For example if it's inside transform(),
copy the code from that into camera_sample_perspective and find out
which value or operation is the culprit.
Here's also a small test, I'm not totally confident the differentials
are aligned well in the struct, you could test this patch to see if
that's somehow related, but it's only a random guess:
> (2) the viewport 'crashes' for a lot of combinations of widthxheight at tiles.
> Sometimes reducing the tiles fixes it, sometimes changing the width,
> sometimes the height, sometimes praying ... ;)
Does F12 rendering work (with resolutions that fail in the viewport)
or is it just viewport rendering? In case of the latter, the problem
is either in tonemapping or viewport opengl drawing. To test if it is
the opengl drawing, this line can be added to dump the image after
I'd also do tests with tile size set to e.g. 10000, that eliminates a
variable since only image width/height matter then.
Another thing you could test is the workgroup_size in
device_opencl.cpp in path_trace and tonemap. You could try setting
that to fixed values like 4, 8, 16. It might also be interesting to
print out the workgroup_size that is computed, maybe it has a strange
> (3) full shader may not be working [I'm not sure about this, but let's
> assuming the "AO" render is good for now]
That's indeed intentional at the moment.
More information about the Bf-cycles