POV-Ray : Newsgroups : povray.programming : Type problems Server Time
28 Mar 2024 10:40:37 EDT (-0400)
  Type problems (Message 5 to 14 of 14)  
<<< Previous 4 Messages Goto Initial 10 Messages
From: Aidy
Subject: Re: Type problems
Date: 29 Mar 2011 13:35:01
Message: <web.4d9217fca2992db7674c4bb0@news.povray.org>
That is the exact text of the error. I'm not at a stage of being able to compile
the code yet, it is simply giving me the errors as if they are syntax errors.
But the error messages I've given are the exact messages I am receiving. There
is no more information provided :(

The first error I'm coming across is in the method dents (cuDents for me) :

__device__ static void cuDents (VECTOR EPoint, TNORMAL *Tnormal, VECTOR normal)
{
  DBL noise;
  VECTOR stucco_turb;

  noise = cuNoise (EPoint, (TPATTERN*)Tnormal);  THIS LINE HAS THE ERROR

  noise = noise * noise * noise * Tnormal->Amount;

  /* Get normal displacement value. */
  cuDNoise(stucco_turb, EPoint);

  /* Displace "normal". */
  cuVAddScaledEq(normal, noise, stucco_turb);
}

The next error appears in the function do_Average_Normals :

__device__ static void cuDo_Average_Normals (VECTOR EPoint,TNORMAL
*Tnormal,VECTOR normal, INTERSECTION *Inter)
{
   int i;
   BLEND_MAP *Map = Tnormal->Blend_Map;  ERROR ON THIS LINE
   SNGL Value;
   SNGL Total = 0.0;
   VECTOR V1,V2;

   cuMake_Vector (V1, 0.0, 0.0, 0.0);

   for (i = 0; i < Map->Number_Of_Entries; i++)
   {
     Value = Map->Blend_Map_Entries[i].value;

     cuAssign_Vector(V2,normal);

     cuPerturb_Normal(V2,Map->Blend_Map_Entries[i].Vals.Tnormal,EPoint, Inter);
                  ERROR ON THIS LINE ^ AS WELL

     cuVAddScaledEq(V1,Value,V2);

     Total += Value;
   }

   cuVInverseScale(normal,V1,Total);
}

The first error has just the ( of (TPATTERN *) highlighted in red as an error
and nothing else.

The second error has Tnormal highlighted as the error.

The third error has Map highlighted as the error



The three errors I receive above, in order, in full text are :

Error: Argument of type "TPATTERN * " is incompatible with parameter of type
"TPATTERN * "

TNORMAL *Tnormal
Error: A value of type "BLEND_MAP * " cannot be used to initialize an entity of
type "BLEND_MAP * "

and

BLEND_MAP *Map
Error: argument of type "TNORMAL * " is incompatible with parameter of type
"TNORMAL * "


Hope this is of more help


Le_Forgeron <jgr### [at] freefr> wrote:
> Le 29/03/2011 18:06, Aidy nous fit lire :
> > Version 3.6.2, yes.
> > Using Visual Studio 2010 so the compile that comes with that.
> > What do you mean by my flag??
>
> The option of your compiler (project/setting/compiler/... that kind of
> things)
>
> >
> > The two errors I provided are repeated a few times just with different data
> > types.
>
> What is the EXACT text of the errors, (or is it your version of it) ?
> It's painful enough to try to understand an error message without adding
> layer(s) of grease...
>
> Please provide a FULL copy of the error message (not it's
> interpretation) as well as at least the code of the calling function
> (from start of function to at least the error line!)
>
> Cristal ball currently broken, please help with accurate data.
>
> > All of the errors however complain about a data type not being compatible
> > with its own kind.
> >
> > A few of the lines with errors are :
> >
> > noise = cuNoise (EPoint, (TPATTERN*)Tnormal);
> >
> > BLEND_MAP *Map = Tnormal->Blend_Map;
> >
> > cuPerturb_Normal(V2,Map->Blend_Map_Entries[i].Vals.Tnormal,EPoint, Inter);
> >
>
> No such code as cuNoise & cuPerturb_Normal... Can you be playing odd
> with some Const ?
>
>
> >
> > There are others but the error messages are all much the same.
> > The method names are slightly different but this is due to the work that I am
> > doing. This code may be being interpreted by the NVCC compiler but I'm not sure.
> > I still don't understand why the error is occurring though.
>
> >>
> >> Could you please provide the error lines' number ?
> >> (or a copy-paste of the errors)
> >
> >
> >
> >


Post a reply to this message

From: Le Forgeron
Subject: Re: Type problems
Date: 29 Mar 2011 14:10:38
Message: <4d92209e$1@news.povray.org>
Le 29/03/2011 19:33, Aidy nous fit lire :
> That is the exact text of the error. I'm not at a stage of being able to compile
> the code yet, it is simply giving me the errors as if they are syntax errors.
> But the error messages I've given are the exact messages I am receiving. There
> is no more information provided :(
> 

Oki... ;-)

Could it be that part of your rewrite (Do_Average_Normals --> cu...) is
incomplete and conflicting on TNORMAL ? (such as existing in more than
one form: the povray one and another one ?)

You should search for the definition (in your source tree) of BLEND_MAP,
TNORMAL & TPATTERN.

From the 3.6.1 unix code (your code might vary):

In source/frame.h, TNORMAL is a struct Tnormal_Struct
struct Tnormal_Struct
{
  TPATTERN_FIELDS
  SNGL Amount;
  SNGL Delta; /* NK delta */
};

TPATTERN is a struct struct Pattern_Struct
struct Pattern_Struct
{
  TPATTERN_FIELDS
};

TPATTERN_FIELDS is a collection of fields, happily mixing union & struct.

If no reordering occured (such as asking the compiler to compact the
structure... a nice option which is strongly discouraged with povray),
there should be no problem to cast a TNORMAL* into a TPATTERN*.
(as long as both are what we thing they are).

But error on Tnormal make me believe the type TNORMAL is not from
frame.h for your compilation.

A Windows C++ expert is probably needed.

Now, there is that __device__ keyword... inlining code might have issue
with structures & casting. You might want to rewrite the casted pointer
as a reference instead... I do not know if it would work.

> The first error I'm coming across is in the method dents (cuDents for me) :
> 
> __device__ static void cuDents (VECTOR EPoint, TNORMAL *Tnormal, VECTOR normal)
> {
>   DBL noise;
>   VECTOR stucco_turb;
> 
>   noise = cuNoise (EPoint, (TPATTERN*)Tnormal);  THIS LINE HAS THE ERROR
> 
>   noise = noise * noise * noise * Tnormal->Amount;
> 
>   /* Get normal displacement value. */
>   cuDNoise(stucco_turb, EPoint);
> 
>   /* Displace "normal". */
>   cuVAddScaledEq(normal, noise, stucco_turb);
> }
> 
> The next error appears in the function do_Average_Normals :
> 
> __device__ static void cuDo_Average_Normals (VECTOR EPoint,TNORMAL
> *Tnormal,VECTOR normal, INTERSECTION *Inter)
> {
>    int i;
>    BLEND_MAP *Map = Tnormal->Blend_Map;  ERROR ON THIS LINE
>    SNGL Value;
>    SNGL Total = 0.0;
>    VECTOR V1,V2;
> 
>    cuMake_Vector (V1, 0.0, 0.0, 0.0);
> 
>    for (i = 0; i < Map->Number_Of_Entries; i++)
>    {
>      Value = Map->Blend_Map_Entries[i].value;
> 
>      cuAssign_Vector(V2,normal);
> 
>      cuPerturb_Normal(V2,Map->Blend_Map_Entries[i].Vals.Tnormal,EPoint, Inter);
>                   ERROR ON THIS LINE ^ AS WELL
> 
>      cuVAddScaledEq(V1,Value,V2);
> 
>      Total += Value;
>    }
> 
>    cuVInverseScale(normal,V1,Total);
> }
> 
> The first error has just the ( of (TPATTERN *) highlighted in red as an error
> and nothing else.
> 
> The second error has Tnormal highlighted as the error.
> 
> The third error has Map highlighted as the error
> 
> 
> 
> The three errors I receive above, in order, in full text are :
> 
> Error: Argument of type "TPATTERN * " is incompatible with parameter of type
> "TPATTERN * "
> 
> TNORMAL *Tnormal
> Error: A value of type "BLEND_MAP * " cannot be used to initialize an entity of
> type "BLEND_MAP * "
> 
> and
> 
> BLEND_MAP *Map
> Error: argument of type "TNORMAL * " is incompatible with parameter of type
> "TNORMAL * "
> 
> 
> Hope this is of more help
> 
> 
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 29/03/2011 18:06, Aidy nous fit lire :
>>> Version 3.6.2, yes.
>>> Using Visual Studio 2010 so the compile that comes with that.
>>> What do you mean by my flag??
>>
>> The option of your compiler (project/setting/compiler/... that kind of
>> things)
>>
>>>
>>> The two errors I provided are repeated a few times just with different data
>>> types.
>>
>> What is the EXACT text of the errors, (or is it your version of it) ?
>> It's painful enough to try to understand an error message without adding
>> layer(s) of grease...
>>
>> Please provide a FULL copy of the error message (not it's
>> interpretation) as well as at least the code of the calling function
>> (from start of function to at least the error line!)
>>
>> Cristal ball currently broken, please help with accurate data.
>>
>>> All of the errors however complain about a data type not being compatible
>>> with its own kind.
>>>
>>> A few of the lines with errors are :
>>>
>>> noise = cuNoise (EPoint, (TPATTERN*)Tnormal);
>>>
>>> BLEND_MAP *Map = Tnormal->Blend_Map;
>>>
>>> cuPerturb_Normal(V2,Map->Blend_Map_Entries[i].Vals.Tnormal,EPoint, Inter);
>>>
>>
>> No such code as cuNoise & cuPerturb_Normal... Can you be playing odd
>> with some Const ?
>>
>>
>>>
>>> There are others but the error messages are all much the same.
>>> The method names are slightly different but this is due to the work that I am
>>> doing. This code may be being interpreted by the NVCC compiler but I'm not sure.
>>> I still don't understand why the error is occurring though.
>>
>>>>
>>>> Could you please provide the error lines' number ?
>>>> (or a copy-paste of the errors)
>>>
>>>
>>>
>>>
> 
> 
> 
>


Post a reply to this message

From: Aidy
Subject: Re: Type problems
Date: 29 Mar 2011 15:05:00
Message: <web.4d922ca1a2992db7674c4bb0@news.povray.org>
OK I've fiddled around with it a bit, and the first error on (TPATTERN *)Tnormal
doesn't appear to be an error to do with the casting. That seems to be working
fine (I created a new TPATTERN * variable and assigned it to the cast Tnormal
without error) however it errors when using that in the method call to cuNoise.

My declaration of cuNoise is :

__device__ INLINE_NOISE DBL cuNoise (VECTOR EPoint,TPATTERN *TPat)

and is inside the texture file, as it was before (i've moved a lot of things
around but all methods are still in the same relative places. e.g methods
originally in texture are now in cuTexture.)

The cuNoise definition clearly requires a TPATTERN pointer, yet I still get the
error? I am including the cuTexture header file where the prototype of the
cuNoise method exists. Everything SEEMS correct, and short of the naming of
methods, it is identical to the original code to the best of my knowledge :(

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 29/03/2011 19:33, Aidy nous fit lire :
> > That is the exact text of the error. I'm not at a stage of being able to compile
> > the code yet, it is simply giving me the errors as if they are syntax errors.
> > But the error messages I've given are the exact messages I am receiving. There
> > is no more information provided :(
> >
>
> Oki... ;-)
>
> Could it be that part of your rewrite (Do_Average_Normals --> cu...) is
> incomplete and conflicting on TNORMAL ? (such as existing in more than
> one form: the povray one and another one ?)
>
> You should search for the definition (in your source tree) of BLEND_MAP,
> TNORMAL & TPATTERN.
>
> From the 3.6.1 unix code (your code might vary):
>
> In source/frame.h, TNORMAL is a struct Tnormal_Struct
> struct Tnormal_Struct
> {
>   TPATTERN_FIELDS
>   SNGL Amount;
>   SNGL Delta; /* NK delta */
> };
>
> TPATTERN is a struct struct Pattern_Struct
> struct Pattern_Struct
> {
>   TPATTERN_FIELDS
> };
>
> TPATTERN_FIELDS is a collection of fields, happily mixing union & struct.
>
> If no reordering occured (such as asking the compiler to compact the
> structure... a nice option which is strongly discouraged with povray),
> there should be no problem to cast a TNORMAL* into a TPATTERN*.
> (as long as both are what we thing they are).
>
> But error on Tnormal make me believe the type TNORMAL is not from
> frame.h for your compilation.
>
> A Windows C++ expert is probably needed.
>
> Now, there is that __device__ keyword... inlining code might have issue
> with structures & casting. You might want to rewrite the casted pointer
> as a reference instead... I do not know if it would work.
>


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Type problems
Date: 29 Mar 2011 15:47:59
Message: <4d92376f$1@news.povray.org>
On 29.03.11 21:01, Aidy wrote:
> OK I've fiddled around with it a bit, and the first error on (TPATTERN *)Tnormal
> doesn't appear to be an error to do with the casting. That seems to be working
> fine (I created a new TPATTERN * variable and assigned it to the cast Tnormal
> without error) however it errors when using that in the method call to cuNoise.
>
> My declaration of cuNoise is :
>
> __device__ INLINE_NOISE DBL cuNoise (VECTOR EPoint,TPATTERN *TPat)
>
> and is inside the texture file, as it was before (i've moved a lot of things
> around but all methods are still in the same relative places. e.g methods
> originally in texture are now in cuTexture.)
>
> The cuNoise definition clearly requires a TPATTERN pointer, yet I still get the
> error? I am including the cuTexture header file where the prototype of the
> cuNoise method exists. Everything SEEMS correct, and short of the naming of
> methods, it is identical to the original code to the best of my knowledge :(

Well, the question to ask is simple: Why are you renaming all functions in 
POV-Ray? And the immediate conclusion is to ask: Did the code work *before* 
you changed it?

     Thorsten


Post a reply to this message

From: Le Forgeron
Subject: Re: Type problems
Date: 29 Mar 2011 17:31:13
Message: <4d924fa1$1@news.povray.org>
Le 29/03/2011 21:01, Aidy nous fit lire :
> OK I've fiddled around with it a bit, and the first error on (TPATTERN *)Tnormal
> doesn't appear to be an error to do with the casting. That seems to be working
> fine (I created a new TPATTERN * variable and assigned it to the cast Tnormal
> without error) however it errors when using that in the method call to cuNoise.
> 
> My declaration of cuNoise is :
> 
> __device__ INLINE_NOISE DBL cuNoise (VECTOR EPoint,TPATTERN *TPat)
> 
> and is inside the texture file, as it was before (i've moved a lot of things
> around but all methods are still in the same relative places. e.g methods
> originally in texture are now in cuTexture.)
> 
> The cuNoise definition clearly requires a TPATTERN pointer, yet I still get the
> error? I am including the cuTexture header file where the prototype of the
> cuNoise method exists. Everything SEEMS correct, and short of the naming of
> methods, it is identical to the original code to the best of my knowledge :(
> 

>> Now, there is that __device__ keyword... inlining code might have issue
>> with structures & casting. You might want to rewrite the casted pointer
>> as a reference instead... I do not know if it would work.
>>
> 
> 

Please, read.
__device__ is going to inline the function (or I'm just getting it
wrong, which is 90% likely).
That means that you cannot give a pointer and hope you can access it's
structure. You need to pass the structure itself.
(and if you are trying what I believe, it cannot work without passing
the content of the structure... which is gonna be a problem because
there is not enough registers for all the fields)

Google clue: __device__

> http://code.google.com/p/stanford-cs193g-sp2010/wiki/TutorialDeviceFunctions

http://forums.nvidia.com/index.php?showtopic=83335

Cuda...


Post a reply to this message

From: Aidy
Subject: Re: Type problems
Date: 30 Mar 2011 09:15:00
Message: <web.4d932caca2992db7674c4bb0@news.povray.org>
> Please, read.
> __device__ is going to inline the function (or I'm just getting it
> wrong, which is 90% likely).

Sorry I missed that bit. You're right, I've just looking through the nVidia
documentation, and the link you sent me and it will inline it.

If it inlines it then, can I pass the structure itself and NOT have it create a
copy within the function itself?? It shouldn't increase the overhead at all
should it??


Post a reply to this message

From: Le Forgeron
Subject: Re: Type problems
Date: 30 Mar 2011 10:13:32
Message: <4d933a8c$1@news.povray.org>
Le 30/03/2011 15:14, Aidy a écrit :
>> Please, read.
>> __device__ is going to inline the function (or I'm just getting it
>> wrong, which is 90% likely).
> 
> Sorry I missed that bit. You're right, I've just looking through the nVidia
> documentation, and the link you sent me and it will inline it.
> 
> If it inlines it then, can I pass the structure itself and NOT have it create a
> copy within the function itself?? It shouldn't increase the overhead at all
> should it??
> 
I would be more concerned about the content of the structure: if it hold
any pointer (and use it), you will be once again in trouble.

(for the sack of my comprehension so far: the address space used by the
main CPU is not the address space used by the Cuda element, so any
pointer filled by the CPU is useless on the Cuda element. Which means
only linear/flat data(aka structure) can be exchanged at the interface
of a __device__ function.)

Now, I did not check the definition of TNORMAL and other.

For your question: as it is inline, no copy are created, it just use the
actual data. (unless a C expert wants to show up and put me in
embarassement right for that sentence)

You might get issue with patterns that use a cache, as 3.6 is not
thread-aware and Cuda code could run into collisions.

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.


Post a reply to this message

From: Aidy
Subject: Re: Type problems
Date: 30 Mar 2011 10:45:00
Message: <web.4d934110a2992db7674c4bb0@news.povray.org>
I've not got round to porting over the types inside the Opts structure just yet
but you're right, they won't be able to reference the original memory. But this
will be part of what I copy to the GPU when the kernel function is called.

What sort of things are you referring to when you say patterns that use a
cache??

Le_Forgeron <lef### [at] freefr> wrote:
> Le 30/03/2011 15:14, Aidy a écrit :
> >> Please, read.
> >> __device__ is going to inline the function (or I'm just getting it
> >> wrong, which is 90% likely).
> >
> > Sorry I missed that bit. You're right, I've just looking through the nVidia
> > documentation, and the link you sent me and it will inline it.
> >
> > If it inlines it then, can I pass the structure itself and NOT have it create a
> > copy within the function itself?? It shouldn't increase the overhead at all
> > should it??
> >
> I would be more concerned about the content of the structure: if it hold
> any pointer (and use it), you will be once again in trouble.
>
> (for the sack of my comprehension so far: the address space used by the
> main CPU is not the address space used by the Cuda element, so any
> pointer filled by the CPU is useless on the Cuda element. Which means
> only linear/flat data(aka structure) can be exchanged at the interface
> of a __device__ function.)
>
> Now, I did not check the definition of TNORMAL and other.
>
> For your question: as it is inline, no copy are created, it just use the
> actual data. (unless a C expert wants to show up and put me in
> embarassement right for that sentence)
>
> You might get issue with patterns that use a cache, as 3.6 is not
> thread-aware and Cuda code could run into collisions.
>
> --
> Software is like dirt - it costs time and money to change it and move it
> around.
>
> Just because you can't see it, it doesn't weigh anything,
> and you can't drill a hole in it and stick a rivet into it doesn't mean
> it's free.


Post a reply to this message

From: Le Forgeron
Subject: Re: Type problems
Date: 30 Mar 2011 12:54:14
Message: <4d936036@news.povray.org>
Le 30/03/2011 16:41, Aidy nous fit lire :

> What sort of things are you referring to when you say patterns that use a
> cache??

IIRC, the crackle pattern needs one (it has been one of a major headache
for 3.7 & SMP). The 3.6 serie for crackle uses a single cache, and
overuse the fact that the rendering is progressive to manage it.


Post a reply to this message

From: clipka
Subject: Re: Type problems
Date: 31 Mar 2011 18:13:38
Message: <4d94fc92$1@news.povray.org>
Am 29.03.2011 19:33, schrieb Aidy:
> That is the exact text of the error. I'm not at a stage of being able to compile
> the code yet, it is simply giving me the errors as if they are syntax errors.
> But the error messages I've given are the exact messages I am receiving. There
> is no more information provided :(
>
> The first error I'm coming across is in the method dents (cuDents for me) :
>
> __device__ static void cuDents (VECTOR EPoint, TNORMAL *Tnormal, VECTOR normal)

What's __device__? You're compiling for CUDA, right? Could it be that 
Tnormal is interpreted as a pointer to CPU address space, while the 
function is to be executed by the GPU and therefore local pointer 
variables need to point to GPU address space?


Post a reply to this message

<<< Previous 4 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.