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:


And here's what I see rendered:


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,

:|
crashes on startup


Im using 10.4.6 btw

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...

Crashed on load for me:


It does this every time.

Runs fine with a ATI 9600, 10.4.6, dual 2.0 G5. No artifacts that I can see.

Ran fine for me on a G5 iMac, 10.4.6.

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.

Works fine for me, no corruption, no crashes.

20" iMac Core Duo x1600 256MB VRAM.

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

My crash is with: 1.25 GHz G4, 768 RAM, ATI Radeon 9200 (32MB), Mac OS 10.4.6

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.

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.

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 The page is Arekkusu's: http://homepage.mac.com/arekkusu/bugs/GLInfo.html

Bah! I remembered the a, r, and k, and ended up picking the shorter name. Damn those similar names!

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.

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.