[osg-users] Volume image crash on the latest version of Nvidia driver

[Robert Osfield]

Hi Clement,

I have tried Julian's suggested approach of assign the num_iterations to an
int and it works, simplify his original suggestion I get:

Original shader line that results in hang:

float num_iterations = ceil(length((te-t0).xyz)/SampleDensityValue);

Revised shader line that works fine:

int num_iterations = ceil(length((te-t0).xyz)/SampleDensityValue);

Now, these both should result in the same value, as ceil rounds to an
integer value, abeit within the scope of floating point math.

Curiously the modern MultiPassTechnique shaders work fine too and they use
an int.  Originally I didn't use an int for the num_iterations as early
GLSL implementations didn't fully support int's.

I think the best solution would be to modify the shaders to all use int's
for the num_iterations as a general coding approach using int's is sound.
It shouldn't however be need a float should work in this context just as
well as a int.  What I suspect is that at certain values there is some kind
of numerical bug on the GPU or perhaps driver that is resulting in an
invalid float point value.  Casting from float to int seems to nip this
error in the bud so it doesn't propagate.

It's end of day here so I'll have to make the changes and test them
tomorrow and will update OpenSceneGraph-Data and OSG-3.2, OSG-3.4 an
OSG-svn/trunk branches.

Robert.

Robert.





On 5 August 2015 at 17:46, Robert Osfield <robert.osfield at gmail.com> wrote:

> Hi Clement,
>
>
> On 5 August 2015 at 17:06, <Clement.Chu at csiro.au> wrote:
>
>>   Thanks for your help to test the problem.  Please find the attachment
>> of my test data.   I tested with my laptop (Nvidia NVS 5200M with driver
>> 353.62) and used osg 3.2.1 x64 windows version.  The command is:
>>
>> osgviewer t1.osg
>>
>
> Thanks for the model.
>
> I've run it on my Kubuntu system with Geforce GTX 760 + 346.59 drives and
> get a hang on my system when I rotate the view.  This happens with OSG
> svn/trunk (equivalent to OSG-3.4).  When I run osgvolume t1.dds I get the
> hang as well.  Given the nature of the hang and how it locks out the whole
> desktop it all points to GPU/driver issue of some kind.
>
> If I run:
>
>   osgvolume t1.dds --multi-pass
>
> I don't get any hang.  The osgVolume::MultiPassTechnique is only part of
> OSG-3.4 so you won't have this option when using OSG3.2.1.  By default
> osgvolume still defaults to the old RayTracedTechnique that you'll be
> familiar with, so I would suspect an issue with how the GPU is managing the
> RayTracedTechnique GLSL shaders.
>
>
> The thread that Julian Valentin linked discusses potentially the same
> issue, although the GLSL code Julian suggesting could be changed looks
> valid and the fix a workaround to otherwise valid code.  I will do a review
> of the shaders to see I can spot a problem.
>
> Robert.
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150805/b302f3f3/attachment-0003.htm>