The new destruction free implementation of OSX CALayer offscreen layer in JOGL as performed in fixes for Bug 569 and Bug 599 is not stable for all GPU drivers yet. [1] The new FBO path does not work at resize w/ old Nvidia 7xxx GPU driver on OSX 10.6.8 and 10.7.4 At resize, validation of the FBO which just had re-attached buffers (with new size) the GL driver returns the FBO error state: GL_FRAMEBUFFER_UNSUPPORTED. According to the spec, this state claims that the following requirement is _not_ matched: The combination of internal formats of the attached images does not violate an implementation-dependent set of restrictions. However, we only resized the buffers, i.e. detached and destroy the old ones, created new ones where only the size differs (both were NPOT sizes) and attaches them. Then we fetch the FBO state again. +++ [2] PBuffer resize produces garbage on the screen at resize Due to lack of sufficient synchronization, the CALayer thread renders invalid data. Read: Using an invalid pbuffer. +++ [3] PBuffer resize crashes ATI driver after a while Due to [2] - using an invalid pbuffer, the driver crashes. +++
Note: 'Destruction free .. offscreen ..' point to the fact that we no more destroy the complete offscreen drawable at resize. No more do we destroy the drawable _and_ it's context at offscreen resize which caused: - going through dispose/init of GLEventListener - loosing all data of glcontext - loosing the prev. glcontext Now offscreen resize: - detaches the context from the drawable (FBO or pbuffer or bitmap), - destroys the drawable - creates a new drawable - re-attache the context to the new drawable The above process works fine w/ FBO (if FBO itself works fine, see [1]) but lacks some synchronization between destruction/creation w/ pbuffers on OSX.
(In reply to comment #1) > > The above process works fine w/ FBO (if FBO itself works fine, see [1]) > but lacks some synchronization between destruction/creation w/ pbuffers on OSX. In the FBO case, we actually don't destroy the drawable itself (here the FBO), but re-attach the buffers to the FBO as described in [1].
I've been testing from the git tip, trying combinations of some experiments Sven was making, FBResetQuirk and FBResizeQuirk. We were having problems with FBOs or PBuffers not working on various Macs. Even when it made a picture, we'd get junk in the window on resize. One graphics card crashed on resize. Here's some of what we've seen: Cast of Characters: nVidiaMac1: OS 10.6.8, nVidia GeForce 7300 GT, 2.1 NVIDIA-7.0.52 nVidiaMac2: OS X 10.7.4, nVidia GeForce 7300 GT, 2.1 NVIDIA-7.0.52 AMDMac: OS X 10.7.4, AMD Radeon HG 6970M, 2.1 ATI-7.18.18 ATIMac: OS X 10.7.4, ATI Radeon HD 6490M, 2.1 ATI-7.18.18 Originally, we were having problems with PBuffer on Mac. Sven has done a lot of work stabilizing and using FBOs instead, and here is where things stand. FBResizeQuirk doesn't seem to make a difference. When FBResetQuirk is false, these nVidia machines say the FBO format is unsupported on resize, though they work on the initial picture. The window becomes filled with junk. All the other machines work for all cases of these variables. All these machines work for PBuffer, specified by setPBuffer(true) and setOnscreen(true) in the GLCapabilities. But I think that the resize is just a bit jumpy. Originally, ATIMac's screen went black with PBuffer, but after updates, it seems pretty solid.
Commit 60c63acc298fd33ada43f37962d1d6c32a0359c3 fixes [2]: "OSX CALayer / MacOSXCGLContext: Remove pbuffer swap garbage; Split pbuffer/FBO revalidation/redraw .." Fix for issue [1] (FBO w/ old Nvidia 7xxx GPU on OSX) will follow up ..
I'm still getting unsupported FBO on my older nVidia. Is this fix still on the way? thanks andy
(In reply to comment #5) > I'm still getting unsupported FBO on my older nVidia. This is b/c it hasn't be fixed yet, otherwise I would have closed this bug. > Is this fix still on the way? IMHO a very inappropriate question, no need to get desperate :) It will be fixed, yes. Since Bug 616 (no XInitThreads, which 'inspiration' came from your department as well) has been solved there is now room for further bug fixes. So it's on the plate and will be fixed before RC11, i.e. all important known bugs shall be fixed by then. You still can send me further debug data of your test results (with all DEBUG enabled) you mentioned in your last PM. ~Sven
More in email, but briefly: Sorry, I did not intend to communicate at all what you heard. andy
Remedy is to catch the exception @ GLFBODrawableImpl.reset(..) and switch over to fallback 'reset' method: FBO reattachment -> FBO complete recreation Of course, the FBO recreation is noticable slower, but at least it seems to work on the offending system. Not tested on the offending system, but manually provoked GLException on FBOObject to trigger fallback, which is working here. See <http://jogamp.org/git/?p=jogl.git;a=commit;h=630d43be7a8cccf28632fc1f7542bb484382d775>
Created attachment 374 [details] output from simple JOGL program on resize
I attached the output from my sample app, after updating to JOGL as of Oct 8. thanks andy
Better detail: I get that output, but the program actually works. I got caught up with the message going to my screen, but I don't see a problem with the test app.
Very good, so we can reduce the message, or only dump it w/ DEBUG enabled. Maybe the latter to not annoy the user. Finally :)
verified by Andy Skinner