I'm not sure I understand why the compiler would treat my uniform as a constant
when I told it I wanted it to be a uniform. I thought uniforms are meant, by
definition, to be changed. Bad decision by the compiler if it is the case.
Also, its my guess that you are not seeing this problem with your examples
because the example shaders are too small and take minimal amount of time to
recompile "on-the-fly". My shaders are on the larger side and the recompile
time is more noticable.
The particular uniform I'm having trouble with changes values as the camera
position changes. I have several other uniforms that are being changed on a
per-frame basis but it appears only this particular one is causing problems
(but its declared/handled no different than the others).
----- Original Message ----
From: Robert Osfield <[EMAIL PROTECTED]>
To: osg users <osg-users@openscenegraph.net>
Sent: Saturday, February 24, 2007 8:52:51 AM
Subject: [osg-users] Frame stalls when changing Uniforms
Hi Paul,
The frame stalls you are see when you change uniforms is probably down
to the OpenGL driver recompiling the vertex or fragment program as
its probably treating uniforms as a constant variable that it compiles
directly into the shader.
While compiling uniforms directly into programs might make for
efficient programs, it does mean that changing uniform start is
expensive. It shouldn't be that expensive though, so it sounds like
the NViidia driver is stuffing up somewhere along the line.
As to what work arounds you can make to avoid this driver problem,
unfortunately I don't have an easy answers. Precompiling shaders
along with uniforms is one possibility, athough if you change a
uniform later you'll hit upon the hit. Perhaps creating several
osg::StateSet each containing a single complete state all of which are
precompiled and then swapped wholesale rather than just tweaking the
uniform.
As general note, the OSG does have a few examples that update uniforms
per frame and don't have problems with performance. Perhaps there is
something specific about the shaders you are using the compiling is
doing some aggressive optimization for that if you change the uniforms
a little things change radically.
A value of 0.5 is something that could be optimized very easily, so
perhaps start with a uniform value which is off 0.5 so to force the
shader to work less aggressively.
Robert.
---------- Forwarded message ----------
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Feb 24, 2007 1:22 PM
Subject: [osg-users] Re: Next release of OpenThreads
To: osg-users@openscenegraph.net
Thank you for your response, Robert.
We have been using OSG intensely for the past 2-3 years and are now in
the integration phase of a relatively large OSG project. We are
finding performance problems that are preventing us from passing our
acceptance tests.
One of these problems is after we change a particular uniform's value,
the next draw time is extremely large (around 80ms). Subsequent frames
seem to be fine. The uniforms value is changing from 0.5 to 0.49999. I
don't think it matters what the new value is but just the fact that
the uniform changed values is causing a problem. As long as the
uniform keeps the value of 0.5, there is no problem but immedately
after it changes values is when we have a problem.
The problem also seems to be related to a texture (and probably other
uniforms) but I am having difficulty tracking down the specifics of
what is causing the problem. Therefore, I do not have sample code
which demostrates the problem. I am using relatively new NVIDIA
drivers. I've used stock 1.2 as well as many CVS/SVN version between
then and now and still have this problem. It has taken me 2 weeks now
to boil the problem down to this information.
What do you think the problem might be?
----- Original Message ----
Date: Fri, 23 Feb 2007 19:22:21 +0000
From: "Robert Osfield" <[EMAIL PROTECTED]>
Subject: Re: [osg-users] Re: Next release of OpenThreads
To: "osg users" <osg-users@openscenegraph.net>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Paul,
On 2/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> What are you saying here Robert? I have an existing
> (relatively large) OSG program that uses osgProducer
> with Producer. Switching this program to use osgViewer
> will result in my schedule and cost overruns.
This is what I have been discussing openly on osg-user for the past
four months, osgProducer will be moved out of the core OSG, and be
maintained seperately. So rather than worry about cost overruns
please keep track of discussions.
> By saying that osgProducer/Producer is "not part of
> the core dependency chain" are you saying that you are
> no longer supporting osgProducer and therefore will
> not be testing it before this release?
osgProducer won't be part of the core OSG. osgProducer will be
released seperately and on its own release schedule. Its such as
small project that it will likely follow along after OSG releases. It
does depend upon Producer releases as well though, and I no longer
have any input to Producer so can't comment on Don's release schedules
> I've already found problems where my existing programs
> broke when moving to CVS/SVN code because of this
> de-emphasis on osgProducer.
Please report them, we can't fix problems we know nothing about.
>
> I'm currently spending a significant portion of my
> time tracking down strange problems with OSG that I do
> not have the time to do even more testing.
>
> I just want to work on making improvements in my
> program and not trying to hit a moving target of
> future OSG changes. I will need future releases of OSG
> for the "bug fixes" but at this time need to holdoff
> switching to new functionality.
Well sorry for ever making open source, ever improving it, ever trying
to fix bugs, ever trying to get releases out.
> What support in the future will there be for
> osgProducer/Producer for existing OSG programs?
Its open source, you can make any future you wish for it. You have
full control over when you upgrade, you have full ability to roll bug
fixes made back into your local code.
There is no magic wand with software, it involves alot of hard graft.
Robert.
____________________________________________________________________________________
Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
