Preparing for a 0.5 release...

[Tim Hutton]

Hello,

I've worked through the list of tasks I had on my TODO list for 0.5, so I'm hoping to make a release in the next week or so.

Now is a great time to make a build and report any bugs, or make suggestions. Let me know if you need help, or need an executable.

Changes:
http://reaction-diffusion.googlecode.com/svn/trunk/Ready/Help/changes.html
A lot of exciting patterns have gone in, including several new discoveries and SmoothLife, which was all over the internet a few weeks ago.

Thanks,

Tim

--
Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/

[Robert Munafo]

Thanks so much for all the continued work on Ready. Despite my
occasional complaints, it's really good all in all.

Here in "the states" we have a bizarre custom that involves driving to
Grandmother's house and eating roast turkey and creamed onions.

I'll be busy with that today and tomorrow, but I can build and test
Ready on Friday or the weekend!

On 11/21/12, Tim Hutton <tim.h...@gmail.com> wrote:
> Hello,
>
> I've worked through the list of tasks I had on my TODO list for 0.5, so I'm
> hoping to make a release in the next week or so.
>
> Now is a great time to make a build and report any bugs, or make
> suggestions. Let me know if you need help, or need an executable.
>
> Changes:
> http://reaction-diffusion.googlecode.com/svn/trunk/Ready/Help/changes.html
> A lot of exciting patterns have gone in, including several new discoveries
> and SmoothLife, which was all over the internet a few weeks ago.

--
Robert Munafo -- mrob.com
Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

[Tim Hutton]

On 21 November 2012 17:38, Robert Munafo <mro...@gmail.com> wrote:

Thanks so much for all the continued work on Ready. Despite my
occasional complaints, it's really good all in all.

Please keep the 'complaints' coming! We can't improve without them.
 

Here in "the states" we have a bizarre custom that involves driving to
Grandmother's house and eating roast turkey and creamed onions.

Oh! Sounds nice. (But creamed onions? Must be some kind of joke? Now bread sauce on the other hand...)
 

I'll be busy with that today and tomorrow, but I can build and test
Ready on Friday or the weekend!

On 11/21/12, Tim Hutton <tim.h...@gmail.com> wrote:
> Hello,
>
> I've worked through the list of tasks I had on my TODO list for 0.5, so I'm
> hoping to make a release in the next week or so.
>
> Now is a great time to make a build and report any bugs, or make
> suggestions. Let me know if you need help, or need an executable.
>
> Changes:
> http://reaction-diffusion.googlecode.com/svn/trunk/Ready/Help/changes.html
> A lot of exciting patterns have gone in, including several new discoveries
> and SmoothLife, which was all over the internet a few weeks ago.

--
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

[Andrew Trevorrow]

Tim:

> Now is a great time to make a build and report any bugs, or make suggestions.

I've committed a couple of minor changes. The Mac build of 0.5 looks
fine, so ready to do a release build whenever you are.

Andrew

[Robert Munafo]

Oops, I forgot to reply to this --

I did the svn update, build, and a bunch of testing. It all seems to
work fine for me. I like the grouping of patterns into folders, and
the UI changes regarding running speed. I noticed that if you make the
running speed a really big number like 1000000, it responds to the
stop command in a reasonably quick manner, which is good. I did not
try generating frames for video, but suspect that code hasn't changed
much...

On 11/21/12, Tim Hutton <tim.h...@gmail.com> wrote:

> Hello,
>
> I've worked through the list of tasks I had on my TODO list for 0.5, so I'm
> hoping to make a release in the next week or so.
>
> Now is a great time to make a build and report any bugs, or make
> suggestions. Let me know if you need help, or need an executable.
>
> Changes:
> http://reaction-diffusion.googlecode.com/svn/trunk/Ready/Help/changes.html
> A lot of exciting patterns have gone in, including several new discoveries
> and SmoothLife, which was all over the internet a few weeks ago.
>
> Thanks,
>
> Tim

--

[Tim Hutton]

Thanks all for having a look.

Sorry for the delay with 0.5. The company I was working for went insolvent, so my first priority has been job-hunting. Not entirely unrelated is the fact that I am no longer able to use the 64-bit machine I was working on. I'm in the process of getting set up again on a new machine but it is taking a while. Hopefully in the next couple of days I'll be all ready to finally make the 0.5 release.

Yours,

Tim

[fededv]

Hi Tim,

I have tested the 0.5 version on a mac running osx 10.8 but I get several error messages loading almost every pattern. I have tested some of the new ones importing them in 0.4 and everything works fine.

Thank you

Federico 

[Robert Munafo]

This isn't nearly enough information for anyone to do anything useful.

What were the error messages? Please give the text of at least one
error message and describe how it is presented (like in a popup
window?).

Aso describe which pattern you were loading that makes the error
happen, and tell us what GPU you have. To find out what GPU you have,
select the "Select OpenCL Device..." command from the Action menu, and
a little window will appear with one or more lines like "Apple: ATI
Radeon HD 6750M" or "Apple: Intel(R) Core(TM) i702720QM CPU @ 2.20
GHz". If there is more than one, your GPU is the one that's currently
selected.

- Robert

[fededv]

Ok Robert,

my previous post was just a try to see if anyone else was experience some serious problems on mac platform. Here are some details to what is happening on my machine:

Mac OSX 10.8.2

Processor:  3.4 GHz Intel Core i7 

Memory:  16 GB 1333 MHz DDR3

OpenCL device to use: Apple: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz

I must make clear that when I switch to OpenCL device ATI Radeon HD 6970M all pattern work ok, unfortunately this option is much slower than the Intel core i7-2600 CPU that worked perfectly in the previous Ready 0.4 version.

Here are a couple of error messages:

ERROR MESSAGES:

 -  FitzHug-Nagumo/Ising_regime.vti -

Failed to open file. Error:

OpenCLImageRD::ReloadKernelIfNeeded : build failed (kernel saved as kernel.txt):

<program source>:47:143: error: can't convert between vector values of different size ('__float4' and 'double')

    a_n.w*0.666667 + a_ne.x*0.166667 + a_e.x*0.666667 + a_se.x*0.166667 + a_s.w*0.666667 + a_s.z*0.166667 + a.z*0.666667 + a_n.z*0.166667) - a*3.333333;

                                                                                                                                             ~^~~~~~~~~

<program source>:51:143: error: can't convert between vector values of different size ('__float4' and 'double')

    b_n.w*0.666667 + b_ne.x*0.166667 + b_e.x*0.666667 + b_se.x*0.166667 + b_s.w*0.666667 + b_s.z*0.166667 + b.z*0.666667 + b_n.z*0.166667) - b*3.333333;

                                                                                                                                             ~^~~~~~~~~

Program build failure

 - Meinhardt_stripes.vti -

Failed to open file. Error:

OpenCLImageRD::ReloadKernelIfNeeded : build failed (kernel saved as kernel.txt):

<program source>:83:143: error: can't convert between vector values of different size ('__float4' and 'double')

    a_n.w*0.666667 + a_ne.x*0.166667 + a_e.x*0.666667 + a_se.x*0.166667 + a_s.w*0.666667 + a_s.z*0.166667 + a.z*0.666667 + a_n.z*0.166667) - a*3.333333;

                                                                                                                                             ~^~~~~~~~~

<program source>:87:143: error: can't convert between vector values of different size ('__float4' and 'double')

    b_n.w*0.666667 + b_ne.x*0.166667 + b_e.x*0.666667 + b_se.x*0.166667 + b_s.w*0.666667 + b_s.z*0.166667 + b.z*0.666667 + b_n.z*0.166667) - b*3.333333;

                                                                                                                                             ~^~~~~~~~~

<program source>:91:143: error: can't convert between vector values of different size ('__float4' and 'double')

    c_n.w*0.666667 + c_ne.x*0.166667 + c_e.x*0.666667 + c_se.x*0.166667 + c_s.w*0.666667 + c_s.z*0.166667 + c.z*0.666667 + c_n.z*0.166667) - c*3.333333;

                                                                                                                                             ~^~~~~~~~~

<program source>:95:143: error: can't convert between vector values of different size ('__float4' and 'double')

    d_n.w*0.666667 + d_ne.x*0.166667 + d_e.x*0.666667 + d_se.x*0.166667 + d_s.w*0.666667 + d_s.z*0.166667 + d.z*0.666667 + d_n.z*0.166667) - d*3.333333;

                                                                                                                                             ~^~~~~~~~~

<program source>:99:143: error: can't convert between vector values of different size ('__float4' and 'double')

    e_n.w*0.666667 + e_ne.x*0.166667 + e_e.x*0.666667 + e_se.x*0.166667 + e_s.w*0.666667 + e_s.z*0.166667 + e.z*0.666667 + e_n.z*0.166667) - e*3.333333;

                                                                                                                                             ~^~~~~~~~~

<program source>:103:143: error: can't convert between vector values of different size ('__float4' and 'double')

    f_n.w*0.666667 + f_ne.x*0.166667 + f_e.x*0.666667 + f_se.x*0.166667 + f_s.w*0.666667 + f_s.z*0.166667 + f.z*0.666667 + f_n.z*0.166667) - f*3.333333;

                                                                                                                                             ~^~~~~~~~~

Program build failure

[Robert Munafo]

Thank you Federico for the details! (I hope you were able to cut and
paste it...)

Tim, I'm including you in case you can offer insight.

Thanks to your details, I was able to Google it and I found these:

http://forum.openframeworks.cc/index.php?topic=7702.0
http://www.khronos.org/message_boards/viewtopic.php?f=37&t=3303

In your case, the code Ready is having trouble with is in the
8-neighbor Laplacian calculation, which is auto-generated by Ready
(and normally not editable, unless you can successfully open a pattern
and then use the "Convert to Full Kernel" command). The error is in
the 4th line of a multi-line statement that looks like this:

float4 laplacian_a = (float4)(a_n.x*0.666667 + a_n.y*0.166667 +
a.y*0.666667 + a_s.y*0.166667 + a_s.x*0.666667 + a_sw.w*0.166667 +
a_w.w*0.666667 + a_nw.w*0.166667,
a_n.y*0.666667 + a_n.z*0.166667 + a.z*0.666667 + a_s.z*0.166667 +
a_s.y*0.666667 + a_s.x*0.166667 + a.x*0.666667 + a_n.x*0.166667,
a_n.z*0.666667 + a_n.w*0.166667 + a.w*0.666667 + a_s.w*0.166667 +
a_s.z*0.666667 + a_s.y*0.166667 + a.y*0.666667 + a_n.y*0.166667,

a_n.w*0.666667 + a_ne.x*0.166667 + a_e.x*0.666667 +
a_se.x*0.166667 + a_s.w*0.666667 + a_s.z*0.166667 + a.z*0.666667 +
a_n.z*0.166667) - a*3.333333;

The specific part it's having trouble with is the bit at the very end that says:

- a*3.333333;

That bit is trying to multiply a float4 (a vector of 4 floats, called
"a") by a scalar constant (the number 3.333333). Apparently in the
MacOS 10.8 OpenCL driver, that implicit conversion is no longer
allowed. The Khronos discussion thread concerns the same problem

I would suggest that it needs to change to:

- a*((float4)3.333333);

and a similar change to the "- b*3.333333;" that appears 4 lines later.

I have created a test version of the "ising" VTI that includes this
fix. I verified that it works on my system (which is MacOS 10.6) when
using the Core i7-2720QM as the OpenCL device -- so at least this
change doesn't make it any worse as far as I can tell.

If this works for you, then it'll be the same fix for the other VTI
files that you reported: it looks like they all have the same error
messages.

- Robert

On 12/15/12, fededv <fed...@gmail.com> wrote:

> Ok Robert,
> [...]

> Here are some details to what is happening on my machine:

> [...]

>
> OpenCL device to use: Apple: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
> I must make clear that when I switch to OpenCL device ATI Radeon HD 6970M
> all pattern work ok, unfortunately this option is much slower than the
> Intel core i7-2600 CPU that worked perfectly in the previous Ready 0.4
> version.
>
> Here are a couple of error messages:
>
> ERROR MESSAGES:
>
> - FitzHug-Nagumo/Ising_regime.vti -
>
> Failed to open file. Error:
>
> OpenCLImageRD::ReloadKernelIfNeeded : build failed (kernel saved as
> kernel.txt):
>
> <program source>:47:143: error: can't convert between vector values of
> different size ('__float4' and 'double')
>
> a_n.w*0.666667 + a_ne.x*0.166667 + a_e.x*0.666667 + a_se.x*0.166667 +
> a_s.w*0.666667 + a_s.z*0.166667 + a.z*0.666667 + a_n.z*0.166667) -
> a*3.333333;
>
>
>
> ~^~~~~~~~~
>
> <program source>:51:143: error: can't convert between vector values of
> different size ('__float4' and 'double')
>
> b_n.w*0.666667 + b_ne.x*0.166667 + b_e.x*0.666667 + b_se.x*0.166667 +
> b_s.w*0.666667 + b_s.z*0.166667 + b.z*0.666667 + b_n.z*0.166667) -
> b*3.333333;
>
>
>
> ~^~~~~~~~~
>
> Program build failure
>

> [...]

[fededv]

Hi Robert,

I have just downloaded your "using-test.vti", loaded it and it works like a charm! This seems the right way...

Thank you for your quick answer.

PS. thank goodness I was able to cut and paste it!

[Robert Munafo]

Oh great, Federico! I'm glad I could help.

Tim, note this means we should change our runtime-generated kernel
text. I think it's in readybase/FormulaOpenCLImageRD.cpp, method
FormulaOpenCLImageRD::AssembleKernelSourceFromFormula(std::string
formula), and the specific case that Federico has run into is the "2D
standard 9-point stencil" case, where it says:

... - " << chem << "*" << K3 << ";\n";

which I guess I'd change to:

... - " << chem << "*((float4)" << K3 << ");\n";

Of course I suspect the same thing will happen in each of the other
auto-generated kernels (anyplace where << chem << isn't followed by a
swizzle like ".x") and since I've never looked at this code before I'm
probably not in a good position to start trying to change it (-:

On 12/15/12, fededv <fed...@gmail.com> wrote:

[Robert Munafo]

Andrew,

Do you have any access to a Mountain Lion system to test with Ready?
Can you confirm Federico's bug (Set the Intel CPU as your OpenCL
device, then get errors when trying to open the Ising_regime pattern)?
And if so, does my fix (attached) fix it?

I think this is a flaw in the OpenCL driver for Intel CPUs, which I
believe might be Intel's fault rather than Apple's fault, but in any
case putting in the explicit scalar-to-vector typecast seems to fix
it, e.g. changing "a*3.333333;" to "a*((float4)3.333333);" in this
example.

[Tim Hutton]

Thanks for the bug report, Federico.

Agreed that we need this fix. I've committed it, and updated the version to 0.5.1 - Andrew, if you could make a new Mac build for Federico to test, that would be brilliant. I don't think we need new Windows or Linux builds, unless we get the same problem reported.

Any more problems with 0.5, let us know.

Thanks all,

Tim

[fededv]

Thanks to you Tim, to Robert and to all the great people on this forum willing to perfect this awesome application.

I will be glad to test the new build on my system as soon as it is ready.

Ciao 

[Andrew Trevorrow]

Federico:

> I have tested the 0.5 version on a mac running osx 10.8 but I get

> several error messages loading almost every pattern. ...

What exactly are the error messages, and which patterns?
(I don't see any errors on my Mac running 10.6.8.)

Do you still get errors if you change to another device using
"Select OpenCL Device" in the Action menu?

What do you see on selecting "Show OpenCL Diagnostics" from the
Action menu? Appended below is what I see.

Andrew

Found 1 platform(s):
Platform 1:
CL_PLATFORM_PROFILE : FULL_PROFILE
CL_PLATFORM_VERSION : OpenCL 1.0 (Jan 2 2011 18:00:11)
CL_PLATFORM_NAME : Apple
CL_PLATFORM_VENDOR : Apple
CL_PLATFORM_EXTENSIONS :

Found 2 device(s) on this platform.
Device 1:
CL_DEVICE_EXTENSIONS : cl_APPLE_gl_sharing
CL_DEVICE_NAME : ATI Radeon HD 6970M
CL_DEVICE_PROFILE : FULL_PROFILE
CL_DEVICE_VENDOR : AMD
CL_DEVICE_VERSION : OpenCL 1.0
CL_DRIVER_VERSION : 1.0
CL_DEVICE_ADDRESS_BITS : 32
CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE : 0
CL_DEVICE_MAX_CLOCK_FREQUENCY : 149
CL_DEVICE_MAX_COMPUTE_UNITS : 10
CL_DEVICE_MAX_CONSTANT_ARGS : 8
CL_DEVICE_MAX_READ_IMAGE_ARGS : 0
CL_DEVICE_MAX_SAMPLERS : 128
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS : 3
CL_DEVICE_MAX_WRITE_IMAGE_ARGS : 0
CL_DEVICE_MEM_BASE_ADDR_ALIGN : 32768
CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE : 128
CL_DEVICE_PREFERRED_VECTOR_WIDTH_FLOAT : 4
CL_DEVICE_VENDOR_ID : 16915200
CL_DEVICE_AVAILABLE : yes
CL_DEVICE_COMPILER_AVAILABLE : yes
CL_DEVICE_ENDIAN_LITTLE : no
CL_DEVICE_ERROR_CORRECTION_SUPPORT : no
CL_DEVICE_IMAGE_SUPPORT : no
CL_DEVICE_GLOBAL_MEM_CACHE_SIZE : 0
CL_DEVICE_GLOBAL_MEM_SIZE : 536870912
CL_DEVICE_LOCAL_MEM_SIZE : 32768
CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE : 65536
CL_DEVICE_MAX_MEM_ALLOC_SIZE : 134217728
CL_DEVICE_IMAGE2D_MAX_HEIGHT : 8192
CL_DEVICE_IMAGE2D_MAX_WIDTH : 8192
CL_DEVICE_IMAGE3D_MAX_DEPTH : 0
CL_DEVICE_IMAGE3D_MAX_HEIGHT : 0
CL_DEVICE_IMAGE3D_MAX_WIDTH : 0
CL_DEVICE_MAX_PARAMETER_SIZE : 1024
CL_DEVICE_MAX_WORK_GROUP_SIZE : 1024
CL_DEVICE_PROFILING_TIMER_RESOLUTION : 37
CL_DEVICE_MAX_WORK_ITEM_SIZES : 1024, 1024, 1024
CL_DEVICE_TYPE : GPU
Device 2:
CL_DEVICE_EXTENSIONS : cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_APPLE_gl_sharing cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions
CL_DEVICE_NAME : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
CL_DEVICE_PROFILE : FULL_PROFILE
CL_DEVICE_VENDOR : Intel
CL_DEVICE_VERSION : OpenCL 1.0
CL_DRIVER_VERSION : 1.0
CL_DEVICE_ADDRESS_BITS : 64
CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE : 64
CL_DEVICE_MAX_CLOCK_FREQUENCY : 3100
CL_DEVICE_MAX_COMPUTE_UNITS : 4
CL_DEVICE_MAX_CONSTANT_ARGS : 8
CL_DEVICE_MAX_READ_IMAGE_ARGS : 128
CL_DEVICE_MAX_SAMPLERS : 16
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS : 3
CL_DEVICE_MAX_WRITE_IMAGE_ARGS : 8
CL_DEVICE_MEM_BASE_ADDR_ALIGN : 1024
CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE : 128
CL_DEVICE_PREFERRED_VECTOR_WIDTH_FLOAT : 4
CL_DEVICE_VENDOR_ID : 16909312
CL_DEVICE_AVAILABLE : yes
CL_DEVICE_COMPILER_AVAILABLE : yes
CL_DEVICE_ENDIAN_LITTLE : yes
CL_DEVICE_ERROR_CORRECTION_SUPPORT : no
CL_DEVICE_IMAGE_SUPPORT : yes
CL_DEVICE_GLOBAL_MEM_CACHE_SIZE : 6291456
CL_DEVICE_GLOBAL_MEM_SIZE : 12884901888
CL_DEVICE_LOCAL_MEM_SIZE : 16384
CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE : 65536
CL_DEVICE_MAX_MEM_ALLOC_SIZE : 3221225472
CL_DEVICE_IMAGE2D_MAX_HEIGHT : 8192
CL_DEVICE_IMAGE2D_MAX_WIDTH : 8192
CL_DEVICE_IMAGE3D_MAX_DEPTH : 2048
CL_DEVICE_IMAGE3D_MAX_HEIGHT : 2048
CL_DEVICE_IMAGE3D_MAX_WIDTH : 2048
CL_DEVICE_MAX_PARAMETER_SIZE : 4096
CL_DEVICE_MAX_WORK_GROUP_SIZE : 1
CL_DEVICE_PROFILING_TIMER_RESOLUTION : 1
CL_DEVICE_MAX_WORK_ITEM_SIZES : 1, 1, 1
CL_DEVICE_TYPE : CPU

[fededv]

Andrew:

I get errors (I have posted a couple of error log in previous post) in all Fitzhug-Nagumo patterns except with squid_axon.vti; errors with Gray-Scott/U--Skate; errors with Complex-Ginsburg-Landau-magnitude.vti and Complex-Ginsburg-Landau; no problem with Grayscott_1D.vti and Grayscott_2D.vti and Grayscott_3D.vti; no problem with all Penrose tiling. These are most of the patterns I tested, as I told Tim and Robert, I get these errors with Apple Intel Core i7-2600 CPU 3.40GHz selected. When I select ATI Radeon HD 6970M OpenCL device everything works fine, much slower though. I paste here my Apple Intel Core OpenCL Diagnostic for you to have a look:

Found 1 platform(s):

Platform 1:

CL_PLATFORM_PROFILE : FULL_PROFILE

CL_PLATFORM_VERSION : OpenCL 1.2 (Aug 24 2012 00:53:09)

CL_PLATFORM_NAME : Apple

CL_PLATFORM_VENDOR : Apple

CL_PLATFORM_EXTENSIONS : cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event

Found 2 device(s) on this platform.

Device 1:

CL_DEVICE_EXTENSIONS : cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_APPLE_fp64_basic_ops cl_APPLE_fixed_alpha_channel_orders cl_APPLE_biased_fixed_point_image_formats

CL_DEVICE_NAME : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz

CL_DEVICE_PROFILE : FULL_PROFILE

CL_DEVICE_VENDOR : Intel

CL_DEVICE_VERSION : OpenCL 1.2 

CL_DRIVER_VERSION : 1.1

CL_DEVICE_ADDRESS_BITS : 64

CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE : 8388608

CL_DEVICE_MAX_CLOCK_FREQUENCY : 3400

CL_DEVICE_MAX_COMPUTE_UNITS : 8

CL_DEVICE_MAX_CONSTANT_ARGS : 8

CL_DEVICE_MAX_READ_IMAGE_ARGS : 128

CL_DEVICE_MAX_SAMPLERS : 16

CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS : 3

CL_DEVICE_MAX_WRITE_IMAGE_ARGS : 8

CL_DEVICE_MEM_BASE_ADDR_ALIGN : 1024

CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE : 128

CL_DEVICE_PREFERRED_VECTOR_WIDTH_FLOAT : 4

CL_DEVICE_VENDOR_ID : 4294967295

CL_DEVICE_AVAILABLE : yes

CL_DEVICE_COMPILER_AVAILABLE : yes

CL_DEVICE_ENDIAN_LITTLE : yes

CL_DEVICE_ERROR_CORRECTION_SUPPORT : no

CL_DEVICE_IMAGE_SUPPORT : yes

CL_DEVICE_GLOBAL_MEM_CACHE_SIZE : 64

CL_DEVICE_GLOBAL_MEM_SIZE : 17179869184

CL_DEVICE_LOCAL_MEM_SIZE : 32768

CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE : 65536

CL_DEVICE_MAX_MEM_ALLOC_SIZE : 4294967296

CL_DEVICE_IMAGE2D_MAX_HEIGHT : 8192

CL_DEVICE_IMAGE2D_MAX_WIDTH : 8192

CL_DEVICE_IMAGE3D_MAX_DEPTH : 2048

CL_DEVICE_IMAGE3D_MAX_HEIGHT : 2048

CL_DEVICE_IMAGE3D_MAX_WIDTH : 2048

CL_DEVICE_MAX_PARAMETER_SIZE : 4096

CL_DEVICE_MAX_WORK_GROUP_SIZE : 1024

CL_DEVICE_PROFILING_TIMER_RESOLUTION : 1

CL_DEVICE_MAX_WORK_ITEM_SIZES : 1024, 1, 1

CL_DEVICE_TYPE : CPU

Device 2:

CL_DEVICE_EXTENSIONS : cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store

CL_DEVICE_NAME : ATI Radeon HD 6970M

CL_DEVICE_PROFILE : FULL_PROFILE

CL_DEVICE_VENDOR : AMD

CL_DEVICE_VERSION : OpenCL 1.1 

CL_DRIVER_VERSION : 1.0

CL_DEVICE_ADDRESS_BITS : 32

CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE : 0

CL_DEVICE_MAX_CLOCK_FREQUENCY : 680

CL_DEVICE_MAX_COMPUTE_UNITS : 12

CL_DEVICE_MAX_CONSTANT_ARGS : 8

CL_DEVICE_MAX_READ_IMAGE_ARGS : 128

CL_DEVICE_MAX_SAMPLERS : 16

CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS : 3

CL_DEVICE_MAX_WRITE_IMAGE_ARGS : 8

CL_DEVICE_MEM_BASE_ADDR_ALIGN : 32768

CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE : 128

CL_DEVICE_PREFERRED_VECTOR_WIDTH_FLOAT : 4

CL_DEVICE_VENDOR_ID : 16915200

CL_DEVICE_AVAILABLE : yes

CL_DEVICE_COMPILER_AVAILABLE : yes

CL_DEVICE_ENDIAN_LITTLE : yes

CL_DEVICE_ERROR_CORRECTION_SUPPORT : no

CL_DEVICE_IMAGE_SUPPORT : yes

CL_DEVICE_GLOBAL_MEM_CACHE_SIZE : 0

CL_DEVICE_GLOBAL_MEM_SIZE : 1073741824

CL_DEVICE_LOCAL_MEM_SIZE : 32768

CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE : 65536

CL_DEVICE_MAX_MEM_ALLOC_SIZE : 268435456

CL_DEVICE_IMAGE2D_MAX_HEIGHT : 8192

CL_DEVICE_IMAGE2D_MAX_WIDTH : 8192

CL_DEVICE_IMAGE3D_MAX_DEPTH : 2048

CL_DEVICE_IMAGE3D_MAX_HEIGHT : 2048

CL_DEVICE_IMAGE3D_MAX_WIDTH : 2048

CL_DEVICE_MAX_PARAMETER_SIZE : 1024

[Robert Munafo]

I've updated my copy (svn says "Updated to revision 1154") built and
run Ready. It runs on my systems (Mac OS 10.6) but that's no news,
because the old version did too.

Inspecting FormulaOpenCLImageRD.cpp and comparing to my Dec 3rd
version, I see that your change was to add a constant declaration to
each kernel, such as:

const float4 K0 = -6.0f;

I do not believe this would solve the problem. I believe that the
kernel compiler will treat this as if it were written:

const float4 K0;
K0 = -6.0f;

which would trigger the same error due to the attempted use of an
implicit conversion. I suggest instead that we need to use explicit
conversion, like this:

const float4 K0 = ((float4) -6.0f);

On 12/16/12, Tim Hutton <tim.h...@gmail.com> wrote:
> Thanks for the bug report, Federico.
>
> Agreed that we need this fix. I've committed it, and updated the version to
> 0.5.1 - Andrew, if you could make a new Mac build for Federico to test,
> that would be brilliant. I don't think we need new Windows or Linux builds,
> unless we get the same problem reported.
>
> Any more problems with 0.5, let us know.

[Tim Hutton]

That's possible. But previously it was trying to convert from double to float4, which is an extra step.

If you're confident that your build is correct (reasonable versions of VTK and wxWidgets, and the right settings) - could you upload it as a New Download. Then Federico can try it out. Or just mail it to him to test.

Thanks,

Tim

[Robert Munafo]

Well, that disproves what I wrote earlier, because the kernel used by
Squid_axon.vti uses one of the new const declarations that I
suspected:

const float4 K0 = -2.0f;

but it doesn't explain why it doesn't work for Federico. Or more
likely, Federico has encountered another bug.

So Federico, I think you'll really have to post this error message
exactly. For example, show us the error you're getting now from
Ising_regime.vti. Although it might look similar to what you reported
last Friday, it's definitely not identical, because the old code "- "
<< chem << "*" << K3 << ";\n";" no longer exists!

On 12/18/12, fededv <fed...@gmail.com> wrote:
> Andrew:
> I get errors (I have posted a couple of error log in previous post) in all
> Fitzhug-Nagumo patterns except with squid_axon.vti; errors with
> Gray-Scott/U--Skate; errors with Complex-Ginsburg-Landau-magnitude.vti and
> Complex-Ginsburg-Landau; no problem with Grayscott_1D.vti
> and Grayscott_2D.vti and Grayscott_3D.vti; no problem with all Penrose
> tiling. These are most of the patterns I tested, as I told Tim and Robert,
> I get these errors with Apple Intel Core i7-2600 CPU 3.40GHz selected. When
>
> I select ATI Radeon HD 6970M OpenCL device everything works fine, much
> slower though. I paste here my Apple Intel Core OpenCL Diagnostic for you
> to have a look:

> [...]

[fededv]

The following is the "exact" message I get when I try to run Ising_regime.vti on my system with Ready 0.5:

Failed to open file. Error:

OpenCLImageRD::ReloadKernelIfNeeded : build failed (kernel saved as kernel.txt):

<program source>:47:143: error: can't convert between vector values of different size ('__float4' and 'double')

    a_n.w*0.666667 + a_ne.x*0.166667 + a_e.x*0.666667 + a_se.x*0.166667 + a_s.w*0.666667 + a_s.z*0.166667 + a.z*0.666667 + a_n.z*0.166667) - a*3.333333;

                                                                                                                                             ~^~~~~~~~~

<program source>:51:143: error: can't convert between vector values of different size ('__float4' and 'double')

    b_n.w*0.666667 + b_ne.x*0.166667 + b_e.x*0.666667 + b_se.x*0.166667 + b_s.w*0.666667 + b_s.z*0.166667 + b.z*0.666667 + b_n.z*0.166667) - b*3.333333;

                                                                                                                                             ~^~~~~~~~~

Program build failure

[Robert Munafo]

Oh, I made a mistake, I apologize.

I thought you had gotten Tim's version 0.5.1 and were telling us that
you still got errors. But I see now that you're still running the
version that has the bug.

On 12/19/12, fededv <fed...@gmail.com> wrote:
> The following is the "exact" message I get when I try to
> run Ising_regime.vti on my system with Ready 0.5:
>
> Failed to open file. Error:
>
> OpenCLImageRD::ReloadKernelIfNeeded : build failed (kernel saved as
> kernel.txt):
>
> <program source>:47:143: error: can't convert between vector values of
> different size ('__float4' and 'double')
> a_n.w*0.666667 + a_ne.x*0.166667 + a_e.x*0.666667 + a_se.x*0.166667 +
> a_s.w*0.666667 + a_s.z*0.166667 + a.z*0.666667 + a_n.z*0.166667) -
> a*3.333333;
>
> ~^~~~~~~~~

[fededv]

No problem,

I may test the 0.5.1 if someone sent it to me.

[Andrew Trevorrow]

[Sorry for late reply -- I've been having email problems.
For some unknown reason my initial reply to Federico turned up
3 days late! Hopefully this was just a temporary glitch.]

Robert:

> Do you have any access to a Mountain Lion system to test with Ready?

No, unfortunately. I've just finished uploading a new 0.5.1 build
for Federico to test on his Mac.

Andrew

[Andrew Trevorrow]

[Robert Munafo]

Hey, thank you Andrew!

Federico wrote:
> No problem,
> I may test the 0.5.1 if someone sent it to me.

Federico: You can find a Mac version 0.5.1, which includes this recent
bug fix, which you can test when you're ready (he he, a pun there).
Go to http://code.google.com/p/reaction-diffusion/downloads/list and
select the item "Ready-0.5.1-Mac.zip". Save it somewhere and un-ZIP
it. In the folder "Ready-0.5.1-Mac" you'll find a "Ready.app" which is
the new version you should try.
If the bug fix works, you should be able to run any of the patterns,
either in your existing patterns directory or in the "Patterns"
directory that you'll also find in the "Ready-0.5.1-Mac" folder.
Let us know how it goes...

On 12/19/12, Andrew Trevorrow <and...@trevorrow.com> wrote:
> Robert:
>
>> Do you have any access to a Mountain Lion system to test with Ready?
>
> No, unfortunately. I've just finished uploading a new 0.5.1 build
> for Federico to test on his Mac.

Maybe someday I'll be able to upload my builds too, but I've just
spent about an hour trying to find answers to Tim's questions to
ascertain whether my builds are actually usable by anybody else. While
I was doing that you uploaded 0.5.1 (-: Thanks for doing that.

[fededv]

Already tested... as far as I could notice all patterns work fine now and no error message afflicted me!

Thank you very much to all of you who put all this effort in this and excuse me if I appeared bothersome sometimes with my complain over those error messages.

I am glad to be able to use this update version of Ready, I even discovered that now you can scale the pattern size by changing a couple of values once you have converted it into full kernel!!!

Thank you again

[Robert Munafo]

On 12/19/12, fededv <fed...@gmail.com> wrote:

> Already tested... as far as I could notice all patterns work fine now and
> no error message afflicted me!

Wow, that's great!

Thanks to Andrew's advice, I'll be able to make builds for testing
purposes at least (although I still suspect we should have a single
experienced person doing "real" builds). I'd rather not have to keep
upgrading my GTK and wxWidgets all the time (and who knows what else
they depend on) when we're not actually using any new features of
those packages.

> I am glad to be able to use this update version of Ready, I even discovered
> that now you can scale the pattern size by changing a couple of values once
> you have converted it into full kernel!!!

Yeah, the full kernels are really great and are part of the reason why
I am so impressed with Ready (that is, with Tim's work) in general. It
provides a wonderful way for beginners to get their feet wet with
reaction-diffusion, and provides enough adjustments and parameters for
scientists to do real work, plus the option of "show full kernel" and
"convert to full kernel" gives a way for people to move up to doing
their own programming, even perhaps making their own stand-alone
simulator separate from Ready if they so desire.