[Bf-cycles] osx + ati + cycles, looking for insights in debugging
dfelinto at gmail.com
Wed Dec 7 07:11:11 CET 2011
"Good news", I believe both problems may indeed be related and of
alignment. At least the first one.
If I change the alignment in kernel_type.h in simple ways [*] I get the Z
problem fixed, but the viewport broken in situations it was working before.
If I go to camera fly mode the viewport is fine ('dirty' but fine) until I
stop then I get the (2) problem. So what are the rules for alignment here?
Regarding (1) camera behaves as if Z = 0:
> 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:
It doesn't do much. but see above.
> 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.
I was trying to do a different approach: I was trying to take out/by pass
whatever I could (e.g. use identity matrixes, raster_x=raster_y=0.0f ...)
that would still produce a different result between cpu/gpu. I think I need
a better understanding of the rendering pipeline in cycle to look at that
further. You gotta agree that this is a quite peculiar bug.
Regarding (2) viewport problem:
Does F12 rendering work (with resolutions that fail in the viewport) or is
it just viewport rendering? ...
The dumped image is as bad as the viewport one. A note: the image is not
'broken' right away. While the light calculation is still dirty, the image
is correct. Only after a few (set_tile() resolution > 8 or so) moments the
> Another thing you could test is the workgroup_size in device_opencl.cpp
in path_trace and tonemap.
workgroup_size is calculated as 16. If I change it to 1, 2, 4, 8, 16 it
produces the same result.
If I change it to 32 OpenCL throw an error on me (OpenCL error (-54):
Invalid work group size)
2011/12/6 Dalai Felinto <dfelinto at gmail.com>
> > 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
> transform operations)
> >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>
>> > (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