[vtk-developers] OpenGL error checking in VTK

[burlen]

Hi All,

Heads up, the patch was merged this am. I'll make a cleanup pass 
tomorrow based on nightly dashboard failures.

Burlen

On 07/03/2013 04:43 PM, burlen wrote:
> Hi All,
>
> I'm preparing to merge a patch( 
> http://review.source.kitware.com/#/t/2980/) that implements OpenGL 
> error checking and reporting in VTK and I'd like to give you a heads 
> up and also to know if you have any comments or concerns before I make 
> the merge. Here is the summary of the work.
>
>      OpenGL error hunt
>
>       This patch implements OpenGL error checking in VTK.
>
>       OpenGL's error handling implementation error is designed such
>       that internal error flags remain set with the first error that
>       occurred until they are explicitly checked. With this design
>       it's important to check and clear the error flags regularly
>       else they become unusable as code checking for errors ends
>       up reporting earlier undetected unrelated errors.
>
>       This patch takes the following approach:
>
>       1) at public entry points into code that uses OpenGL clear the
>       error flags without reporting errors. This guards against
>       reportinig unrealted errors, such as those caused by code
>       outside of VTK. See vtkOpenGLClearErrorMacro
>
>       2) before returning from functions that made OpenGL calls check
>       for and report OpenGL errors. This detects Open GL errors in the
>       function/method where they occurred facilitating debugging and it
>       clears error flags so that user code doesn't detect errors caused
>       by VTK. See vtkOpenGLCheckErrorMacro
>
>       This patch cleans up a number of bugs that were detected by
>       the new error checking and reporting.
>
>       This patch also contains improvements for OpenGL pixel buffers, a
>       renderbuffer object, and fast paths through framebuffer objects,
>       and texture objects, and fast path for setting uniform variables,
>       all of which are needed in vtkSurfaceLICPainter and
>       vtkLineIntegralConvolution2D GPGPU code.
>
> After the merge you may see reports for previously undetected OpenGL 
> errors in your codes or ctest output. Also, on the Mac if you ask VTK 
> to render into an "invalid drawable" you will find that all subsequent 
> OpenGL calls fail  (until the drawable becomes valid) with 
> INVALID_FRAMEBUFFER_OPERATION reported. The "invalid drawable" issue 
> is not new (http://vtk.markmail.org/search/?q=invalid%20drawable). 
> However, until now one could ignore this as OpenGL errors were not 
> detected and reported. Going forward you will need to fix your code or 
> disable new gl error detection and reporting. To fix your code you can 
> make use of the new vtkRenderWindow::IsDrawable method to detect 
> invalid drawable and avoid asking VTK to render until the drawable is 
> valid. Alternatively you may disable OpenGL error detection via a 
> cmake variable allowing you to ignore the bug.
>
> My motivation for this patch comes from my experience debugging my own 
> VTK code and detecting errors that occurred elsewhere in VTK, in some 
> instances far away in space and time (measured in lines of code). 
> During this process I've noticed a good deal of variability between 
> OpenGL implementations, some are very robust and tolerant of errors 
> while others more strict/sensitive and can crash and burn on the same 
> code. The new error detection and reporting can help quite a bit in 
> tracking down cross platform/driver issues and ensures errors are 
> detected at their source.
>
> I think it would make sense going forward, that new code contributed 
> to VTK that makes use of OpenGL take the approach I described 
> above(with exception made for performance sensitive functions) so that 
> OpenGL error flags remain usable by all, allowing us to more 
> aggressively detect and fix bugs in our OpenGL codes.
>
> Please let me know if you have comments or concerns about this patch.
>
> Thanks
> Burlen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130711/b579c425/attachment.html>