|
|
Pixmap rendering 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 ? |
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)glReadPixelsis 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_pixmaplooks like a primitive version of FBOs (the modern way to perform Render To Texture -- much more flexible thanEXT_texture_from_pixmap)What exactly are you trying to accomplish/accelerate with this?
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 ?
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.
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
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. :/
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 ;)
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".