Pixmap rendering

yanomano's picture

When i was searching infos on forums for glCopyTo Texture (which seems to be the fundation of the "Render in Image" patch...as I understand) and glReadPixel, i found explanation about " EXT_texture_from_pixmap" which seems to be a more fast Opengl function to recover a texture from a color buffer... Pixmap on opengl.org Interesting duscussion on a french forum

Does it make sense ?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cwright's picture

glCopy* can be made asynchronous with some apple extensions (making it very fast when used -- QC can't really use this because patches don't have enough time from start to finish to take advantage of this). It can also take place entirely in vram, making it very very fast (no cpu stall, no bus saturation)

glReadPixels is terribly slow, and shouldn't be used -- it always reads across the bus, which is painfully slow, and stalls both the CPU and the GPU. No small tweaks to this will make it practical.

EXT_texture_from_pixmap looks like a primitive version of FBOs (the modern way to perform Render To Texture -- much more flexible than EXT_texture_from_pixmap)

What exactly are you trying to accomplish/accelerate with this?

yanomano's picture

I want to render in image a lot of bigs macros patches...I have to replug all the published inputs...And don't know if it will be finaly very efficient in FPS terms. so I was searching infos about the read pixel patch to see if it could be an alternative solution. But it seems that it have a bug and don't render realtime as you explain it somewhere in the kineme forums.) And as you say, glReadPixels is very slow (that was what i find also in anothers forums...) As I understand FBOs were introduced with opengl 2.0 ? Is it actualy somewhere in action in QC 3.0 ?

cwright's picture
not sure

It's available (GL_EXT_framebuffer_object) on my gma950, in apple's software renderer, and on the nvidia 8800, so I'm guessing it's available everywhere (except for ancient machines, where ancient means "before 2006").

the GLTools realPixels patch used glReadPixels, and used an incorrect time mode (it's private for a reason: we didn't polish it, and didn't think it was useful for most situations.. however, we had started it, and didn't want to take it out.). This is why it acted somewhat strangely, and was slow. The next GLTools update corrects both of these issues.

Render In Image might use fbo's, but I'm not certain -- we've not taken apart that patch to see how it works yet. Vade has some working FBO plugins though, so I know that it works.

toneburst's picture

and vade's FBO-based patches are FAST.... I got the impression vade was assuming the Render In Image patch didn't use FBOs, but I may have misunderstood.

a|x http://machinesdontcare.wordpress.com

cwright's picture

they are fast, from what I've seen.

I don't know that render to texture is particularly difficult/slow using most of the methods available, but vade's implementation does allow for fancy fbo flags to be set (antialiasing being the noteworthy one that comes to mind) -- thus, he was able to make a render-in-image-like plugin that output a nicely antialiased image without having to do any tricks.

I don't know more details, unfortunately. :/

yanomano's picture
From an actual test with a

From an actual test with a very big patch inside the render in image, i'am very surprised that my FPS don't fall...:) Render in image = possibly FBO So it seems that i'll have to repatch all my spaguettis in confidence ...Then doors are opened to post-process ;)

gtoledo3's picture
No kidding? Anti-aliasing

No kidding? Anti-aliasing huh?

This somewhat out of place here, but on "faking sprite anti-aliasing" tip, I truly enjoy the benefits of what is "softRec CI".