Hi,
With the sources retrieved this morning, compiled with MS Visual 2005
express,
the performances are the same.
I'll bench more precisely the application to find the problem.
Just a little question...
I've tried the different threading models and I can't get in the cull
task
overlap the draw task in the statistics.
I'm missing something ?
Should I set an environment variable to specify the number of
processors or
something like that ?
Robert Osfield wrote:
> Hi Loinel,
>
> I see no performance drop with the SVN version of the OSG. Please
> try upgrading.
>
> Robert.
>
> On 6/11/07, Lionel Lagarde <[EMAIL PROTECTED]> wrote:
>> My samples.tar.bz2 is refused by the mail list server.
>>
>> The non compressed size is 60Mo.
>>
>> If someone want to retrieve the files, they can be downloaded at:
>> http://perso.orange.fr/lionel.lagarde/samples.tar.bz2
>>
>>
>> Lionel Lagarde wrote:
>> > I've built some test files.
>> >
>> > The attached archive contains:
>> > - withoutshader.osg: a 20x20x20 3D grid of cubes
>> > - withshader_0.osg: the same grid but with a basic shader in the
root
>> > node (no uniforms)
>> > - withshader_1.osg: the same grid but with a basic shader in the
root
>> > node (1 uniforms)
>> > - withshader_10.osg: the same grid but with a basic shader in
the root
>> > node (10 uniforms)
>> > - withshader_20.osg: the same grid but with a basic shader in
the root
>> > node (20 uniforms)
>> > - withshader_30.osg: the same grid but with a basic shader in
the root
>> > node (30 uniforms)
>> > - withshader_100.osg: the same grid but with a basic shader in the
>> > root node (100 uniforms)
>> >
>> >
>> > The uniform are defined in the root node (with the shader).
>> >
>> > On my machine (Core2 duo 6400 + GeForce 7900GTX + OSG 1.2):
>> > - withoutshader.osg: 25.7 fps
>> > - withshader_0.osg: 23.2 fps
>> > - withshader_1.osg: 23.1 fps
>> > - withshader_10.osg: 22.3 fps
>> > - withshader_20.osg: 21.2 fps
>> > - withshader_30.osg: 20.1 fps
>> > - withshader_100.osg: 11.7 fps
>> >
>> >
>> > Lionel Lagarde wrote:
>> >> Hi Robert,
>> >>
>> >> The uniform values are not changing per drawables. They are
fixed in
>> >> the root
>> >> state set (it contains also the shader program).
>> >>
>> >> None of the children of the root node define uniforms (nor shader)
>> >>
>> >> But, per-drawable, the PerContextProgram::apply function is called
>> >> for each
>> >> uniform registered in the root node.
>> >>
>> >>
>> >>
>> >> Robert Osfield wrote:
>> >>> Hi Loinel,
>> >>>
>> >>> High number of uniforms will be the bottleneck, changing
uniforms in
>> >>> OpenGL is relatively expensive. If you shader parameter various
>> >>> changing per drawable then use vertex attributes rather than
>> uniforms.
>> >>>
>> >>> Robert.
>> >>>
>> >>> On 6/11/07, Lionel Lagarde <[EMAIL PROTECTED]> wrote:
>> >>>> It's seems that nobody has this problem.
>> >>>>
>> >>>> High number of drawables + high number of uniforms = bad
>> performances
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> Lionel Lagarde wrote:
>> >>>> > Hi,
>> >>>> >
>> >>>> > Problem description:
>> >>>> > We have a scene with a lot of drawables (>1500). The stateset
>> of the
>> >>>> > root of the
>> >>>> > scene graph contains a shader program.
>> >>>> >
>> >>>> > When we increase the number of uniform variables used by the
>> shader,
>> >>>> > the application performance drop down.
>> >>>> >
>> >>>> > A little debugging session after, it appears that for each
>> drawable
>> >>>> > that has a stateset
>> >>>> > defined, the uniform variables are applied.
>> >>>> >
>> >>>> > They are not really applied, (their modifiedCount has not
>> >>>> changed) but
>> >>>> > the
>> >>>> > osg::Program::PerContextProgram (line 163) do a "find" on a
>> std::map
>> >>>> > (std::string -> GLint)
>> >>>> > to retrieve the uniform location.
>> >>>> >
>> >>>> > It seems that it is this access to the std::map that cause the
>> >>>> > performance drop.
>> >>>> >
>> >>>> > Does someone has encountered this problem ?
>> >>>> > Is there a way to disable the uniform application for each
>> >>>> drawables ?
>> >>>> >
>> >>>> > _______________________________________________
>> >>>> > 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/
>> >>>>
>> >>> _______________________________________________
>> >>> 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/
>> >>
>> >
>> > _______________________________________________
>> > 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/
>>
> _______________________________________________
> 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/
