it.
Enjoy your vacations,
Wojtek
- Original Message - From: Robert Osfield
robert.osfi...@gmail.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Monday, July 27, 2009 4:37 PM
Subject: Re: [osg-users] Frame rates vary dramatically across runs
Hi Wojtek,
On Mon, Jul
: [osg-users] Frame rates vary dramatically across runs
Hi Wojtek,
I've done my best to enjoy my vacation(s!) and now will take joy in
pestering you about the changes we discussed, did you get around to
making them :-)
Cheers,
Robert.
On Mon, Jul 27, 2009 at 4:27 PM, Wojciech
, reading from the depth_tex
Cheers,
Wojtek
- Original Message -
From: Wojciech Lewandowski lewandow...@ai.com.pl
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Friday, July 24, 2009 4:25 PM
Subject: Re: [osg-users] Frame rates vary dramatically across runs
Hi Robert
@lists.openscenegraph.org
Sent: Friday, July 24, 2009 4:25 PM
Subject: Re: [osg-users] Frame rates vary dramatically across runs
Hi Robert,
I've just has a look at your changed RenderStage. The changed code is
below. Is there a reason why the #if !FORCE_COLOR_ATTACHMENT which
disables the draw and read buffer
Hi Robert J-S,
Sorry if I am bit late with the answers. I have browsed the code to know
what we are talking about ;-)
[...] right thing to do would be to refactor
this code so it allowed the setting of the draw and read buffer values
directly even with the value is GL_NONE. As things stand
HI Wojtek,
I agree with your analysis that it'd be appropriate to place
glDrawBuffers/glReadBuffer support into osg::State and utilize lazy
state updating for this.
In terms of the existing RenderStage::_draw/_renderBuffers values,
this is currently set by the CullVisitor + SceneView, so rather
Hi Robert,
In terms of the existing RenderStage::_draw/_renderBuffers values,
this is currently set by the CullVisitor + SceneView, so rather than
being their for lazy state updating it's there as means of passing
values for high level set up to the lower level draw traversal so
would need to
Hi Wojtek,
On Mon, Jul 27, 2009 at 3:23 PM, Wojciech
Lewandowskilewandow...@ai.com.pl wrote:
I think we are pretty much on the same page. Question (which J-S asked) is
who does this ? I may not uderstand all the intricacies, but I promised to
look at the code and come up with submission
Robert,
I'll try to do it.
Enjoy your vacations,
Wojtek
- Original Message -
From: Robert Osfield robert.osfi...@gmail.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Monday, July 27, 2009 4:37 PM
Subject: Re: [osg-users] Frame rates vary dramatically across
Hi Wojtek, JS, et al,
On Wed, Jul 22, 2009 at 3:57 PM, Wojciech
Lewandowskilewandow...@ai.com.pl wrote:
I agree. We may raise this subject when Robert comes back. He probably knows
why RenderStage does this.
The code in RenderStage is mainly there as fallback to avoid limits
applied by the
Hi Robert,
One problem that this change might introduce is that if users make not
explicitly specified both a depth and colour buffers in their Camera
settings, but instead have relied upon this behavior of RenderStage.
I think a solution could be adding default COLOR_BUFFER and DEPTH_BUFFER
Hi Wojtek,
On Fri, Jul 24, 2009 at 1:18 PM, Wojciech
Lewandowskilewandow...@ai.com.pl wrote:
I think a solution could be adding default COLOR_BUFFER and DEPTH_BUFFER
attachments to FBO Cameras. They are not set currently and thus dirty work
of setting them is done by RenderStage. If they were
Thanks Robert,
I think a solution could be adding default COLOR_BUFFER and DEPTH_BUFFER
attachments to FBO Cameras. They are not set currently and thus dirty
work
of setting them is done by RenderStage. If they were set by default in
Camera users could directly override or remove them.
If
Hi Robert, Wojtek,
Robert Osfield wrote:
The code in RenderStage is mainly there as fallback to avoid limits
applied by the first FBO supporting drivers. Removing this
requirement should now be possible - we can do this and then do a call
for testing.
That's what I thought. I think that
Hi J-S,
Is this really needed? I know we don't want to break users' existing apps,
but in general, we should assume they know what they're doing right?
The solution above would mean that someone who knows what they're doing
would need to remove attachment(s) instead of adding just the ones
Hi Wojtek,
We all agree. Lets make atachment selection explicit. My proposal was
just an rhetoric response (if I may say so;-) to rhetoric question
Robert asked.
OK, so who does it? :-)
If you have the time, I'd be more comfortable if you made the change, as
I haven't touched that code
Hi J-S,
We all agree. Lets make atachment selection explicit. My proposal was
just an rhetoric response (if I may say so;-) to rhetoric question Robert
asked.
OK, so who does it? :-)
Smart move. I can do this. But only if you take the evangelization part
;-)
If you have the time, I'd
HI Wojtek,
I've just has a look at your changed RenderStage. The changed code is
below. Is there a reason why the #if !FORCE_COLOR_ATTACHMENT which
disables the draw and read buffer is done after the FBO apply? I
looks to me that one could simply have an #ifdef/#else. I do also
wonder whether
Hi Wojtek,
Smart move. I can do this. But only if you take the evangelization
part ;-)
I don't know what evangelism means in this context... It seems to me
that it just allows users to make better use of the resources they have.
But yeah, if you equate evangelism with being opinionated, I
Hi JS,
On Fri, Jul 24, 2009 at 3:21 PM, Jean-Sébastien
Guayjean-sebastien.g...@cm-labs.com wrote:
But yeah, if you equate evangelism with being opinionated, I can do that :-)
Ahh so we're all just evangelists round here then :-)
Robert.
___
osg-users
Hi Robert,
I've just has a look at your changed RenderStage. The changed code is
below. Is there a reason why the #if !FORCE_COLOR_ATTACHMENT which
disables the draw and read buffer is done after the FBO apply? I
looks to me that one could simply have an #ifdef/#else. I do also
wonder
Subject: Re: [osg-users] Frame rates vary dramatically across runs
Hi Wojtek,
Smart move. I can do this. But only if you take the evangelization part
;-)
I don't know what evangelism means in this context... It seems to me that
it just allows users to make better use of the resources they have
Hi Robert,
Ahh so we're all just evangelists round here then :-)
I'm not the one who said it :-)
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
Hi J-S,
I think if it gives a verifiable gain (less video memory used for depth
component RTT) then you can submit it. As you know, submission does not
mean that you need to be confident that it does not break anything, it
means that you are sending it for review. Robert will check it out, if
Hi Wojtek,
I think if it gives a verifiable gain (less video memory used for
depth component RTT) then you can submit it.
I saw direct improvement on GF 7800. On newer boards its smaller unless
the OSG application is GPU memory bound. Which happens quite often in
our practice.
But even if
Hi J-S,
Looking at the code, it seems like the same thing happens with the depth
buffer, i.e. a depth attachment will be created if none is present. IMHO,
a depth buffer is not mandatory - you could want to do an RTT pass on a
single fullscreen quad, in which case you don't need depth and can
Hi Wojtek,
GL_EXT_framebuffer_object spec allows FBOs without color attachments.
http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt see
issue (45) ). Its only an intutition but I suspect there were times that
despite the specs both attachments were required by the drivers and FBO
Hi ,
The code in osgUtil/RenderStage.cpp (as it stands now) automatically
attaches a depth buffer if there is none, and a color buffer if there is
none. Perhaps this code should be removed. If this causes problems to
applications on some drivers/cards, I think it's up to the application to
Hi,
It seems the issue was caused by using shadow maps that were too large. I
switched back to 4096 x 4096 and all is well.
...
Thank you!
Cheers,
Michele
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=15178#15178
Hi Michele,
It seems the issue was caused by using shadow maps that were too large. I switched back to 4096 x 4096 and all is well.
4096^2 is already large... Some of our cards here (9800GT) don't support
them (rendering slows down to ~3fps when at 4096^2, when it's at 60fps
steady at
Hi,
On Wednesday 01 July 2009, Michele Olsen wrote:
I am building an application using osg and recently I have been
experiencing dramatic changes in frame rate across runs. One run will have
140 + fps while the next run will have 15 fps. I was wondering if anyone
else has experienced this?
jean-sebastien.g...@cm-labs.com
To: osg-users@lists.openscenegraph.org
Sent: Tuesday, July 21, 2009 5:19 PM
Subject: Re: [osg-users] Frame rates vary dramatically across runs
Hi Michele,
It seems the issue was caused by using shadow maps that were too large. I
switched back to 4096 x 4096 and all
Hi Wojtek,
As I was summoned by shadow spell
Haha! :-)
Last time I checked OSG was also creating accompanying color
buffer for the depth shadow map. Which usually multiplies GPU memory
alocation by two (assuming RGBA is 32 bit and Z is 32 bit).
Wow, isn't that a bug? It surprises me
My machine is using a 9800 GTX and Ubuntu 8.04 32 bit btw.
Thanks for the help, and I hope the driver bug gets worked out.
...
Michele[/quote]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=15194#15194
Hi, J-S
Last time I checked OSG was also creating accompanying color buffer for
the depth shadow map. Which usually multiplies GPU memory alocation by
two (assuming RGBA is 32 bit and Z is 32 bit).
Wow, isn't that a bug? It surprises me that no one has tried to fix that,
it seems pretty
Hi Wojtek,
I am not sure... I believe that it was impossible to use depth only FBO
when they were initially introduced into OpenGL . But now it seems
possible at least on NVidia's because I made such modificattion and it
works ( in fact it gave me shadowing speedup improvements). But I did
Hi,
I am building an application using osg and recently I have been experiencing
dramatic changes in frame rate across runs. One run will have 140 + fps while
the next run will have 15 fps. I was wondering if anyone else has
experienced this?
Thank you!
--
Read this topic
Hi Michele,
This behavior is unusually, one might expect differences if cache
coherency or CPU affinity is not working well but no where near the
scale you are seeing. I would recommend looking at what other
processes are running on your machine. I'd also enable onscreen stats
to see what is
38 matches
Mail list logo
