search

buddhi1980 / mandelbulber2

Official repository for Mandelbulber v2
GNU General Public License v3.0
894 stars 116 forks source link

Different coloring in CPU and OpenCL mode for hybrid fractals #523

Closed buddhi1980 closed 6 years ago

buddhi1980 commented 6 years ago

There is significant difference in fractal colors between CPU mode and OpenCL in hybrid mode It is visible for most of fractals. It is needed to check of all changes in compute_fractal.cpp and fractal_coloring.cpp were copied to OpenCL equivalents.

Example settings for testings:

# Mandelbulber settings file
# version 2.15
# only modified parameters
[main_parameters]
ambient_occlusion_enabled true;
camera 0,9781478165320964 -2,36507565399708 0,5400838756478107;
camera_distance_to_target 1,675122022628784;
camera_rotation 25,05150055126203 -12,63109573407259 -0,428477987805968;
camera_top -0,09936543914953455 0,1949296807394929 0,975770940881834;
flight_last_to_render 99999;
formula_2 7;
formula_iterations_2 2;
fractal_enable_3 false;
hybrid_fractal_enable true;
keyframe_last_to_render 0;
mat1_is_defined true;
raytraced_reflections true;
target 0,2860126800641944 -0,8842636052727353 0,1737801493286319;
mclarekin commented 6 years ago

I think there will be more than one issue

This is the first issue (which in theory should not make a difference between c++ and openCL):

For log formulas we were iterating aux.r_dz

so assuming extendedAux.DE remained unchanged, then, extendedAux.DE = initial condition of 1.0

    // aux.DE
    double mboxDE;
    mboxDE = extendedAux.DE;    =  1.0;
    double r2 = r / fabs(mboxDE);  =  r/1.0 = r;
    if (r2 > 20) r2 = 20;

result r2 = r; for case analyticFunctionLogarithmic

    // summation = orbit trap  part  + aux.color part +  aux.DE part
    colorIndex = (minimumR * 1000.0 + mboxColor * 100 + r2 * 5000.0);

when using analytic log , r2 value is not influenced by iterating aux.DE value.

There are various ways to fix this issue with Hybrid Mode

I do not know the code required

fractal_coloring.cpp 272

// Historic HYBRID MODE coloring
else if (isHybrid)
/*{
    double r2 = r;

    // aux.DE
    // if     (DE function from spinbox) != case

analyticFunctionLogarithmic) { double mboxDE = extendedAux.DE; double r2 = r / fabs(mboxDE); if (r2 > 20) r2 = 20; }

   //   OR          if  (version < v2.15 ) r2 = r;

    // orbit trap
    if (minimumR > 100) minimumR = 100;

    // aux.color (init cond = 1.0)
    double mboxColor;
    mboxColor = extendedAux.color;
    if (mboxColor > 1000) mboxColor = 1000;

    // summation
    colorIndex = (minimumR * 1000.0 + mboxColor * 100 + r2 * 5000.0);
}*/
mclarekin commented 6 years ago

or a mix function with a tooltip

r2 = mix( 1.0, extendedAux.DE, Old_DE_influence parameter) note pre v2.15 settings files, use parameter = 0 with analytic logarithmic DE

On Wed, Aug 15, 2018 at 9:26 PM, carbuncle grim mclarekin@gmail.com wrote:

I think there will be more than one issue

This is the first issue (which in theory should not make a difference between c++ and openCL):

  • aux.r_dz => aux.DE, and effects historic term r2*

For log formulas we were iterating aux.r_dz

so assuming extendedAux.DE remained unchanged, then, extendedAux.DE = initial condition of 1.0

    // aux.DE
    double mboxDE;
    mboxDE = extendedAux.DE;    =  1.0;
    double r2 = r / fabs(mboxDE);  =  r/1.0 = r;
    if (r2 > 20) r2 = 20;

result r2 = r; for case analyticFunctionLogarithmic

    // summation = orbit trap  part  + aux.color part +  aux.DE part
    colorIndex = (minimumR * 1000.0 + mboxColor * 100 + r2 * 5000.0);

when using analytic log , r2 value is not influenced by iterating aux.DE value.

There are various ways to fix this issue with Hybrid Mode

I do not know the code required

fractal_coloring.cpp 272

// Historic HYBRID MODE coloring
else if (isHybrid)
/*{
    double r2 = r;

    // aux.DE
    // if     (DE function from spinbox) != case

analyticFunctionLogarithmic) { double mboxDE = extendedAux.DE; double r2 = r / fabs(mboxDE); if (r2 > 20) r2 = 20; }

   //   OR          if  (version < v2.15 ) r2 = r;

    // orbit trap
    if (minimumR > 100) minimumR = 100;

    // aux.color (init cond = 1.0)
    double mboxColor;
    mboxColor = extendedAux.color;
    if (mboxColor > 1000) mboxColor = 1000;

    // summation
    colorIndex = (minimumR * 1000.0 + mboxColor * 100 + r2 * 5000.0);
}*/
mclarekin commented 6 years ago

another consideration is that we have three color modes:

normal = orbit traps hybrid mode = three parts , plus it uses orbit traps color_by_numbers , can do it all

hybrid mode could be enhanced

// summation colorIndex = (minimumR 1000.0 orbitTrapScale

each solution has "pros and cons."

On Wed, Aug 15, 2018 at 9:42 PM, carbuncle grim mclarekin@gmail.com wrote:

or a mix function with a tooltip

r2 = mix( 1.0, extendedAux.DE, Old_DE_influence parameter) note pre v2.15 settings files, use parameter = 0 with analytic logarithmic DE

On Wed, Aug 15, 2018 at 9:26 PM, carbuncle grim mclarekin@gmail.com wrote:

I think there will be more than one issue

This is the first issue (which in theory should not make a difference between c++ and openCL):

  • aux.r_dz => aux.DE, and effects historic term r2*

For log formulas we were iterating aux.r_dz

so assuming extendedAux.DE remained unchanged, then, extendedAux.DE = initial condition of 1.0

    // aux.DE
    double mboxDE;
    mboxDE = extendedAux.DE;    =  1.0;
    double r2 = r / fabs(mboxDE);  =  r/1.0 = r;
    if (r2 > 20) r2 = 20;

result r2 = r; for case analyticFunctionLogarithmic

    // summation = orbit trap  part  + aux.color part +  aux.DE part
    colorIndex = (minimumR * 1000.0 + mboxColor * 100 + r2 * 5000.0);

when using analytic log , r2 value is not influenced by iterating aux.DE value.

There are various ways to fix this issue with Hybrid Mode

I do not know the code required

fractal_coloring.cpp 272

// Historic HYBRID MODE coloring
else if (isHybrid)
/*{
    double r2 = r;

    // aux.DE
    // if     (DE function from spinbox) != case

analyticFunctionLogarithmic) { double mboxDE = extendedAux.DE; double r2 = r / fabs(mboxDE); if (r2 > 20) r2 = 20; }

   //   OR          if  (version < v2.15 ) r2 = r;

    // orbit trap
    if (minimumR > 100) minimumR = 100;

    // aux.color (init cond = 1.0)
    double mboxColor;
    mboxColor = extendedAux.color;
    if (mboxColor > 1000) mboxColor = 1000;

    // summation
    colorIndex = (minimumR * 1000.0 + mboxColor * 100 + r2 * 5000.0);
}*/
buddhi1980 commented 6 years ago

I'm just asking to eliminate differences between CPU and GPU code. There is needed to compare code line by line in compute_fractal and fractal_coloring files.

mclarekin commented 6 years ago

i am slowly doing it :), I just had to make some notes on the backwards compatibility problems i found while I was checking the code :)

On Wed, Aug 15, 2018 at 10:48 PM, Krzysztof Marczak < notifications@github.com> wrote:

I'm just asking to eliminate differences between CPU and GPU code. There is needed to compare code line by line in compute_fractal and fractal_coloring files.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413162088, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHN96SM-9S_pxzOEMiOeNfHJpADW7ks5uQ_yQgaJpZM4V9Ce8 .

mclarekin commented 6 years ago

compared code line by line in compute_fractal and fractal_coloring files. Result no differences found.

checking commits 6 july 18 7ed2 last good 7 july 18 879e no appveyor cannot check 7 july 18 c8df issues start here

On Wed, Aug 15, 2018 at 10:58 PM, carbuncle grim mclarekin@gmail.com wrote:

i am slowly doing it :), I just had to make some notes on the backwards compatibility problems i found while I was checking the code :)

On Wed, Aug 15, 2018 at 10:48 PM, Krzysztof Marczak < notifications@github.com> wrote:

I'm just asking to eliminate differences between CPU and GPU code. There is needed to compare code line by line in compute_fractal and fractal_coloring files.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413162088, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHN96SM-9S_pxzOEMiOeNfHJpADW7ks5uQ_yQgaJpZM4V9Ce8 .

buddhi1980 commented 6 years ago

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

mclarekin commented 6 years ago

a) finding issue on apperveyor 7 july may help, but that issue may have since been fixed, then broken again

b) currently i am thinking it is related to aux.DE used in the r2 calculation, and maybe in the c++ code.

c) I will go back to Win10 openCL and try to determine which code is correct.

On Thu, Aug 16, 2018 at 12:04 AM, Krzysztof Marczak < notifications@github.com> wrote:

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413177903, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHL7pjTxrn-AvLoiSPxeijNTUqc6Pks5uRA5pgaJpZM4V9Ce8 .

mclarekin commented 6 years ago

isolate problem in current build settings : mandelbulb and transf_add_constant (no DE in this transform) procedure: replicate hybrid mode in color-by-numbers mode result: in color-by-numbers we get the same image as Hybrid Mode c++

r2 calculation in Hybrid Mode openCL code, appears to be what is not working correctly. either r or aux.DE maybe causing problem

now i sleep :)

On Thu, Aug 16, 2018 at 12:35 AM, carbuncle grim mclarekin@gmail.com wrote:

a) finding issue on apperveyor 7 july may help, but that issue may have since been fixed, then broken again

b) currently i am thinking it is related to aux.DE used in the r2 calculation, and maybe in the c++ code.

c) I will go back to Win10 openCL and try to determine which code is correct.

On Thu, Aug 16, 2018 at 12:04 AM, Krzysztof Marczak < notifications@github.com> wrote:

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413177903, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHL7pjTxrn-AvLoiSPxeijNTUqc6Pks5uRA5pgaJpZM4V9Ce8 .

mclarekin commented 6 years ago

it is possible that aux.r_dz to aux.DE changes in 7 July commit, made a pre-existing c++ difference much more obvious.

I will temporary hard code DE to 1 in hybrid color equation, and check openCL appveyor build

random notes

standard mandelbulb,

Normal mode - c++ is the same as openCL

Color-by-numbers mode - c++ is the same as openCL, except if i enable r/DE.,

Hybrid mode - maybe a small difference when openCL was first implemented,

On Thu, Aug 16, 2018 at 1:26 AM, carbuncle grim mclarekin@gmail.com wrote:

isolate problem in current build settings : mandelbulb and transf_add_constant (no DE in this transform) procedure: replicate hybrid mode in color-by-numbers mode result: in color-by-numbers we get the same image as Hybrid Mode c++

r2 calculation in Hybrid Mode openCL code, appears to be what is not working correctly. either r or aux.DE maybe causing problem

now i sleep :)

On Thu, Aug 16, 2018 at 12:35 AM, carbuncle grim mclarekin@gmail.com wrote:

a) finding issue on apperveyor 7 july may help, but that issue may have since been fixed, then broken again

b) currently i am thinking it is related to aux.DE used in the r2 calculation, and maybe in the c++ code.

c) I will go back to Win10 openCL and try to determine which code is correct.

On Thu, Aug 16, 2018 at 12:04 AM, Krzysztof Marczak < notifications@github.com> wrote:

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413177903, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHL7pjTxrn-AvLoiSPxeijNTUqc6Pks5uRA5pgaJpZM4V9Ce8 .

mclarekin commented 6 years ago

The problem existed in V2.14.

And has been made noticable, now that we are using only aux.DE

I am slowly figuring it out :)

On Thu, Aug 16, 2018 at 5:16 PM, carbuncle grim mclarekin@gmail.com wrote:

it is possible that aux.r_dz to aux.DE changes in 7 July commit, made a pre-existing c++ difference much more obvious.

I will temporary hard code DE to 1 in hybrid color equation, and check openCL appveyor build

random notes

standard mandelbulb,

Normal mode - c++ is the same as openCL

Color-by-numbers mode - c++ is the same as openCL, except if i enable r/DE.,

  • plus minor backwards compatability issue from aux.r_dz change

Hybrid mode - maybe a small difference when openCL was first implemented,

  • major difference is the r/DE problem.
  • plus backwards compatability issue from aux.r_dz change, code required

On Thu, Aug 16, 2018 at 1:26 AM, carbuncle grim mclarekin@gmail.com wrote:

isolate problem in current build settings : mandelbulb and transf_add_constant (no DE in this transform) procedure: replicate hybrid mode in color-by-numbers mode result: in color-by-numbers we get the same image as Hybrid Mode c++

r2 calculation in Hybrid Mode openCL code, appears to be what is not working correctly. either r or aux.DE maybe causing problem

now i sleep :)

On Thu, Aug 16, 2018 at 12:35 AM, carbuncle grim mclarekin@gmail.com wrote:

a) finding issue on apperveyor 7 july may help, but that issue may have since been fixed, then broken again

b) currently i am thinking it is related to aux.DE used in the r2 calculation, and maybe in the c++ code.

c) I will go back to Win10 openCL and try to determine which code is correct.

On Thu, Aug 16, 2018 at 12:04 AM, Krzysztof Marczak < notifications@github.com> wrote:

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413177903, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHL7pjTxrn-AvLoiSPxeijNTUqc6Pks5uRA5pgaJpZM4V9Ce8 .

mclarekin commented 6 years ago

hard coding the DE to 1.0 (so r2 = r/1.0;) removed the color difference between c++ and openCL in hybrid mode

therefore DE is confirmed as the problem

with equation r / DE; I would not expect DE being single or double precision, to be causing such a difference.

investigations continue

On Thu, Aug 16, 2018 at 8:30 PM, carbuncle grim mclarekin@gmail.com wrote:

The problem existed in V2.14.

And has been made noticable, now that we are using only aux.DE

I am slowly figuring it out :)

On Thu, Aug 16, 2018 at 5:16 PM, carbuncle grim mclarekin@gmail.com wrote:

it is possible that aux.r_dz to aux.DE changes in 7 July commit, made a pre-existing c++ difference much more obvious.

I will temporary hard code DE to 1 in hybrid color equation, and check openCL appveyor build

random notes

standard mandelbulb,

Normal mode - c++ is the same as openCL

Color-by-numbers mode - c++ is the same as openCL, except if i enable r/DE.,

  • plus minor backwards compatability issue from aux.r_dz change

Hybrid mode - maybe a small difference when openCL was first implemented,

  • major difference is the r/DE problem.
  • plus backwards compatability issue from aux.r_dz change, code required

On Thu, Aug 16, 2018 at 1:26 AM, carbuncle grim mclarekin@gmail.com wrote:

isolate problem in current build settings : mandelbulb and transf_add_constant (no DE in this transform) procedure: replicate hybrid mode in color-by-numbers mode result: in color-by-numbers we get the same image as Hybrid Mode c++

r2 calculation in Hybrid Mode openCL code, appears to be what is not working correctly. either r or aux.DE maybe causing problem

now i sleep :)

On Thu, Aug 16, 2018 at 12:35 AM, carbuncle grim mclarekin@gmail.com wrote:

a) finding issue on apperveyor 7 july may help, but that issue may have since been fixed, then broken again

b) currently i am thinking it is related to aux.DE used in the r2 calculation, and maybe in the c++ code.

c) I will go back to Win10 openCL and try to determine which code is correct.

On Thu, Aug 16, 2018 at 12:04 AM, Krzysztof Marczak < notifications@github.com> wrote:

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413177903, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHL7pjTxrn-AvLoiSPxeijNTUqc6Pks5uRA5pgaJpZM4V9Ce8 .

ghost commented 6 years ago

Great root cause discovery!

On Aug 16, 2018, at 8:13 PM, mclarekin notifications@github.com wrote:

hard coding the DE to 1.0 (so r2 = r/1.0;) removed the color difference between c++ and openCL in hybrid mode

therefore DE is confirmed as the problem

with equation r / DE; I would not expect DE being single or double precision, to be causing such a difference.

investigations continue

On Thu, Aug 16, 2018 at 8:30 PM, carbuncle grim mclarekin@gmail.com wrote:

The problem existed in V2.14.

And has been made noticable, now that we are using only aux.DE

I am slowly figuring it out :)

On Thu, Aug 16, 2018 at 5:16 PM, carbuncle grim mclarekin@gmail.com wrote:

it is possible that aux.r_dz to aux.DE changes in 7 July commit, made a pre-existing c++ difference much more obvious.

I will temporary hard code DE to 1 in hybrid color equation, and check openCL appveyor build

random notes

standard mandelbulb,

Normal mode - c++ is the same as openCL

Color-by-numbers mode - c++ is the same as openCL, except if i enable r/DE.,

  • plus minor backwards compatability issue from aux.r_dz change

Hybrid mode - maybe a small difference when openCL was first implemented,

  • major difference is the r/DE problem.
  • plus backwards compatability issue from aux.r_dz change, code required

On Thu, Aug 16, 2018 at 1:26 AM, carbuncle grim mclarekin@gmail.com wrote:

isolate problem in current build settings : mandelbulb and transf_add_constant (no DE in this transform) procedure: replicate hybrid mode in color-by-numbers mode result: in color-by-numbers we get the same image as Hybrid Mode c++

r2 calculation in Hybrid Mode openCL code, appears to be what is not working correctly. either r or aux.DE maybe causing problem

now i sleep :)

On Thu, Aug 16, 2018 at 12:35 AM, carbuncle grim mclarekin@gmail.com wrote:

a) finding issue on apperveyor 7 july may help, but that issue may have since been fixed, then broken again

b) currently i am thinking it is related to aux.DE used in the r2 calculation, and maybe in the c++ code.

c) I will go back to Win10 openCL and try to determine which code is correct.

On Thu, Aug 16, 2018 at 12:04 AM, Krzysztof Marczak < notifications@github.com> wrote:

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413177903, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHL7pjTxrn-AvLoiSPxeijNTUqc6Pks5uRA5pgaJpZM4V9Ce8 .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

mclarekin commented 6 years ago

i am still only half way there. I am now thinking "why is there a color change in Hybrid mode when using DeltaDE?"

On Fri, Aug 17, 2018 at 12:32 PM, mancoast notifications@github.com wrote:

Great root cause discovery!

On Aug 16, 2018, at 8:13 PM, mclarekin notifications@github.com wrote:

hard coding the DE to 1.0 (so r2 = r/1.0;) removed the color difference between c++ and openCL in hybrid mode

therefore DE is confirmed as the problem

with equation r / DE; I would not expect DE being single or double precision, to be causing such a difference.

investigations continue

On Thu, Aug 16, 2018 at 8:30 PM, carbuncle grim mclarekin@gmail.com wrote:

The problem existed in V2.14.

And has been made noticable, now that we are using only aux.DE

I am slowly figuring it out :)

On Thu, Aug 16, 2018 at 5:16 PM, carbuncle grim mclarekin@gmail.com wrote:

it is possible that aux.r_dz to aux.DE changes in 7 July commit, made a pre-existing c++ difference much more obvious.

I will temporary hard code DE to 1 in hybrid color equation, and check openCL appveyor build

random notes

standard mandelbulb,

Normal mode - c++ is the same as openCL

Color-by-numbers mode - c++ is the same as openCL, except if i enable r/DE.,

  • plus minor backwards compatability issue from aux.r_dz change

Hybrid mode - maybe a small difference when openCL was first implemented,

  • major difference is the r/DE problem.
  • plus backwards compatability issue from aux.r_dz change, code required

On Thu, Aug 16, 2018 at 1:26 AM, carbuncle grim mclarekin@gmail.com wrote:

isolate problem in current build settings : mandelbulb and transf_add_constant (no DE in this transform) procedure: replicate hybrid mode in color-by-numbers mode result: in color-by-numbers we get the same image as Hybrid Mode c++

r2 calculation in Hybrid Mode openCL code, appears to be what is not working correctly. either r or aux.DE maybe causing problem

now i sleep :)

On Thu, Aug 16, 2018 at 12:35 AM, carbuncle grim < mclarekin@gmail.com> wrote:

a) finding issue on apperveyor 7 july may help, but that issue may have since been fixed, then broken again

b) currently i am thinking it is related to aux.DE used in the r2 calculation, and maybe in the c++ code.

c) I will go back to Win10 openCL and try to determine which code is correct.

On Thu, Aug 16, 2018 at 12:04 AM, Krzysztof Marczak < notifications@github.com> wrote:

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/ issues/523#issuecomment-413177903, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHL7pjTxrn- AvLoiSPxeijNTUqc6Pks5uRA5pgaJpZM4V9Ce8 .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413723441, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHP2lX7SfBiGj_w2l1hFfb7EjlCp6ks5uRg8WgaJpZM4V9Ce8 .

mclarekin commented 6 years ago

this would be explained if maybe aux.DE still goes into color equation even though Delta.DE is chosen, this does not need to be changed.

On Fri, Aug 17, 2018 at 12:41 PM, carbuncle grim mclarekin@gmail.com wrote:

i am still only half way there. I am now thinking "why is there a color change in Hybrid mode when using DeltaDE?"

On Fri, Aug 17, 2018 at 12:32 PM, mancoast notifications@github.com wrote:

Great root cause discovery!

On Aug 16, 2018, at 8:13 PM, mclarekin notifications@github.com wrote:

hard coding the DE to 1.0 (so r2 = r/1.0;) removed the color difference between c++ and openCL in hybrid mode

therefore DE is confirmed as the problem

with equation r / DE; I would not expect DE being single or double precision, to be causing such a difference.

investigations continue

On Thu, Aug 16, 2018 at 8:30 PM, carbuncle grim mclarekin@gmail.com wrote:

The problem existed in V2.14.

And has been made noticable, now that we are using only aux.DE

I am slowly figuring it out :)

On Thu, Aug 16, 2018 at 5:16 PM, carbuncle grim mclarekin@gmail.com wrote:

it is possible that aux.r_dz to aux.DE changes in 7 July commit, made a pre-existing c++ difference much more obvious.

I will temporary hard code DE to 1 in hybrid color equation, and check openCL appveyor build

random notes

standard mandelbulb,

Normal mode - c++ is the same as openCL

Color-by-numbers mode - c++ is the same as openCL, except if i enable r/DE.,

  • plus minor backwards compatability issue from aux.r_dz change

Hybrid mode - maybe a small difference when openCL was first implemented,

  • major difference is the r/DE problem.
  • plus backwards compatability issue from aux.r_dz change, code required

On Thu, Aug 16, 2018 at 1:26 AM, carbuncle grim <mclarekin@gmail.com

wrote:

isolate problem in current build settings : mandelbulb and transf_add_constant (no DE in this transform) procedure: replicate hybrid mode in color-by-numbers mode result: in color-by-numbers we get the same image as Hybrid Mode c++

r2 calculation in Hybrid Mode openCL code, appears to be what is not working correctly. either r or aux.DE maybe causing problem

now i sleep :)

On Thu, Aug 16, 2018 at 12:35 AM, carbuncle grim < mclarekin@gmail.com> wrote:

a) finding issue on apperveyor 7 july may help, but that issue may have since been fixed, then broken again

b) currently i am thinking it is related to aux.DE used in the r2 calculation, and maybe in the c++ code.

c) I will go back to Win10 openCL and try to determine which code is correct.

On Thu, Aug 16, 2018 at 12:04 AM, Krzysztof Marczak < notifications@github.com> wrote:

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523# issuecomment-413177903, or mute the thread https://github.com/notifications/unsubscribe-auth/ AMLZHL7pjTxrn-AvLoiSPxeijNTUqc6Pks5uRA5pgaJpZM4V9Ce8 .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413723441, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHP2lX7SfBiGj_w2l1hFfb7EjlCp6ks5uRg8WgaJpZM4V9Ce8 .

mclarekin commented 6 years ago

finally, it appears that casting r in c++ to single precision was the soltution :) :) :)

a bit more testing, then i will evaluate backwards compatability issues

On Fri, Aug 17, 2018 at 12:47 PM, carbuncle grim mclarekin@gmail.com wrote:

this would be explained if maybe aux.DE still goes into color equation even though Delta.DE is chosen, this does not need to be changed.

On Fri, Aug 17, 2018 at 12:41 PM, carbuncle grim mclarekin@gmail.com wrote:

i am still only half way there. I am now thinking "why is there a color change in Hybrid mode when using DeltaDE?"

On Fri, Aug 17, 2018 at 12:32 PM, mancoast notifications@github.com wrote:

Great root cause discovery!

On Aug 16, 2018, at 8:13 PM, mclarekin notifications@github.com wrote:

hard coding the DE to 1.0 (so r2 = r/1.0;) removed the color difference between c++ and openCL in hybrid mode

therefore DE is confirmed as the problem

with equation r / DE; I would not expect DE being single or double precision, to be causing such a difference.

investigations continue

On Thu, Aug 16, 2018 at 8:30 PM, carbuncle grim mclarekin@gmail.com wrote:

The problem existed in V2.14.

And has been made noticable, now that we are using only aux.DE

I am slowly figuring it out :)

On Thu, Aug 16, 2018 at 5:16 PM, carbuncle grim <mclarekin@gmail.com

wrote:

it is possible that aux.r_dz to aux.DE changes in 7 July commit, made a pre-existing c++ difference much more obvious.

I will temporary hard code DE to 1 in hybrid color equation, and check openCL appveyor build

random notes

standard mandelbulb,

Normal mode - c++ is the same as openCL

Color-by-numbers mode - c++ is the same as openCL, except if i enable r/DE.,

  • plus minor backwards compatability issue from aux.r_dz change

Hybrid mode - maybe a small difference when openCL was first implemented,

  • major difference is the r/DE problem.
  • plus backwards compatability issue from aux.r_dz change, code required

On Thu, Aug 16, 2018 at 1:26 AM, carbuncle grim < mclarekin@gmail.com> wrote:

isolate problem in current build settings : mandelbulb and transf_add_constant (no DE in this transform) procedure: replicate hybrid mode in color-by-numbers mode result: in color-by-numbers we get the same image as Hybrid Mode c++

r2 calculation in Hybrid Mode openCL code, appears to be what is not working correctly. either r or aux.DE maybe causing problem

now i sleep :)

On Thu, Aug 16, 2018 at 12:35 AM, carbuncle grim < mclarekin@gmail.com> wrote:

a) finding issue on apperveyor 7 july may help, but that issue may have since been fixed, then broken again

b) currently i am thinking it is related to aux.DE used in the r2 calculation, and maybe in the c++ code.

c) I will go back to Win10 openCL and try to determine which code is correct.

On Thu, Aug 16, 2018 at 12:04 AM, Krzysztof Marczak < notifications@github.com> wrote:

Where the problem started? In CPU code or GPU? Your trace with checking commits will help us a lot.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issu ecomment-413177903, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHL7pj Txrn-AvLoiSPxeijNTUqc6Pks5uRA5pgaJpZM4V9Ce8 .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#issuecomment-413723441, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHP2lX7SfBiGj_w2l1hFfb7EjlCp6ks5uRg8WgaJpZM4V9Ce8 .

buddhi1980 commented 6 years ago

It is very interesting catch that double/single precision makes big difference here.

zebastian commented 6 years ago

what is the performance hit on using double in opencl code? Maybe the maths can be rewritten, to lower the precision loss?

buddhi1980 commented 6 years ago

It will not help, because all previous calculation (input data for coloring) are single precision

buddhi1980 commented 6 years ago

I have found new trace. The formula: float r2 = min(r / fabs(extendedAux->DE), 20.0f); in fractal_coloring for hybrids gives completely different results in OpenCL mode than in CPU. It is always 20.0 !!!

It is the reason of wrong total result for colorIndex = (minimumR 1000.0f + mboxColor 100.0f + r2 * 5000.0f);

Now I have to find why this value is wrong.

buddhi1980 commented 6 years ago

Found!!! The problem was in compute_fractal. Bailout condition for calculating color caused big numeric errors and infinite results. There was condition: if (aux.r > 1e15 || length(z - lastZ) / aux.r < 1e-15f) break; When iteration loop was finished, then aux.r and aux.DE were huge numbers.

buddhi1980 commented 6 years ago

@mclarekin, your discovery about differences between single and double precision was really helpful. In this way I have found important difference in calculation results. Because r2 was always 20, the result of

    colorIndex = (minimumR * 1000.0f + mboxColor * 100.0f + r2 * 5000.0f);

was always: very_small_number + 100000.0 It caused big numeric error in single precision

Thanks @mclarekin for debugging this topic.

mclarekin commented 6 years ago

i suspect your commit will remove a lot of minor color differences, that i had yet to explain and were bugging me. :)

On Sat, Aug 18, 2018 at 4:43 AM Krzysztof Marczak notifications@github.com wrote:

Closed #523 https://github.com/buddhi1980/mandelbulber2/issues/523.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/buddhi1980/mandelbulber2/issues/523#event-1795094653, or mute the thread https://github.com/notifications/unsubscribe-auth/AMLZHChD6tSJ--_QbozlgyvlxjaGJJAEks5uRvLFgaJpZM4V9Ce8 .