> ensight, theres no loop constructs, its all straight mesh data. Granted its
> indexed face sets (mesh2 objects), so I'm not sure how that will get
> represented internally, but since the file is ascii and its internal
> representation will be binary, I assumed the memory image would be smaller
> than the file size.

	Ok, for mesh2{} it is indeed reasonable to guess that the object will
take less space in memory than its plain ascii description (particularly if
vertice coordinates are written with a sufficient precision) *unless* the
mesh carries individual texture(s) for each of its triangles.
	Is it the case in your file?

	- NC

Post a reply to this message

Nicolas Calimet wrote:
>     I'm talking about the AMD64 (= x86-64) MegaPOV binary here.  On the
> other hand the (x86) povlinux binary can indeed run on the Itanium (AFAIK
> the current Itanium supports x86 instructions, but it won't be true in the
> next generations that will require emulation via the IA-32 Execution 
> Layer).

This is not correct. They all emulate x86.

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
>>     I'm talking about the AMD64 (= x86-64) MegaPOV binary here.  On the
>> other hand the (x86) povlinux binary can indeed run on the Itanium (AFAIK
>> the current Itanium supports x86 instructions, but it won't be true in 
>> the
>> next generations that will require emulation via the IA-32 Execution 
>> Layer).
> 
> This is not correct. They all emulate x86.

To be more precise, older versions have the emulator in microcode with 
software support, while newer versions will have it in software only. Either 
way, it is known to be extremely slow, and the microcode emulator only 
supports IA-32.

	Thorsten

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
>>
>  Ok, for mesh2{} it is indeed reasonable to guess that the object will
> take less space in memory than its plain ascii description (particularly if
> vertice coordinates are written with a sufficient precision) *unless* the
> mesh carries individual texture(s) for each of its triangles.
>  Is it the case in your file?
>
>  - NC

Ah! Good call!!  Actually, its a different texture for each VERTEX! and
there's a gagillion of them.  (The model is of a jet engine and we've
mapped CFD parameters (density in this case) to vertex colors to show data
on the surface of the engine blades.)  So that explains that. :) thanks.

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> This might well be the issue, indeed.  Another one is that there is
> some weirdness about memory allocation under Linux in general.  Although
> POV-Ray for Linux, as WinPOV, always checks whether it can allocate memory
> or not, it seems there is no chance for the software to report when it
> cannot allocate memory under Linux: it just gets killed by the OS instead.
> I've been experiencing such an odd behaviour for quite some time with other
> applications as well, so I believe this is not a problem specific to POV
> for Linux.  Yet this will be investigated.

It's not a POV-specific problem, as I understand it. See (under the heading
"Moral #2")

http://www.gotw.ca/publications/mill16.htm

According to Sutter, memory allocation under linux (and some other operating
systems) never fails at the call to "new" (or whatever). Apparently the idea
is that applications may not ever use all the memory they asked for, so
requested memory is not actually committed to your application until you
actually use it. It doesn't sound like something an application can change
easily.

Post a reply to this message

BAH!!!

I attempted the home build, and sure enough, trouble. Although it seems to
be not povray related.  I've pasted the end of the build verbose below. The
repeating assembler message (the NOP thing) actually appeared literally
hundreds of times throughout the build messages. I have no idea what it
means. But ultimately, it reports an error internal to the compiler. Its
using gcc and g++.

Oh well, just posting this in case this means anything to anyone, or has
ideas. But I understand its not a povray problem.


*********************

g++ -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I../source/base -I../source/frontend
-I../unix -I../libraries/png   -I/usr/X11R6/include   -pipe -Wno-multichar
-O3  -c -o mesh.o `test -f 'mesh.cpp' || echo './'`mesh.cpp
{standard input}: Assembler messages:
{standard input}:1061: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:1072: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:1088: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:1099: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:1131: Warning: Additional NOP may be necessary to
workaround mesh.cpp: In function `int
pov::Compute_Mesh_Triangle(pov::MESH_TRIANGLE*, int,
   double*, double*, double*, double*)':
mesh.cpp:1081: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.suse.de/feedback> for instructions.
{standard input}:8759: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:8770: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:8794: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:8810: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:8830: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:8846: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
{standard input}:8862: Warning: Additional NOP may be necessary to
workaround Itanium processor A/B step errata
Preprocessed source stored into /tmp/ccGLCUGm.out file, please attach this
to your bugreport.
make[2]: *** [mesh.o] Error 1
make[2]: Leaving directory `/u/poconn/povray-3.6.1/source'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/u/poconn/povray-3.6.1/source'
make: *** [install-recursive] Error 1
poconn/povray-3.6.1>

Post a reply to this message

> means. But ultimately, it reports an error internal to the compiler. Its
> using gcc and g++.

	For the sake of getting a better gcc (in case that matters on the
Itanium...) I'd suggest you follow the error message and file a bug report.

	In any case I recommand you to use the Intel C++ Compiler to build
anything on that platform.  It is available for free on Linux -- but I
never bothered downloading / testing the version for IA-64.  You can get
it at  https://premier.intel.com  which requires registration in order to
get an end-user license.  (Maybe your institution already has ICPC installed
though: check either "icc -V" or "icpc -V").
	Configuring and building POV should then just be a matter of doing:

./configure COMPILED_BY=you --disable-optimiz CXX=icpc CXXFLAGS="-O3 -ip"

	This is for a start.  In case of trouble I'd be glad to help you
further on.  Followup-To p.unix.

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> > means. But ultimately, it reports an error internal to the compiler. Its
> > using gcc and g++.
>
>  For the sake of getting a better gcc (in case that matters on the
> Itanium...) I'd suggest you follow the error message and file a bug report.
>
>  In any case I recommand you to use the Intel C++ Compiler to build
> anything on that platform.  It is available for free on Linux -- but I
> never bothered downloading / testing the version for IA-64.  You can get
> it at  https://premier.intel.com  which requires registration in order to
> get an end-user license.  (Maybe your institution already has ICPC installed
> though: check either "icc -V" or "icpc -V").
>  Configuring and building POV should then just be a matter of doing:
>
> ./configure COMPILED_BY=you --disable-optimiz CXX=icpc CXXFLAGS="-O3 -ip"
>
>  This is for a start.  In case of trouble I'd be glad to help you
> further on.  Followup-To p.unix.
>
>  - NC

Thanks NC.  icpc is not currently on our altix here.  I downloaded it. I
dont have root on that machine, so I looked into a local install, but that
introduces some issues, so I'm trying to get admin to install it system
wide (which should be done anyway).  So it might be a few days before that
gets done (I work at nasa->gov't environment->slower turning wheels), so
I'll resume the discussion at that time.

Other than that, you requested I attempt MegaPOV on that machine, and report
results.  I actually avoided the bz2 stuff, and just downloaded the tar
file. But trying to 'tar xvf' it on the altix, it reported "doesnt seem to
be a tar file".  So I dont know if there's already a platform
incompatibility at the file format level or what.  But I didnt wrestle with
it any further, since it was a long shot to begin with.

I'll let you know how things go with the home build (over on the p.unix
forum).

Thanks again.

Post a reply to this message

> Other than that, you requested I attempt MegaPOV on that machine, and report
> results.  I actually avoided the bz2 stuff, and just downloaded the tar
> file. But trying to 'tar xvf' it on the altix, it reported "doesnt seem to
> be a tar file".

	Tar archives are usually compressed with gzip (tar.gz) or bzip2 (tar.bz2).
Hence you should also pass the proper option to decompress the archive, e.g.
tar xvzf archive.tar.gz  (note the 'z' for the gzip'ed archive; for an archive
compressed with bzip2 you could use 'j' instead, but this option/decompressor
might not be supported by the tar utility installed on your machine).

	In any case, testing the AMD64 MegaPOV binary is no priority, as it will
normally fail on the Itanium as soon as the  megapov  command is ran.

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> >
>  Tar archives are usually compressed with gzip (tar.gz) or bzip2 (tar.bz2).
> Hence you should also pass the proper option to decompress the archive, e.g.
> tar xvzf archive.tar.gz  (note the 'z' for the gzip'ed archive; for an archive
> compressed with bzip2 you could use 'j' instead, but this option/decompressor
> might not be supported by the tar utility installed on your machine).
>
>  In any case, testing the AMD64 MegaPOV binary is no priority, as it will
> normally fail on the Itanium as soon as the  megapov  command is ran.
>
>  - NC

Right, I believe I gunzipped the .gz to produce a .tar, and then tar xvf'd
that. I decompress tars and gzips all the time, that shouldnt have tripped
me up.  But perhaps I may have had a brain phart moment. It happens to the
best of us. :-)

No worries either way.

Post a reply to this message