[Bf-cycles] osx + ati + cycles, looking for insights in debugging

[Dalai Felinto]

Hi Brecht
(and anyone that can help),

I'm trying to help Jens to pinpoint what is wrong with the combo: OSX + ATI
+ OpenCL.
There are at least three problems there:

(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)

(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

(3) full shader may not be working [I'm not sure about this, but let's
assuming the "AO" render is good for now]

To test the (1) camera Z I tried your suggestion:
---------------------------------------------------------------------
(in kernel_path.h):
L = make_float4(ray.D.x, ray.D.y, ray.D.z, 1.0f);

This produces the same result in CPU and OCL (and seems correct):
http://www.pasteall.org/pic/show.php?id=22108

All matrixes seem indeed correct, so I could use some direction on where to
look next.


To pinpoint the (2) I was trying to play with the tile code (tile.cpp).
----------------------------------------------------------------------------------------------
In some cases I have a "broken viewport" (see image above). For example, a
820x772 at 818 image renders in the 3dview fine, while a 820x772 at 820 fails.
By only changing the tile size I go from a good to a bad image. (Which in
this case changes a lot given that the former makes 2 tiles (2x410x772)
while the latter makes one (1x820x772)).

With the same file, same windows size, same everything, I apply this patch:
(in tile.cpp)
state.tiles.push_back(Tile(0, 0, image_w, image_h));
/* ... comment all the following lines until: state.width

Now both 818 and 820 tile sizes break the viewport. It's a shame that they
both break, but at least is consistent. Now, what does it tell us?


I remember running into a strange bug between ATIxNVIDIA (on windows back
then) that may be related. In short ATI would never consider the 0,0
defined by the glViewport as the 0,0 for glCopy and SubCopy operations:
http://projects.blender.org/tracker/?func=detail&aid=18004&group_id=9&atid=127It
may be related.

If anyone has any suggestions on what to look further, we are short in
ideas here,
Thanks,
Dalai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20111206/2b996d87/attachment.htm