On Sat, Apr 23, 2011 at 5:00 PM, Christian Schmitt wrote:
> Csaba Halász wrote:
>
>> Hm, ok, that doesn't seem to be SSE related, it's just your everyday
>> NULL pointer.
>> Have to check source code to see how that can happen.
>
>
> Did you look into this already?
Yes.
> Would be a good start t
Csaba Halász wrote:
> Hm, ok, that doesn't seem to be SSE related, it's just your everyday
> NULL pointer.
> Have to check source code to see how that can happen.
Did you look into this already?
Would be a good start to fix this (if the problem is not IN the gpc lib).
Chris
--
Geoff McLane wrote:
> I know and read some, like Martin, want to go perhaps
> another direction, and that too is fine...
Well, what I am (we are) having in mind is to provide some sort of a
"scenery root node" to FlightGear in the way like you're typically
referencing OpenFlight scenarios. This
On Tue, 2011-04-19 at 09:29 -0500, Curtis Olson wrote:
[]
> Yup, this is definitely a problem. In order to keep file sizes down,
> the index into the vertex, normal, and texture coordinate lists is a
> "short" ... it might even be a "signed" short.
[]
> Tradeoffs ... if we switch from short to int
On Tue, Apr 19, 2011 at 9:13 AM, Geoff McLane wrote:
>
> Quite some time ago now ran into this NULL ptr
> passed to the merge_left() (internal) gpc library
> function, when trying to process dense (very detailed)
> data, but even after adding code 'protecting' against
> such a segfault, the resu
On Mon, 2011-04-18 at 16:14 +0200, Csaba Halász wrote:
> On Mon, Apr 18, 2011 at 1:38 PM, Christian Schmitt
> wrote:
> > Csaba Halász wrote:
> >> Info registers, and something like x/10i $eip (or $rip on 64 bit)
> > Here you go (still on Atom), Phenom this evening.
> >
> > (gdb) info registers
On Mon, 18 Apr 2011 19:20:59 +0200, Christian wrote in message
<20110418172059.cd1fe1318...@mail.sigmos.de>:
> Curtis Olson wrote:
>
> > Right, as said before, you crashed inside the gpc code. Have you
> > tried regenerating this airport using the --nudge option
> > (increasing the value in sma
The first fault is inside the gpc code. As I said before, by my best
estimation, gpc is algorithmically correct, but when we throw arbitrary real
world numerical data at it, we can encounter some numerical degeneracies and
that can blow up the gpc routines.
I have no complaints if someone wants t
Curtis Olson wrote:
> Right, as said before, you crashed inside the gpc code. Have you tried
> regenerating this airport using the --nudge option (increasing the value
> in small increments until you find a value that allows the airport to be
> successfully built.)
>
> Regards,
>
> Curt.
Curt,
Right, as said before, you crashed inside the gpc code. Have you tried
regenerating this airport using the --nudge option (increasing the value in
small increments until you find a value that allows the airport to be
successfully built.)
Regards,
Curt.
On Mon, Apr 18, 2011 at 11:59 AM, Christi
Christian Schmitt wrote:
> Here you go (still on Atom), Phenom this evening.
Phenom:
(gdb) bt
#0 0x77bd4504 in merge_left (p=0x7c4f00, q=0x0, list=0x7c4f30) at
gpc.c:785
#1 0x77bd6861 in gpc_polygon_clip (op=GPC_UNION, subj=0x747fb0,
clip=0x770120, result=0x74edc0) at gpc.c:13
On Mon, Apr 18, 2011 at 1:38 PM, Christian Schmitt wrote:
> Csaba Halász wrote:
>
>> Info registers, and something like x/10i $eip (or $rip on 64 bit)
>>
>
> Here you go (still on Atom), Phenom this evening.
>
> (gdb) info registers
> eax 0x0 0
>
> (gdb) x/10i $eip
> => 0xb7fb8fd
Csaba Halász wrote:
> Info registers, and something like x/10i $eip (or $rip on 64 bit)
>
Here you go (still on Atom), Phenom this evening.
(gdb) info registers
eax0x0 0
ecx0xb7e67380 -1209633920
edx0x814aab0135572144
ebx0xb7f
On Mon, Apr 18, 2011 at 12:16 PM, Christian Schmitt wrote:
>
> I can get that for you, if you want. But what do you need?
> info registers? The whole coredump file?
Info registers, and something like x/10i $eip (or $rip on 64 bit)
--
Csaba/Jester
-
Csaba Halász wrote:
> It is certainly good advice to optimize for the correct processor, but
> using unsupported instructions typically result in a SIGILL not a
> SIGSEGV.
> It would help to see the actual disassembly around the fault and
> machine register contents. It smells like alignment prob
On Sun, Apr 17, 2011 at 6:37 PM, Martin Spott wrote:
> Christian Schmitt wrote:
>> Martin Spott wrote:
>
>> The O2 flag was set for all tries but it's not the problem here. The problem
>> are certain -march options. "-march=core2 -mfpmath=sse" for the Atom showed
>> the error. Settung it to a more
Curtis Olson wrote:
>
> GIS on a global scale is a really really hard thing. There are tremendous
> challenges in terms of data set sizes, processing time, numerical
> representations, manipulating and crunching data, etc. "Terrorgear" is a
> clever play on words, but any one who is ready to div
>>People who have never seen unix before and are diving in expecting to be
able to click next a couple times and have something useful pop out the
other end 3 seconds later probably will be a little terrorized by what
they find. But others who enjoy seeing dozens of machines crankin
On Sun, Apr 17, 2011 at 2:56 PM, Arnt Karlsen wrote:
> ..searching this list for "TerrorGear" will dig up the horror
> stories of its use too. ;o)
>
GIS on a global scale is a really really hard thing. There are tremendous
challenges in terms of data set sizes, processing time, numerical
repres
On Sun, 17 Apr 2011 19:41:31 + (UTC), Martin wrote in message
:
> Curtis Olson wrote:
>
> > Hopefully the larger point to be made is that we are moving forward
> > with terragear-cs and my main point of jumping in here is to try to
> > give some context and hints and understanding of the bas
On Sun, 17 Apr 2011 11:24:32 -0500, Curtis wrote in message
:
> Personal experience speaking here:
>
> Any time you run off to find a bug in gcc, or in a driver, or you
> think there' s a bug in the optimizer, or your operating system:
> STOP! These are all loud and bright flashing warnings for
Curtis Olson wrote:
> Hopefully the larger point to be made is that we are moving forward with
> terragear-cs and my main point of jumping in here is to try to give some
> context and hints and understanding of the basic system. There's no point
> in chasing down the wrong paths in search of bugs
Christian Schmitt wrote:
> I can agree, it was surely not the 100% correct setting. But for my Phenom I
> still have no clue what to do.
Does it fail even without _any_ additional compiler flag ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
I wrote:
> [...] Nowadays
> people are creating their own public forks (ah, "clones" ;-) of
> "terragear-cs" before submitting _anything_ - which is't that bad at
> all [...]
This typo could be misleading as well :-)
"which isn't that bad at all"
It's good to get the view from both sides of the coin. :-)
Hopefully the larger point to be made is that we are moving forward with
terragear-cs and my main point of jumping in here is to try to give some
context and hints and understanding of the basic system. There's no point
in chasing down th
Curtis Olson wrote:
> Generally terragear is going to be more IO bound that compute bound anyway.
> I don't think you buy yourself a whole lot by trying to squeeze a few
> instructions savings into your build.
Agreed,
Martin.
--
Unix _IS_ user friendly - it's just selective about who it
Curtis Olson wrote:
[...]
I'm trying not to add yet another iteration to the debate about the two
terms "topologically correct" vs. "good enough", everything's already
been said (details upon request, if required), but I think one point
ought to be made very clear in this context, for those who ar
Martin Spott wrote:
> Well, to be more precise, it's been optimization for an incompatible
> platfom ;-)
> The Core2 has a slightly different instruction set from the Pentium
> III, thus, if I were you, I'd let the 'native' compiler choose the
> right platform optimization for you - as long as yo
On Sun, Apr 17, 2011 at 11:37 AM, Martin Spott wrote:
> Christian Schmitt wrote:
> > Martin Spott wrote:
>
> > The O2 flag was set for all tries but it's not the problem here. The
> problem
> > are certain -march options. "-march=core2 -mfpmath=sse" for the Atom
> showed
> > the error. Settung it
Christian Schmitt wrote:
> Martin Spott wrote:
> The O2 flag was set for all tries but it's not the problem here. The problem
> are certain -march options. "-march=core2 -mfpmath=sse" for the Atom showed
> the error. Settung it to a more conservative "-march=prescott" makes it
> work. In this c
Personal experience speaking here:
Any time you run off to find a bug in gcc, or in a driver, or you think
there' s a bug in the optimizer, or your operating system: STOP! These are
all loud and bright flashing warnings for something stupid in your own code.
If people want to spend hours chasin
On Sun, 17 Apr 2011 16:04:17 +0200, Christian wrote in message
<20110417140253.11d101318...@mail.sigmos.de>:
> Martin Spott wrote:
>
>
> >> -#define __FLT_EVAL_METHOD__ 0
> >> +#define __FLT_EVAL_METHOD__ 2
> >
> > I think a simple "-O2" should be permitted. Does it still fail with
> > setting
I noticed the crash appeared to be in "gpc.c". This is the general polygon
clipping library code. I've spent a lot of time in that code and here are
some things for people to be aware of:
1. I believe the code is algorithmically correct.
2. The problem is primarily binary floating point represen
On Sun, 17 Apr 2011 16:08:35 +0200, Christian wrote in message
<20110417140707.e067a1318...@mail.sigmos.de>:
> Arnt Karlsen wrote:
>
> > ..who's code, F|S|TG, or GCC? Which gcc version(s) did you use
> > here?
>
> Where the problem lies in the code I don't know. But it would be SG
> or TG.
..
Arnt Karlsen wrote:
> ..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here?
Where the problem lies in the code I don't know. But it would be SG or TG.
My GCC version is 4.4.5, OS is Gentoo.
> Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may
> be updating gcc-4.5 no
Martin Spott wrote:
>> -#define __FLT_EVAL_METHOD__ 0
>> +#define __FLT_EVAL_METHOD__ 2
>
> I think a simple "-O2" should be permitted. Does it still fail with
> setting just this single option ?
The O2 flag was set for all tries but it's not the problem here. The problem
are certain -march op
Christian Schmitt wrote:
> -#define __FLT_EVAL_METHOD__ 0
> +#define __FLT_EVAL_METHOD__ 2
I think a simple "-O2" should be permitted. Does it still fail with
setting just this single option ?
> I encountered this problem on an Atom-based machine and an AMD Phenom
> machine. So, yes, I should p
On Sun, 17 Apr 2011 14:02:02 +0200, Christian wrote in message
<20110417120036.a62241318...@mail.sigmos.de>:
> Christian Schmitt wrote:
>
> > After that genapts segfaulted during EGKK processing and right
> > until now I have still not much of a clue what exactly is going on.
> > I thought it wa
Christian Schmitt wrote:
> After that genapts segfaulted during EGKK processing and right until now I
> have still not much of a clue what exactly is going on. I thought it was a
> problem with compiling TG against SG and not SG-CS (all from GIT). That
> showed to be wrong. Next guess was overopti
39 matches
Mail list logo
