On Jan 27, 2012, at 4:12 PM, Jason Daly wrote:
>
> On 01/27/2012 04:17 PM, Doug McCorkle wrote:
>> We run a very similar system with 5 quadro cards and do not run into these
>> problems with very large models. We are using VR Juggler though. I mention
>> this because it would be very straight
On 01/27/2012 04:17 PM, Doug McCorkle wrote:
We run a very similar system with 5 quadro cards and do not run into these
problems with very large models. We are using VR Juggler though. I mention this
because it would be very straight forward to use one of the sample OGL VR
Juggler examples as
Hello Jason,
On Jan 27, 2012, at 1:37 PM, Jason Daly wrote:
> On 01/27/2012 02:12 PM, Paul Martz wrote:
>> Sorry, I was going off your post that read "This leads me to believe that bus
>> contention was causing the lack of scalability." I was just trying to
>> outline a
>> way to validate that s
Hi All,
I haven't chipped in so far as I haven't really too much to add to the
investigation. My sense from own tests and looking at others over the
years is that looks to be contention in the drivers that leads to poor
scaling. Reducing the amount of data and commands being pushed in
each conte
Sean,
Don't know conclusively, but I have had problems like this in the past when
using dynamic_cast on a polymorphic object and it failed to give a non-NULL
value even when I knew it should. As you said, using a static_cast or C-style
cast works. In my case it had to do with how objects were
On 01/27/2012 02:12 PM, Paul Martz wrote:
Sorry, I was going off your post that read "This leads me to believe that bus
contention was causing the lack of scalability." I was just trying to outline a
way to validate that suspicion. If you've already ruled out bus contention, then
disregard my pos
My scene contains virtualplanetbuilder-generated terrain that has a texture
wrapped on it along with surface objects such as trees that I generated by
creating osg primitives and coloring them "PER_VERTEX" without using any
textures.
I have written an atmospheric transmission shader that decrea
Sorry, I was going off your post that read "This leads me to believe that bus
contention was causing the lack of scalability." I was just trying to outline a
way to validate that suspicion. If you've already ruled out bus contention, then
disregard my post.
-Paul
On 1/27/2012 11:40 AM, Jas
Hi, Paul,
As Tim pointed out earlier, the more limiting resource is likely to be
lock contention in the NVidia driver instead of bus contention.
Note that Bb is going to be 4000 MB/sec (500 MB/sec * 8), per Quadroplex
(PCI-e 2.0 8x) on the NIST machine. On my system I have an X58 chipset,
Hi Tim,
Thanks for the suggestion. I'll definitely take a look at it. I saw your
response in another thread about RTT and was going to PM you before I saw you
respond here.
>From reading the OpenGL specification, FBOs can't be shared between graphics
>contexts, so it doesn't look like I have a
Hey guys,
I'm trying to pass an osgViewer::GraphicsWindowCocoa::WindowData to my traits
object with CreateOnlyView specified. For some reason whenever my WindowData is
dynamic_cast in GraphicsWindowCocoa.mm it just returns 0. If I switch them to
static_cast they work.
Here's my code:
Code:
/
On 01/27/2012 04:38 AM, Sergey Polischuk wrote:
As a side note:
if you were using vbo's instead of display lists for drawing i think you werent
get into this problem in first place, as with vbos 5500 draw calls would
happily kill your performance even on one screen, so you have to optimize your
On 1/27/2012 7:17 AM, Paul Martz wrote:
Bb
FPS =
Nw * Nd * Sd + O
Where Bb is the bus bandwidth in bytes,
Upon rereading this, a few corrections:
Bb
FPS = --
Nw * (Nd * Sd + O)
And note that Bb is bandwidth in bytes/sec,
On 1/27/2012 7:17 AM, Paul Martz wrote:
> Sd is the size of the drawing commands in bytes
gDebugger might be able to help you estimate this too.
--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Train
Hi Jason -- I agree that the system bus is a likely source of the scaling issue.
It is certainly a single resource that has to be shared by all the GPUs in the
system.
To make a case for bus bandwidth limitation, you might work through the math.
Bb
FPS =
Nw *
Hi Robert,
Am 26.01.12 19:02, schrieb Robert Osfield:
> So disabling the feature would be fine for OpenGL ES, but on setting a
> non zero RowLength osg::Image under OpenGL ES it should emit a warning
> that it's not supported.
thanks for the explanation, I'll code + submit a fix for review.
chee
2012/1/17 "Martin Großer" :
> Hello all,
>
> A few weeks ago, I want to render my scene into a texture, which I want to
> use in the final rendering on a screen aligned quad. My first problem was I
> lost the shadows, because view dependent shadow techniques don't work with
> nested cameras. So
Thank you Chris for your reply.
I am still trying to solve the problems. One thing that have helped me is
changing this line:
AudioSink(osg::AudioStream* audioStream): _started(false), _paused(false),
_audioStream(audioStream) {play();}
for this line:
AudioSink(osg::AudioStream* audioStream): _
On Thu, Jan 26, 2012 at 5:58 AM, Adam Bruce wrote:
> Hi again,
>
> Thanks for following up. I've tried it before with an attached pbuffer, but
> was - and still have been - getting unpredictable results. As before, if I
> simply place a camera as a node in the scene and attach a texture with FBO
As a side note:
if you were using vbo's instead of display lists for drawing i think you werent
get into this problem in first place, as with vbos 5500 draw calls would
happily kill your performance even on one screen, so you have to optimize your
models. Nvidia drivers are great at optimizing c
On 26 January 2012 20:50, Mohammed Rashad wrote:
> still same error..
>
> can you give me a step by step explanation
I did tell you all the steps you need to do and present a number of
different routes you can try. I really can't add much more.
Robert.
__
Same here... No solution :( msvs rocks and stuff, but dropping linux support is total fail 27.01.2012, 12:29, "Riccardo Corsi" :Hi Sebastian,this is a little off-topic, but this might interst others as well.I have been using gDebugger 5.8 (the last before AMD decided to make it a visual studio 201
Hi Sebastian,
this is a little off-topic, but this might interst others as well.
I have been using gDebugger 5.8 (the last before AMD decided to make it a
visual studio 2010 plugin, damn it!)
until 2 days ago, when my free 1-year-licence expired.
Since then I was unable to run it again, I tried
23 matches
Mail list logo
