With paralell computing becomming more and more common isn’t it time fo openGL to be able to do paralell rendereing.
It would work the same way as “normal” openGL, but you would have several framebuffers to work with.
They would work separate of each other.
You would then have to use a function to either activate one or deactivate one.
When activated it will acpt any openGL command sent to it.
IF you activate several of them them it would mean that whatever openGL command issued by the program is sent to all active framebuffers(or whatever they will be called).
At several point’s during the rendering process you could combine or blend two or more of them together.
If the graphics card manufacturers would add hardware support for this then it would not just speed up rendering on paralell computing sytems, but it would allso alow for significant speedup’s when for instance doing multiple stencil shadowed light’s in a scene.
I actuarly mean paralell rendering as in rendering to two differen’t frame buffer’s at the same time.
By doing this you could increase the speed of the rendering process.
For instance, when rendering multiple lightscources, several light’s can be renderd at the same time as one light could.
Even if you only have one GPU on your card, it would speed up rendering as the CPU would have to work less.
Allthough it’s nothing that would be much of use today, im pretty shure paralell rendering would be pretty common in the near future.
So it would be nice to have the framework of that built in OpenGL2 so that the day hardware support’s it, the software would allready support it and be able to use it with no or little coding.
And yes, you can do stuff with the accum buffer(allthough it seams to run in software mode for me, so i never use it), but i don’t think the accum buffer contain’s a zbuffer, a stencil buffer or even it’s own accum buffer.
With paralell computing becomming more and more common isn’t it time fo openGL to be able to do paralell rendereing.
A graphics chip is about the most parallel chip you can possibly find. These things have very deeply pipelined and massively parallel computational cores. Asking for more is somewhat ludicrus.
Perhaps.
But more in this case is allway’s better.
It’s not just so that the GPU(s) will work better with paralell rendering, but allso the rest of the system could possibly run better.
Preformance issues aside, there are other advantages to having multiple framebuffer’s(and the ability to render to them at the same time).
Shaders could do a much nicer job if it can have several sources to read from.
More cool effects are made possible if you render to several framebuffer’s.
And it’s allway’s nice to have more than one stencil buffer to work with.
Originally posted by al_bob: How is this different than having multiple render contexts, or pbuffers?
You still have to render to those one by one.
But if the hardware dosn’t support it then i guess the driver could cheat a little and use something simmilar.
It doesn’t really matter if hardware support’s it or not, but i like the framework for it to be includded in OpenGL2.
not realy, that “extension extends ARB_fragment_program to allow multiple output colors, and provides a mechanism for directing those outputs to multiple color buffers”.
While that is usefull, it’s not what i meant.
But i guess that you could hack that extention a little and write a fragment program that simulate’s the stencil buffer in a color buffer and then use that in another fragment shader that calcylates all lightscources in one pass with the help of your simulated stencilbuffers and output the result to another set of colorbuffers yada yada yada…
But then again i guess you have to read all of the posts in this tread.
Originally posted by lc_overlord: not realy, that “extension extends ARB_fragment_program to allow multiple output colors, and provides a mechanism for directing those outputs to multiple color buffers”.
While that is usefull, it’s not what i meant.
But i guess that you could hack that extention a little and write a fragment program that simulate’s the stencil buffer in a color buffer and then use that in another fragment shader that calcylates all lightscources in one pass with the help of your simulated stencilbuffers and output the result to another set of colorbuffers yada yada yada…
But then again i guess you have to read all of the posts in this tread.
I did.
So you want stencil shadow volumes. These won’t work, agreed.
But then, why should they? Stencil volumes for different lights require different geometry anyway. So you’re not exactly duplicating the frame buffer, you’re duplicating the whole chip. We could do worse. We could try to duplicate everything except for the frame buffer. Synchronizing two complete rendering pipelines to write to a single framebuffer at the same time - without imploding - sure sounds like an infinite source of fun.
[This message has been edited by zeckensack (edited 02-01-2004).]
Did you want something like OpenGL Multipipe?
I believe it’s primary purpose is to display a single render stretched across a grid of monitors. For example, a 3x3 grid of screens presenting (different portions of) the same image. Each screen in this case has the corresponding 1/9 of the image.
I still think just having different instances of buffers would be convenient… it would also be neat to actually be able to pin a specific stencil buffer to a specific light.
Wait a minute, what’s all this about running the parallel system, you don’t talk about some way to send geometry to all of those at the same time to keep the AGP bus a break… You’re asking a lot.
[This message has been edited by 147-2 (edited 02-22-2004).]