[vtkusers] Re: Rendering slowed down after recent CVS update

[Francois Bertel]

Hi Paul,

Paul Melis wrote:
> I am very doubtful it will make a difference. In NVidia's OpenGL
> extension specifications it says that this card (based on an NV25 chip)
> does not support the extension. See
> http://developer.download.nvidia.com/opengl/specs/nvOpenGLspecs.pdf   An
> earlier version of this document (dated somewhere in 2003) clearly marks
> the extension as being emulated in software for NV2x cards, with a note
> to expect slow performance.
> I attached the output anyway.

Thanks for your feedback.

Actually, I think it might make a difference :-) If the new driver upgrade reports an OpenGL version less than 1.4 (currently it reports OpenGL 1.5), and does not report "GL_EXT_blend_func_separate" in its list of extensions, you will have your performance back without changing any VTK code.
I'm explaining that later in this message.

Anyway, I'll take a look at pages 6 to 10 of the nvidia document to see if there is any other functionality implemented in software and try to make the vtkOpenGLExtensionManager aware of that.

> Interestingly, the extension list doesn't
> have the blend_func_separate extension, while VTK obviously gets some
> function pointer when querying for this extension.


The VTK behavior is the right one.

Extension "GL_EXT_blend_func_separate" was promoted as a core feature of OpenGL 1.4.
VTK first checks if this version of OpenGL is supported by the card, if so, it uses the function pointer of "glBlendFuncSeparate".
If not, VTK gives a second chance by checking directly for the extension. If this is supported, it uses the function pointer of "glBlendFuncSeparateEXT".

The Linux driver of your graphics cards says it supports OpenGL 1.5 so the VTK logic falls in the first case.

It has to happen in this order because some OpenGL implementations only report the OpenGL version they support and they put only extra extensions in the list of their extensions.

For instance, on the mac, if you want to use 3D textures, the graphics card says it supports OpenGL 1.2 (which has GL_EXT_texture3D as a core promoted extension) but it does not list
GL_EXT_texture3D in its list of extensions.

Ref: OpenGL 2.1 spec, Appendix G "Version 1.4", G.9 "Separate Blend Functions", page 335 (pdf page 349). http://www.opengl.org/registry/doc/glspec21.20061201.pdf


To sum up, please still give a try to a driver upgrade and let me know about it.

Regards.


>> Paul Melis wrote:
>>> / Paul Melis wrote:
>> />/ />>/ Sean McBride wrote:
>> />>/
>> />>>/ /On 1/16/08 4:24 PM, Paul Melis said:
>> />>/ />/
>> />>/ />>/And another reply to myself...
>> />>/ />>/After going back to a CVS version of VTK of October 1st the
>> />>/ problem />>/seems to be gone. So something changed in VTK between
>> />>/ october and today />>/that influences the render performance,
>> probably
>> />>/ due to a software />>/fallback suddenly being used in the NVidia
>> driver.
>> />>/ />>/    />>/
>> />>/ />/
>> />>/ />/Next try Nov 1, Dec 1, etc. until you have it narrowed down to
>> />>/ between 2
>> />>/ />/days... tedious, but easy.  You'll probably find the problem
>> this way.
>> />>/ />/  />/
>> />>/ /Well, I made a little script that did all the hard work of checking
>> />>/ out a CVS version for specific date, configuring it with cmake,
>> />>/ building it, setting appropriate environment variables and then
>> />>/ running a little test application. The results indicate that the
>> />>/ problems start with commits done on October 27. I suspect the
>> changes
>> />>/ relating to alpha handing (for bug 2347) in
>> vtkOpenGLRenderWindow.cxx
>> />>/ and friends, although I don't see anything suspicious in the code.
>> />>/ Most of the changes seem related to depth peeling and using
>> different
>> />>/ blending, but I'm not enabling depth peeling and are also not using
>> />>/ any transparent geometry.
>> />>/
>> />>/  />>/
>> />/ />/ Okay, further testing shows it is indeed related to using a
>> different
>> />/ blending function. If I take the faulty revision and only comment out
>> />/ the calls to glBlendFuncSeparate in vtkOpenGLRenderer.cxx and
>> />/ vtkOpenGLRenderWindow.cxx the problem goes away, i.e. performance is
>> />/ restored. So it looks like a software fallback is used as
>> side-effect of
>> />/ this call. Yuck. The card (actually driver) says it's OpenGL 1.5
>> />/ capable, and glBlendFuncSeparate was introduced in 1.4. But it
>> doesn't
>> />/ seem to be hw-accelerated...
>> />/ />/ I guess there's not much of a work-around for this, except a card
>> />/ upgrade :-/
>> />/ />/ Paul


-- 
François Bertel, PhD  | Kitware Inc. Suite 204
1 (518) 371 3971 x113 | 28 Corporate Drive
                      | Clifton Park NY 12065, USA