[gephex-devel] opengl and gephex

[Manuel Massing]

Hey,

great to see someone envisaging an OpenGL integration :-) I've just been
waiting (yeah, lurking :-)) for an easy way to get some 3d running with
gephex...

> > - There is one Core class. This class wraps every call there is (or
> > every call that is used) of opengl (Note: this could be any rendering
> > system).

is it really necessary to wrap a whole 3d api? this seems a bit ambitious.
besides, it's not in the interest of someone who writes OpenGL apps and
would like to port them to a gephex module... I am assuming here that
you don't want to build something along the lines of a scene graph manager,
but just a technical framework to do some hardware-accelerated 3d or
2d image processing.

I confess I don't know much about the gephex architecture, but wouldn't it be
sufficient for the graph scheduler to provide an adequate opengl context, i.e.
uploading input textures and setting an output context before GL-module
activation? or at the limit, provide a state manager. But I doubt state
changes will be of any concern (performance wise) compared to texture-upload /
download ops or framebuffer clears.

so, i guess i'll just add some random notes to the discussion. excuse me if
i miss the point :-)

	- transitioning image data out of a GL chain is expensive (i.e.
	  GPU-to-memory transfer!) ideally, a GL chain should therefore mark
	  the endpoint of the graph, i.e. use OpenGL for device output.
	  does the architecture allow for typed data streams? if so, make
	  opengl "images/textures" an own type and define portal modules (convert
	  image to glimage type) for transition into (texture upload) and out of
	  gl/gpu-space. 

	- the minimal gl specific scheduling would be: managment of texture
	  id's, state managment, output context management. 

	- I think a single (image) output sink is sufficient for any GL processing
	  module. i am assuming here that only image (RGB) output is propagated, and
	  only in the form of textures (no shared framebuffers), i.e. depth
     information is discarded between GL modules (which makes sense, the
	  depth values being a function of the projection matrix, so that wouldn't be
	  really consistent anyway...)

	- so, for glmodules, the minimal GLscheduler would need to [apart from the 	
	  texture resource management/propagation, but I this can be handled the same
	  way as "other" graph resources]: 

		- set the current context to either a framebuffer object(render-to-texture),
		  or a visible buffer (if the GL module marks the end point of an effect
		  chain). this way, it will be transparent to the gl module where the output
		  goes. if FBOs are too state-of-the-artish (don't know if NVIDIA has
		  implemented them on linux yet?), bite the bullet and use pbuffers. 
		- maybe clear the framebuffer?
		- on first activation of the gl module, restore default opengl state, or
		  call a special GL setup routine. load previously saved state* otherwise. 
		- call glModule->activate(),->update(),->render(),whatever()
		- save opengl state*
		- manage/share the freshly rendered texture id.

	*caveat: don't know if there is an easy way to store state information for
	         all those gl extensions. that's where a state manager might make
	         sense

	- GLModules would only need a method to retrieve the input texture IDs, and
	  could handle rendering/processing like a normal opengl app. 

i guess what i want to say is that having a pure GLish environement for
module processing is a desireable property for many applications :-) 

bye,

	Manuel