hi list.
i just wanted to inform you what i have done recently:
#------------------ 1) branching: there are several branches that i have created, namely "SIMD" (for MMX support) and "multiple_window"
1x) *stupidity*: while branching seems simple, i have experienced that it is a bit beyond my reach. i have done a lot of really stupid things, namely: - branching single files: this is stupid as you cannot update the whole source-tree to the branch (it will delete files that are not in the branch); i hope i have fixed this for now - branching from other branches, that have nothing in common; even worse, only part of the files were branched from another branch, while others were branched from HEAD. this has often lead to an uncompilable source-tree. i *hope* i have fixed this for now - tagging instead of branching: unfortunately "tag" is the default on my graphical cvs-interface, so i have tagged several files instead of branched. with a lot of removing and re-adding i might have fixed this, but i am not sure at all...
however, i apologize for my stupidity and hopefully will think before acting in the future.
1a) "SIMD": i have tested it under linux and windows and it works (although i am a bit disapointed of the performance-gain; unfortunately i have no SSE2 machine at hand so i haven't tried this yet); however, i have not tried to compile it under osX yet. the SIMD-functions are named uniformly for all subclasses of GemPixObj (and GemDualObj) and are called automatically if present.
1b) "multiple_window": (there is also a TAG with this name, so beware!) this separates the functionality of [gemwin] (which has vanished) into 2 objects [gemcontrol] and [gemwindow], where [gemcontrol] is the interface to the rendering-engine (GemMan) and [gemwindow] handles the window-management. a lot of code has moved from GemMan to gemwindow; there is a new directory src/Output for alternative output-modules. currently it only holds [gemextwin] which can be used to replace [gemwindow] to render into an externally created window (this really works: http://iem.at/~zmoelnig/GEM/plugin/ ); currently this object compiles under windows & linux but is working only under linux. multiple output-modules can be connected to a [gemcontrol]. there are still a *lot* of problems, so i guess it is not ready for testing.
#--------------- 2) new directories:
apart from the Gem/src/Output directory i have also created the long awaited Gem/abstractions directory. currently it is empty (it holds a [gemwin]-replacement in the multiple_window branch) and waits to be populated
#--------------- 3) i have just created a mailinglist pd-gem-cvs@lists.sourceforge.net for email-notifications on CVS-changes (like the pd-cvs list); it will take some hours until it is online i have received email-notification on the CVS-changes for some time and probably someone else is interested too.
+++++++++++
mfg.a.asdr IOhannes
On Aug 17, 2004, at 10:08 AM, IOhannes m zmoelnig wrote:
1x) *stupidity*: while branching seems simple, i have experienced that it is a bit beyond my reach. i have done a lot of really stupid things, namely:
...this is what I'm afraid of: many different versions going out in different directions, each with some small "stupidity" mistake, making for a fool's errand to find out if it's even worthwhile...
however, i apologize for my stupidity and hopefully will think before acting in the future.
...I'm sure we're all going to make mistakes for awhile...
1a) "SIMD": i have tested it under linux and windows and it works (although i am a bit disapointed of the performance-gain; unfortunately i have no SSE2 machine at hand so i haven't tried this yet); however, i have not tried to compile it under osX yet. the SIMD-functions are named uniformly for all subclasses of GemPixObj (and GemDualObj) and are called automatically if present.
...why would you try to compile it under OSX? Are you writing altivec? What is it a branch of?
1b) "multiple_window": (there is also a TAG with this name, so beware!) this separates the functionality of [gemwin] (which has vanished) into 2 objects [gemcontrol] and [gemwindow], where [gemcontrol] is the interface to the rendering-engine (GemMan) and [gemwindow] handles the window-management. a lot of code has moved from GemMan to gemwindow; there is a new directory src/Output for alternative output-modules. currently it only holds [gemextwin] which can be used to replace [gemwindow] to render into an externally created window (this really works: http://iem.at/~zmoelnig/GEM/plugin/ ); currently this object compiles under windows & linux but is working only under linux. multiple output-modules can be connected to a [gemcontrol]. there are still a *lot* of problems, so i guess it is not ready for testing.
...this sounds vaguely interesting, but I have no way of testing against multiple video cards (I just have a laptop)...again, what is this a branch off of? Does it seem to have conflicts with the vertex array stuff? I'm also working on changing rendering in GemMan, but my solution is not necessarily just to move it to a new object...
#--------------- 2) new directories:
apart from the Gem/src/Output directory i have also created the long awaited Gem/abstractions directory. currently it is empty (it holds a [gemwin]-replacement in the multiple_window branch) and waits to be populated
...have no idea what an /src/Output directory would be good for...abstraction, yeh! Ben's stuff should definitely be first candidate for there...
#--------------- 3) i have just created a mailinglist pd-gem-cvs@lists.sourceforge.net for email-notifications on CVS-changes (like the pd-cvs list); it will take some hours until it is online i have received email-notification on the CVS-changes for some time and probably someone else is interested too.
...are we going to be auto-subscribed like last time? I'm interested in staying abreast of commits...
...so, sorry if I sound grumpy, but this is quickly getting outta hand, like subscribing to too many mailing lists: how are we supposed to manage this? Check out multiple copies of Gem, each with it's own branch/tag/whatever?
...my goals are simple: try to bring Gem up to OpenGL 1.5 (1.3 would be a good start)...atm, unfortunately, I'm still working in the underlying drawing code for Tk on OSX...but hopefully will move on to multitexturing and other things soon...
jamie
James Tittle II wrote:
On Aug 17, 2004, at 10:08 AM, IOhannes m zmoelnig wrote:
1x) *stupidity*: while branching seems simple, i have experienced that it is a bit beyond my reach. i have done a lot of really stupid things, namely:
...this is what I'm afraid of: many different versions going out in different directions, each with some small "stupidity" mistake, making for a fool's errand to find out if it's even worthwhile...
...I'm sure we're all going to make mistakes for awhile...
absolutely. but what i can i do know ? the biggest problem with me using the CVS is, that i need it not only for sharing code with other people (e.g.: you) but also to have a code-base that i can work on from several machines under several operating systems both at work and at home. this is why i tend to check in things that are not running at all.
1a) "SIMD": i have tested it under linux and windows and it works (although i SSE2 machine at hand so i haven't tried this yet); however, i have not tried to compile it under osX yet.
...why would you try to compile it under OSX? Are you writing altivec?
no i am not writing altivec. however, the altivec functions were not named uniformly and me (in my "facist" way of thinking) have just changed this. and i have thought that each and every change to the code-base - no matter how well tested on one platform - *might* break compilation on another system.
What is it a branch of?
v0.90 (if this answers your question) for now i have branched (at least) the whole Gem/src folder.
1b) "multiple_window": (there is also a TAG with this name, so beware!)
...this sounds vaguely interesting, but I have no way of testing against multiple video cards (I just have a laptop)...again, what is this a branch off of?
again v0.90; everything is branched
the point is not necessarily about having multiple video-cards in one machine. i have neither (and if i would this won't matter to me as a] X could create one big desktop; and b] i can already do rendering to remote Xs for a while (this is: run 2 machines with X and do the Gem-output on one machine; or run 2 X servers on one machine and re-direct the rendering from the "patching" X to the other one))
while i don't think that their are similar mechanisms like X-forwarding on osX and win23 (as long as you don't run X of course), i think that spanning across multiple gfx-cards should not be an issue today. (ok, i have never actually used this...)
Does it seem to have conflicts with the vertex array no, why should it ?
stuff? I'm also working on changing rendering in GemMan, but my solution is not necessarily just to move it to a new object...
so why do i think we need multiple windows ? people keep bothering me with feature-requests like "i have a dual-head gfx-card and want to do a performance; the second head goes to the video-beam while i am controlling on the first head. unfortunately i cannot see the beam from where i am and they have no video-splitter for me to monitor what i am actually producing. wouldn't it be possible to display the "output" on a small monitoring window ?
the other thing is, that we (the iem) are currently working on a pd-plugin for webbrowsers. it is important (for whatever reasons) that Gem is included and that rendering is done to an "embedded window" (e.g. like with movie-player-plugins the rendering-window should be bound to the browser (scrollable and everything) and not pop-up "somewhere" on the desktop and vanish behind other windows as soon as i change some parameters on the plugin-GUI in the browser)
there *is* a lot of code in GemMan that is specific to the operating systems window handling, and even worse, there is code in there that depends on certain graphics-servers.
furthermore, a lot of code in GemMan is declared "static" (like the viewpoint). now *if* i want the ability to render to several independent windows, then i also want to be able to set different viewpoints for each window. or lighting, or background-color, or dimensions, or whatever...
how are we supposed to ever drive a cave with Gem otherwise.
...have no idea what an /src/Output directory would be good
on the long run i would like to remove the dependency on X from Gem. (e.g. if only output to an aa-terminal is needed). then there might be output-modules that only make sense for a special hardware. i have thought to isolate such objects and make them as externals to Gem.
...are we going to be auto-subscribed like last time? I'm interested in staying abreast of commits...
even i am able to learn. nobody will be subscribed automatically.
manage this? Check out multiple copies of Gem, each with it's own branch/tag/whatever?
hmm. supposed your local copy is up-to-date. then you could just update your whole source-tree to the tip of a certain branch; that's it. you are there. edit. commit. then update to another branch. edit. commit. then go back to HEAD. and so on. the only problem arise, when your local copies are modified and you don't want to check them in.
mfg.a.sdr IOhannes
Hi
I am on vacation right now, but I here's a quick response to the changes:
Quoting IOhannes m zmoelnig zmoelnig@iem.at:
1a) "SIMD": i have tested it under linux and windows and it works (although i am a bit disapointed of the performance-gain; unfortunately i have no SSE2 machine at hand so i haven't tried this yet); however, i have not tried to compile it under osX yet.
In my experience MMX is so poor that it's not even worth the effort. Not only is it only 64bits wide, it cannot do single cycle ops and well tuned scalar code will come close or match it with a decent compiler. SSE has C intrinsics much like Altivec which would greatly speed development and aid readibility about 1 billion percent - I know that VC++ and ICC work with them, but check GCC as well. Unless you can really tweak the hell out of the asm, it's better to use the intrinsics anyway as the compiler will do a lot of the little nicities for you. It's pretty easy to write very bad assembly.
1b) "multiple_window": (there is also a TAG with this name, so beware!) this separates the functionality of [gemwin] (which has vanished) into 2 objects [gemcontrol] and [gemwindow], where [gemcontrol] is the interface to the rendering-engine (GemMan) and [gemwindow] handles the window-management.
This is a pretty huge change, and it should be a working branch or the objects should be built as entirely separate objects. It does break every patch and version of GEM currently out there, which is a problem.
Overall, this is a good idea and the functionality is a welcome advancement, but the direction of development needs some discussion. I would suggest keeping the gemwin object and just adding some arguments to it to create multiple windows ([gemwin window1] to make a window called 'window1' or something). [gemcontrol] isn't as bad idea, but it could be potentially confusing if one object manages many windows at once.
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
chris clepper wrote:
Hi
1a) "SIMD":
In my experience MMX is so poor that it's not even worth the effort. Not only
you couldn't have told me earlier ;-) (i even guess, you did!)
code will come close or match it with a decent compiler. SSE has C intrinsics much like Altivec which would greatly speed development and aid readibility about 1 billion percent - I know that VC++ and ICC work with them, but check GCC as well. Unless you can really tweak the hell out of the asm, it's better to use the intrinsics anyway as the compiler will do a lot of the little nicities for you. It's pretty easy to write very bad assembly.
actually there are intrinsics for MMX, SSE and SSE2, supported by icc, gcc and vc7 (and vc6 if you have the "processor pack"); i really did write the code for gcc (and was surprised that it worked so well under windows then) and indeed: i don't think that i would *ever* have written any line of assembler for MMX.
1b) "multiple_window": (there is also a TAG with this name, so beware!) this separates the functionality of [gemwin] (which has vanished) into 2 objects [gemcontrol] and [gemwindow], where [gemcontrol] is the interface to the rendering-engine (GemMan) and [gemwindow] handles the window-management.
This is a pretty huge change, and it should be a working branch or the objects should be built as entirely separate objects. It does break every patch and version of GEM currently out there, which is a problem.
i thought it would be possible to stay compatible with older patches. the magic is in the abstractions folder that provides a [gemwin]-abstraction holding [gemcontrol] and [gemwindow].
Overall, this is a good idea and the functionality is a welcome advancement, but the direction of development needs some discussion. I would suggest keeping the gemwin object and just adding some arguments to it to create multiple windows ([gemwin window1] to make a window called 'window1' or something).
indeed this would have been another good idea too. the problem that i see is, that you would have a rendering-engine (the current GemMan) for each window. one of the problems arising here, is that auto-updating objects (like pix_film or particles) will have serious problems to stay "in time". the current solution in the multiple_window branch is to control the frame-rate centrally (this is: each window renders at the same rate, which might be a problem) and the use of display-lists sharing, which calls the render-object of each [object] exactly once per rendering cycle (but of course, display-list sharing might not really work everywhere).
[gemcontrol] isn't as bad idea, but it could be potentially confusing if one object manages many windows at once.
the idea is, to use pd's messaging system for controlling. imagine a patch with 3 [gemwindow] objects, 2 of which are connected to the sole [gemcontrol]. you create 3 windows by sending a "create"-message to the [gemwindow]s and turn rendering on by sending "1" to [gemcontrol]. 2 of the windows will render the scene, the 3rd (which is not connected) will stay blank.
i guess this is more like pd's concept of sources and sinks (you could compare [gemwindow] to [dac~])
all the [gemcontrol]s will control the same rendering-engine (if you turn one gemcontrol "on", you turn all of them on)
i even think it would be clearer than it used to be, as now you can have multiple [gemwin]s and send concurring messages to each of them which all take effect on the same window (e.g: multiple objects managing a single window)
the only problem that could arise is indeed, if one has multiple [gemwin]s in their patch. this will eventually produce multiple windows (which is a minor issue) but if you were using one [gemwin] to create/destroy and another one to set the fog-density this will really break the patch.
and thanks for being not grumpy ;-)
mfg.s.f.as IOhannes
Quoting IOhannes m zmoelnig zmoelnig@iem.at:
the problem that i see is, that you would have a rendering-engine (the current GemMan) for each window. one of the problems arising here, is that auto-updating objects (like pix_film or particles) will have serious problems to stay "in time". the current solution in the multiple_window branch is to control the frame-rate centrally (this is: each window renders at the same rate, which might be a problem) and the use of display-lists sharing, which calls the render-object of each [object] exactly once per rendering cycle (but of course, display-list sharing might not really work everywhere).
the idea is, to use pd's messaging system for controlling. imagine a patch with 3 [gemwindow] objects, 2 of which are connected to the sole [gemcontrol]. you create 3 windows by sending a "create"-message to the [gemwindow]s and turn rendering on by sending "1" to [gemcontrol]. 2 of the windows will render the scene, the 3rd (which is not connected) will stay blank.
This explanation makes more sense to me. I haven't gotten the code yet, but the idea of having render targets independent of individual windows is great.
What about having render targets that are not displayed directly to a window like a render to texture or pbuffer? Those possibilities should be included with the reworking of the window and control elements. Does [gemrender] make sense as a way to render to a non-window target?
Also, are their any opportunities to take display lists further? Like build a chain that is a display list and then calling the list in another chain?
Finally, the render control could use some work. We should probably take a look at where time is being spent managing the chains and if timing could have a finer resolution and more stable frequency. Oh and if we could work out some sort of thread and priority solution to keep the damn GUI from stopping rendering then that would be top.
and thanks for being not grumpy ;-)
You caught me on vacation! ;)
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
chris clepper wrote:
the idea is, to use pd's messaging system for controlling. imagine a patch with 3 [gemwindow] objects, 2 of which are connected to the sole [gemcontrol]. you create 3 windows by sending a "create"-message to the [gemwindow]s and turn rendering on by sending "1" to [gemcontrol]. 2 of the windows will render the scene, the 3rd (which is not connected) will stay blank.
This explanation makes more sense to me. I haven't gotten the code yet, but the idea of having render targets independent of individual windows is great.
actually it doesn't work this way yet: you cannot tell one gemhead to render to window-1 and the other to window-2 and yet another to all windows.
What about having render targets that are not displayed directly to a window like a render to texture or pbuffer? Those possibilities should be included with the reworking of the window and control elements. Does [gemrender] make sense as a way to render to a non-window target?
right, that was part of the idea. to have render-targets (aka "Output"s) that could be anything, on-screen (normal windows, embedded windows) and off-screen (pbuffers: output to movies, video-out, firewire,...)
my first thought was, to have integrated output-modules (this is: one object that renders to AVI, another object that renders to 1394); i am now thinking that it might be better to have one pbuffer-output-object that passes the data to the actual encoders,...
but i am not sure at all; (class inheritance is really a cool think for not doubling code)
i was thinking to put these output-modules into src/Output and build them as _externals_ to Gem, as they are likely to be highly platform and hardware specific.
Also, are their any opportunities to take display lists further? Like build a chain that is a display list and then calling the list in another chain?
you can already do this. (ok, it is a but tricky and the problem is that you cannot build the display-lists outside the rendering-chain (to ensure to have an openGL-context)
apropos openGL-context: i guess we will have to think about getting a generic way to solve the "haveValidContext"-problem. right now, win/lin do not care at all, and osx get's the information from GemMan (which will not be possible with multiple-contexts any more)
Finally, the render control could use some work. We should probably take a look at where time is being spent managing the chains and if timing could have a finer resolution and more stable frequency. Oh and if we could work out some sort of thread and priority solution to keep the damn GUI from stopping rendering then that would be top.
ah. finally make gem threaded! this will be huge work! (especially since we use pd's messaging system so much now) but it might be worth the hazzle
mfg.a.sdr IOhannes