Paul Melis wrote:
Alberto Luaces wrote:
El Martes 07 Octubre 2008ES 22:58:06 Paul Melis escribió:
Well, going back to 169.12 does seem to make that problem go away (but
the non-vsynced framerate has gone down to about 1/10th of what it was
with the 173 series, doh!)
Paul
Paul,
I wasn
On Tue, Oct 7, 2008 at 11:04 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 7, 2008 at 10:58 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
>>
>> Well, going back to 169.12 does seem to make that problem go away
>
> Interesting, since I have the problem with the 169.12 driver.
> Maybe I shoul
Hi Robert,
Builds fine on Windows Vista 32 bit, VC++ 2005 (VC8), CMake 2.6.1. Ran
osgviewer and a few other examples (to verify that the recent changes
were merged) and all looks fine.
Just FYI, I thought I'd build and test again in light of the changes
that were checked in in the last few h
Alberto Luaces wrote:
El Martes 07 Octubre 2008ES 22:58:06 Paul Melis escribió:
Well, going back to 169.12 does seem to make that problem go away (but
the non-vsynced framerate has gone down to about 1/10th of what it was
with the 173 series, doh!)
Paul
Paul,
I wasn't able to reprodu
El Martes 07 Octubre 2008ES 22:58:06 Paul Melis escribió:
> Well, going back to 169.12 does seem to make that problem go away (but
> the non-vsynced framerate has gone down to about 1/10th of what it was
> with the 173 series, doh!)
>
> Paul
Paul,
I wasn't able to reproduce that crash, but I have
Hi Paul,
On Tue, Oct 7, 2008 at 9:58 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
>> I'll see what downgrading the nvidia drivers does for this
>
> Well, going back to 169.12 does seem to make that problem go away (but the
> non-vsynced framerate has gone down to about 1/10th of what it was with the
On Tue, Oct 7, 2008 at 10:58 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
>
> Well, going back to 169.12 does seem to make that problem go away
Interesting, since I have the problem with the 169.12 driver.
Maybe I should upgrade to make it go away ;)
--
Csaba
___
Paul Melis wrote:
Robert Osfield wrote:
What type of data sets do you see lock ups on?
Errr, the cow "dataset" :)
What is the rest of your hardware specs?
Intel Core2 Duo, 3 Gb, single monitor.
The gfx card has 512 Mb, but that will hardly have any influence here.
Just tested with vsyn
On Tue, Oct 7, 2008 at 9:14 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
> I seem to be getting some lock up when switching threading models in
> osgviewer (with the cow). However I also see these in 2.6.0 now that I
> test it (haven't been using 2.6 yet).
> What's more, switching of the threading
Robert Osfield wrote:
What type of data sets do you see lock ups on?
Errr, the cow "dataset" :)
What is the rest of your hardware specs?
Intel Core2 Duo, 3 Gb, single monitor.
The gfx card has 512 Mb, but that will hardly have any influence here.
Just tested with vsync turned on and now
Hi Paul,
What type of data sets do you see lock ups on?
What is the rest of your hardware specs?
FYI, I haven't seen lock ups with toggling threading models, just
tried it again and no problems so we'll need to work hard to reproduce
elsewhere. My system is Quad core Intel, 4GB, Kubuntu 7.10, 6
Hi Paul,
What's more, switching of the threading model with 'm' does not always
seem to happen. Sometimes when I press 'm' the threading model doesn't
change, only when I press 'm' again.
FYI, the ThreadingHandler checks that it doesn't receive multiple
"change threading model" events within
And I'm forgetting the important details:
- Gentoo Linux 2.6.25
- GCC 4.1.2
- NVidia Geforce 9600GT, driver 173.14.09
Paul
Paul Melis wrote:
I seem to be getting some lock up when switching threading models in
osgviewer (with the cow). However I also see these in 2.6.0 now
that I test it (
I seem to be getting some lock up when switching threading models in
osgviewer (with the cow). However I also see these in 2.6.0 now that
I test it (haven't been using 2.6 yet).
What's more, switching of the threading model with 'm' does not always
seem to happen. Sometimes when I press 'm'
Builds fine with gcc version 4.3.2, Linux 2.6.26-1-amd64.
El Martes 07 Octubre 2008ES 18:00:17 Robert Osfield escribió:
> Hi All,
>
> I am planning to make a 2.7.3 dev release tomorrow morning, there have
> been plenty of changes checked in since 2.7.2 so there is potential
> for build breaks so I
Hi Robert,
I am planning to make a 2.7.3 dev release tomorrow morning, there have
been plenty of changes checked in since 2.7.2 so there is potential
for build breaks so I'd appreciate testing across platforms of
svn/trunk.
If you have a clean build or a build failure please post your results
i
Hi All,
I am planning to make a 2.7.3 dev release tomorrow morning, there have
been plenty of changes checked in since 2.7.2 so there is potential
for build breaks so I'd appreciate testing across platforms of
svn/trunk.
If you have a clean build or a build failure please post your results
into t
17 matches
Mail list logo