Nicolas Calimet <pov### [at] freefr> wrote:
>>  You are confusing two completely different things: the scene file size
> has in general nothing to do with how much memory POV-Ray will need to allocate
> for it.  For instance you can have a small scene file that generates billions
> of objects by using loop constructs.
>

Right, I know they are different issues, but since my file was generated by
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.  But perhaps I'm wrong.

thanks.

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
;-)
>
>      As mentioned on the MegaPOV download page, the 64-bit PC-Linux binary
> prepared by the MegaPOV maintainers is meant to run on the AMD64 (and most
> likely Intel EM64T as well), i.e. x86-64 platforms.  I believe this binary
> won't run on the Itanium (i.e. IA-64 platforms) although I can't test either.
>
>      So point 2) above is not valid.  Point 1) still is.
>      Thanks for pointing this out.
>
>      - NC

I'm not a hardware guy, and this is my first dealings with an Itanium, so I
dont really know the issues. But if the povlinux binary works on the
Itanium, why would the megaPOV binary NOT work?

(btw, thanks for all the info and suggestions. great help!)

Post a reply to this message

"space_cadet" <poc### [at] grcnasagov> wrote:
> Nicolas Calimet <pov### [at] freefr> wrote:
> ;-)
> >
> >      As mentioned on the MegaPOV download page, the 64-bit PC-Linux binary
> > prepared by the MegaPOV maintainers is meant to run on the AMD64 (and most
> > likely Intel EM64T as well), i.e. x86-64 platforms.  I believe this binary
> > won't run on the Itanium (i.e. IA-64 platforms) although I can't test either.
> >
> >      So point 2) above is not valid.  Point 1) still is.
> >      Thanks for pointing this out.
> >
> >      - NC
>
> I'm not a hardware guy, and this is my first dealings with an Itanium, so I
> dont really know the issues. But if the povlinux binary works on the
> Itanium, why would the megaPOV binary NOT work?
>
> (btw, thanks for all the info and suggestions. great help!)

Well, maybe I can answer my own question. I talked with our hardware guy
here and he believes that perhaps the 32bit povlinux is running in an x86
emulation mode on the itanium. And this emulation mode is only available
for 32 bit binaries. A 64 bit binary cannot run in emulation mode on the
itanium.

Would this be consistent with your understanding?

Well, home build here I come. :-(  (If I'm not back in 3 days, send in a
search party).

Post a reply to this message

> But if the povlinux binary works on the
> Itanium, why would the megaPOV binary NOT work?

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

	It would be interesting if you could try the AMD64 MegaPOV distro
linked below and report whether it works on your machine.  I'm pretty sure
it won't run, but best is to try  :-)

	- NC

http://megapov.inetart.net/packages/unix/megapov-1.2.1-linux-amd64.tar.bz2

Post a reply to this message

> 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