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

[Paul Melis]

Hello Francois,

>By card upgrade, try a driver upgrade first. http://www.nvidia.com/object/unix.html
>  
>

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.

>You card is listed in the legacy section:
>http://www.nvidia.com/object/IO_32667.html
>
>It means you have to deal with the latest legacy driver available for Linux:
>
>http://www.nvidia.com/object/linux_display_x86_96.43.01.html
>
>Once you try this new driver, two cases:
>
>1. it works, just let us know
>2. it is still slow, I'll try to make the vtkOpenGLExtensionManager aware of this particular card and of this software fallback. I will need the output of glxinfo:
> $ glxinfo > output.txt
>  
>
I attached the output anyway. Interestingly, the extension list doesn't 
have the blend_func_separate extension, while VTK obviously gets some 
function pointer when querying for this extension.

Regards,
Paul

>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
>/>/ 
>/>/ 
>/>/ _______________________________________________
>/>/ This is the private VTK discussion list. Please keep messages on-topic.
>/>/ Check the FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>/>/ Follow this link to subscribe/unsubscribe:
>/>/ http://www.vtk.org/mailman/listinfo/vtkusers
>/>/ 
>/
>
>-- 
>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.txt
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20080121/7479113e/attachment.txt>