[Bf-cycles] osx + ati + cycles, looking for insights in debugging
dfelinto at gmail.com
Wed Dec 7 03:31:56 CET 2011
> What does this mean exactly, that Pcamera.z is always 0?
I can rotate the camera, move it in x and y and is all good. As soon as I
move it outsize Z=0 the view no longer match.
(rastertocamera and raster_x and raster_y seems right though, same for the
>Does F12 rendering work (with resolutions that fail in the viewport) or is
it just viewport rendering?
F12 never renders ok. it's always black to me (with CPU renders fine).
I'll test the other things later and get back to you.
Thanks for the fast reply.
2011/12/6 Brecht Van Lommel <brechtvanlommel at pandora.be>
> On Wed, Dec 7, 2011 at 12:49 AM, Dalai Felinto <dfelinto at gmail.com> wrote:
> > (1) camera is always in Z 0.
> > http://www.pasteall.org/blend/10154
> > (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 ... ;)
> > http://www.pasteall.org/pic/show.php?id=22109
> 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.
> Bf-cycles mailing list
> Bf-cycles at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-cycles