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

[Paul Melis]

Hello Francois,

Well, I upgraded the driver to 96.43.01. As I expected it doesn't make 
the OpenGL version reported pre-1.4. In fact, it now reports it supports 
OpenGL 1.5.8 instead of 1.5.6 :)
See the attached glxinfo output.

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
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: glxinfo.964301.txt
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20080122/cca659e8/attachment.txt>