Corrupted FBO, can people download my app and tell me if it breaks for you?

Sage
Posts: 1,199
Joined: 2004.10
Post: #1
Basically, a few days ago, I started seeing corruption in some render-to-texture operations. It was working before, which makes me worried...

Now, here's what I'm seeing in GLProfiler:
[Image: Corruption-GLPRofiler.png]

And here's what I see rendered:
[Image: Corruption-Screenshot.png]

If I comment out the part that renders the tree -- e.g, I create and init the FBO, clear it, and then close it, then bind the texture and render, I still see the yellow noise block.

I recently saw a post on Apple's GL mailing list about PBuffers not clearing on NVIDIA 5200 cards, which is what I have. So, I was thinking that maybe this might just be related.

So here's a link to download a demo app where you can see if it's happening or not. By the way, it's PPC only. Sorry.

http://zakariya.net/shamyl/etc/WorldEngine.app.zip

The app is straightforward enough -- it's my tree generator, and I've set it to draw the "impostor" ( instead of automatically switching between solid and impostor rendering ).

If anybody has any experience with this kind of issue, I'd appreciate some pointers. Thanks,
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #2
:|
crashes on startup

Code:
Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   <<00000000>>     0x00000000 0 + 0
1   org.zakariya.worldengine           0x000080e4 -[GSOpenGLView update] + 372 (crt.c:355)
2   com.apple.AppKit                   0x93765e78 -[NSView _drawRect:clip:] + 2128
3   com.apple.AppKit                   0x93765438 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 404
4   com.apple.AppKit                   0x93768180 _recursiveDisplayInRect2 + 84
5   com.apple.CoreFoundation           0x907f3960 CFArrayApplyFunction + 416
6   com.apple.AppKit                   0x9376554c -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 680
7   com.apple.AppKit                   0x93768180 _recursiveDisplayInRect2 + 84
8   com.apple.CoreFoundation           0x907f3960 CFArrayApplyFunction + 416
9   com.apple.AppKit                   0x9376554c -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 680
10  com.apple.AppKit                   0x93764a00 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForV​iew:topView:] + 196
11  com.apple.AppKit                   0x93785664 -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForV​iew:topView:] + 192
12  com.apple.AppKit                   0x9375e674 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 384
13  com.apple.AppKit                   0x93753968 -[NSView displayIfNeeded] + 248
..
..

Im using 10.4.6 btw

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #3
Huh. It ran on my powerbook and my g5... what kind of machine do you have?

That said... I solved the problem while writing a similar message to the mac-opengl mailing list. It turns out that glClear respects the current viewport. I guess that's obvious, but it hadn't occurred to me. I'd assumed it cleared the context...
Quote this message in a reply
Apprentice
Posts: 11
Joined: 2005.09
Post: #4
Crashed on load for me:

Code:
Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   <<00000000>>     0x00000000 0 + 0
1   org.zakariya.worldengine           0x00049f5c WorldEngine::CelestialBody::settingsChanged(WorldEngine::Settings*) + 56
2   org.zakariya.worldengine           0x0004a070 WorldEngine::SkyDome::settingsChanged(WorldEngine::Settings*) + 108
3   org.zakariya.worldengine           0x000317bc WorldEngine::World::settingsChanged(WorldEngine::Settings*) + 444
4   org.zakariya.worldengine           0x0003ae04 WorldEngine::World::initialize(PANSICore::ManifestDOMObject*) + 936
5   org.zakariya.worldengine           0x000383c4 WorldEngine::World::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> >) + 1612
6   org.zakariya.worldengine           0x000b04fc WorldEngine::ScenarioLoader::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> >) + 1484
7   org.zakariya.worldengine           0x000c36bc ScenarioRunner::eventAppInitialized() + 1072
8   org.zakariya.worldengine           0x00006928 -[GSApplication applicationDidFinishLaunching:] + 108
9   com.apple.Foundation               0x92975ad8 _nsnote_callback + 180
10  com.apple.CoreFoundation           0x9080b010 __CFXNotificationPost + 368
11  com.apple.CoreFoundation           0x908030ec _CFXNotificationPostNotification + 684
12  com.apple.Foundation               0x9295fee0 -[NSNotificationCenter postNotificationName:object:userInfo:] + 92
13  com.apple.AppKit                   0x93722338 -[NSApplication _postDidFinishNotification] + 112
14  com.apple.AppKit                   0x93722224 -[NSApplication _sendFinishLaunchingNotification] + 92
15  com.apple.AppKit                   0x93721d6c -[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 264
16  com.apple.AppKit                   0x93721914 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 92
17  com.apple.Foundation               0x92976ae4 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 380
18  com.apple.Foundation               0x92976944 _NSAppleEventManagerGenericHandler + 92
19  com.apple.AE                       0x91534960 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 208
20  com.apple.AE                       0x915347fc dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 44
21  com.apple.AE                       0x91534654 aeProcessAppleEvent + 284
22  com.apple.HIToolbox                0x932200e0 AEProcessAppleEvent + 60
23  com.apple.AppKit                   0x9372005c _DPSNextEvent + 856
24  com.apple.AppKit                   0x9371fb48 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116
25  com.apple.AppKit                   0x9371c08c -[NSApplication run] + 472
26  com.apple.AppKit                   0x9380cbfc NSApplicationMain + 452
27  org.zakariya.worldengine           0x0003f6fc main + 764
28  org.zakariya.worldengine           0x0000304c _start + 340 (crt.c:272)
29  org.zakariya.worldengine           0x00002ef4 start + 60

It does this every time.
Quote this message in a reply
Apprentice
Posts: 14
Joined: 2004.07
Post: #5
Runs fine with a ATI 9600, 10.4.6, dual 2.0 G5. No artifacts that I can see.
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #6
Ran fine for me on a G5 iMac, 10.4.6.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #7
Could the folks with the crashes let me know what hardware/gpus/etc they had?

I should emphasize, this is PPC only; untested on x86 under rosetta. Also, the build linked above still has the bug I originally mentioned, I haven't updated it.
Quote this message in a reply
Apprentice
Posts: 17
Joined: 2005.05
Post: #8
Works fine for me, no corruption, no crashes.

20" iMac Core Duo x1600 256MB VRAM.

Gets about 100fps on a complex tree (~200verts)
Quote this message in a reply
Apprentice
Posts: 11
Joined: 2005.09
Post: #9
My crash is with: 1.25 GHz G4, 768 RAM, ATI Radeon 9200 (32MB), Mac OS 10.4.6
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #10
Matrix Wrote:Works fine for me, no corruption, no crashes.

20" iMac Core Duo x1600 256MB VRAM.

Gets about 100fps on a complex tree (~200verts)

Oh. My. God. It works under Rosetta!

Regarding the crashers, I'll have to do some investigating. My guess is that it's crashing on machines with old video cards; I don't really push GL that hard, and where I do I attempt to query for support... but given the crash in CelestialBody::settingChanged I think that's a situation where my querying for presence of occlusion queries is causing a crash in an old card.

My powerbook has a 5200 with 64 mb vram. Since that card is indisputably a worthless piece of dog sh*t I think it's fair to target it as bottom-end for support.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #11
If you're using FBOs, I don't think they're supported on video cards that don't also support pixel shaders. (also, you can just look at aarku's page) If the functions don't work, that might explain the crash.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #12
akb825 is correct. This restriction appears to be arbitrary, but is in line with the PC drivers. He's incorrect about it being aarku's page though Rasp The page is Arekkusu's: http://homepage.mac.com/arekkusu/bugs/GLInfo.html
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #13
Bah! I remembered the a, r, and k, and ended up picking the shorter name. Rasp Damn those similar names! Wink
Quote this message in a reply
Member
Posts: 260
Joined: 2005.05
Post: #14
TomorrowPlusX Wrote:I don't really push GL that hard, and where I do I attempt to query for support...
I'd say that using FBOs in any way at all is pushing OpenGL pretty hard. Remember, ATI didn't support them even on PCs one year ago, and as far as I know, they are still EXT, not ARB and certainly not standard. Correct me if I am wrong, but I can't find the FBO calls in the Red Book 5th ed.

I learned FBOs fairly recently, so I am not very experienced, but in the experience I have, they succeed or fail on rather small differences in the code, depending on hardware. In particular, things happen when I go between ATI and NVidia. If I use float buffers, it gets even harder.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #15
Did they even exist a year ago?

FBO is the new standard way to do PBuffers. It doesn't push any harder than a PBuffer; the graphics vendors just chose to implement it only for hardware "current" at the time.

Yes, it's "just" an EXT extension, but it's one that is agreed upon by ATI, NVidia, Apple, etc. -- "promotion" to ARB or the core spec is probably just a matter of time -- not that it's at all relevant. There is no sense in which an ARB extension or a core feature is "better" than any other extension, other than possibly wider availability.

There are restrictions that apply to depth and stencil buffers due to the limitations of the hardware. EXT_packed_depth_stencil fixes those. There is no support for multisampling, due to the formulation of the extension. EXT_framebuffer_blit and EXT_framebuffer_multisample combined fix those. None of those extensions are yet available for Mac OS X.

There are severe limitations of all current hardware when it comes to rendering into float buffers. Intel GMA 950s don't support it at all; GeForce FXs may have issues with texture targets other than TEXTURE_RECTANGLE_(ARB|EXT|NV). Most hardware has severe limitations on where blending or multisampling is possible.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  GLSL Shader getting corrupted Weebull 4 4,727 Jun 23, 2008 03:43 PM
Last Post: Weebull
  Isometric people skrew 8 5,994 Feb 15, 2006 01:33 AM
Last Post: skrew
  Tiger breaks SDL? sealfin 7 5,043 Jun 10, 2005 07:13 AM
Last Post: sealfin
  Mosquito Fighter Test Available for Download! please try it NYGhost 47 14,537 Jul 14, 2003 08:15 AM
Last Post: NYGhost
  cocoa release breaks drawarrays kelvin 4 3,282 Feb 26, 2003 01:44 AM
Last Post: kelvin