Pbuffers on Mac

[psiegel]

Not having a Mac myself, but having a Mac user testing code remotely for me has led me to make blind stabs in the dark as to the cause of various bugs.  So I figured I'd ask this generic question: has anyone tested pbuffers on a Mac?  Are there any known issues using pbuffers in the Mac port?

Paul

[elias]

Yep - "it ain't supported" :-)

As far as I know, up until 10.2 a pbuffer on the mac is in fact an in memory array of pixels that you can draw into and then read from directly. Useful, but not quite what you would expect from a LWJGL Pbuffer. I think I saw somewhere that Mac OS X 10.3 includes a "real" pbuffer, but in that case it's not implemented in LWJGL (yet). In any case, 10.3 is still too new to rely on, in my opinion.

- elias

[psiegel]

Your description of the 10.2 pbuffer sounds like a normal pbuffer to me (not that I really know a whole lot about them).  What other features would you expect from a "real" pbuffer?

Paul

[elias]

Think of a "real" pbuffer as a an invisible window with a gl context attached to it. It lives (presumably) on the vid mem of your gfx card and therefore it can be accessed just as fast as a gl window when drawing to it and when copying some of its contents to a texture. A Mac pixel buffer does not live in vid mem (because you specify the memory it resides in), and therefore cannot be used effectively for anything else than real offline rendering (post render processing etc.).

- elias

[psiegel]

Ah I see.  Well that is sad, as this will likely mean putting off the Mac port of our game yet longer.

Paul

[elias]

I'm curious as to what exactly you need the Pbuffer for anyway? In TT you can set a property to determine whether the texture generation should happen in the framebuffer itself or in a separate Pbuffer. You usage might vary though.

- elias

[princec]

Got no Pbuffers? Order your drawing so that "pbuffer-like" drawing happens in the frame backbuffer.

Pbuffers aren't really needed at all, really. They're just bells and whistles.

Cas

[spasi]

The way they work, yeah it sucks. All the system specific context stuff are totally stupid. But they are useful when you need textures bigger than your window (e.g. shadow-mapping) and render-to-texture gives a nice performance boost (at least on win32).

psiegel, you may want to wait for the new EXT_render_target. It's going to be much "lighter" than pbuffers (no context switches, etc.) so probably faster too (and much cleaner!). From what I've read, NV is going to support it in all its cards that already support render-to-texture (TNT and up :wink:) and I hope they'll be able to support it in systems other than win32 :x... I don't know about ATI though. They haven't said anything about this yet.

[elias]

Yes, I look forward to EXT_render_target too. I believe d3d has had similar features for years.

- elias

[psiegel]

Cas -
Yeah, but copying from the frame's back buffer into a texture is damn slow.  And re-ordering my rendering order really isn't an option given what I mention below.

Everyone else -
Waiting on a new extension strikes me as being even slower that waiting for the LWJGL developers to figure out a way to make pbuffers work on Mac.    At least I can try and pester the LWJGL developers directly in hopes of getting what I want.

Honestly, all I want is a hardware accelerated 2D blitter for Java (which includes blitting to offscreen images in memory, not just the window).  At this point I've written up a nice interface abstraction layer to my blitter so I can swap what's being used underneath quickly and easily.  I've got implementations using Java2D, LWJGL, and a custom jni lib that wraps DirectX.  I was really hoping the LWJGL version would work for both Linux and Mac, but it looks like it'll only solve Linux for me.  What I really need to do is get my hands on a Mac so I can write a custom jni lib for it like I did with DirectX -- though I'm really not looking forward to learning what DirectX like libraries may (or may not) exist on Mac.

Or I could just take the road too often taken by every other game developer -- give up on Mac.

Paul

[spasi]

You should pester the MacOS developers instead , we'd have it done if it was possible! I just hope that Elias is right and 10.3 has it.

But, you should anyway implement a path for framebuffer rendering/copying. Not every card out there supports pbuffers (it's not as simple as blitting, it's a hardware thing), and since we're talking about non-win32 machines, you can't avoid the texture copy (it's probably even faster copying from the framebuffer than a pbuffer - given your texture fits there).

[elias]

Spasi is right, if render-to-texture is not supported (linux and mac os x), my experience is that it's faster to copy from the framebuffer into a texture than from a pbuffer. Basicly, Pbuffers are pretty much useless for interactive 3d, except if you need some texture pregenerated at runtime with weird properties (too large for the framebuffer or a different pixel format)

- elias

[psiegel]

I just wanted to post and say that you guys were once again completely right.  I eventually stumbled onto a way to change all my blits into logical objects and maintain a sorted list of them, thus waiting until the request to swap the main window's back buffer to perform any and all blits.  With that done, I can now use the main window's back buffer as an offscreen surface without worrying that it happens after "real" blitting to the main window has happened.

So it works great, even ups the performance on my linux box a good deal compared to the pbuffer approach.  Looks like my Mac port is back on track.  

Thanks guys!

Paul