Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

meeshoo

Game pipeline

This topic is 5243 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi. I''m developing an engine that uses opengl for graphics(with shaders and without them for non GPUcards) and I use DirectInput for input and DirectAudio for sound. I''ve read that the goal of a game pipeline is to make the GPU, the CPU and the sound card''s chip to run in parallel as much as possible. My question is how can I make that happen(without multithreading)? I use as a scripting language Lua and Lua 5.0 supports CO-routins, wich is a kind of multithreading(more like multitasking) and i wonder if i can use that for my pipeline or is too slow. Please help me and post any pipeline(except the serial one) that came to your heads. Mihai

Share this post


Link to post
Share on other sites
Advertisement
Thanks, they are usefull help, but I''ve forget to mention that my engine is quite 50% finished and it''s design is very robust(it''s dll based and it''s very modular, all libraries are comunicating through Lua, with some compromises in essential points).The problem is I''ve implemented a serial pipeline and that is no good, so now I want to replace it.

Share this post


Link to post
Share on other sites
Well the basic idea is that you need to do things at appropriate times. For example if you are going to render a bunch of vertices and then update their position each frame: You would fill in a vertex buffer, and set positions (this would happen on the CPU for a SYSTEMMEM Vertex buffer) now after the positions are all set, you push all the vertices out to the graphics card (Draw*Primitive*()). Then you again mess around with the objects vertices. Now while you are fixing the objects vertices the second time, the GPU is busy rendering the vertices that you sent in the last time. So therefore in this situation you have gotten your CPU and GPU working in parallel.

You''ll have to find out what commands flush the command queue on the graphics card. In DirectX Locking and Drawing vertex buffers causes a GPU command flush, and while the commands are being flushed, you can do work on the CPU (literally for free).

That''s the basic idea of how it works. Im not sure which functions cause OpenGL to flush its command Queue. I dont think I even know all teh DX functions that cause a flush.

Maybe some website will have something on flushing. After you''ve found out which functions flush. Then its just a matter of doing the right things at the same time.

| C++ Debug Kit :: GameDev Kit :: DirectX Tutorials :: 2D DX Engine | TripleBuffer Software |
| Plug-in Manager :: System Information Class :: D3D9 Hardware Enum | DevMaster :: FlipCode |

Share this post


Link to post
Share on other sites
I assume glFlush(). But i dont think that will acheive the same thing. Since in order to call it the above functions would have had to return, so you've waited for them. I guess i have no idea wut glFlush does and so i dont use it.

edit: Ok maybe i do understand, if it works like this.


When you start giving it opengl commands it dosnt actualy do anything but just add them to list, and when you call swapbuffers it executes them, glFush()? glFlush purges the list, so you would give it a bunch of complex calls, purge the list do some non graphics api call stuff, and pick back up with the graphics without waiting for it again at the end?

Im probably way off.

[edited by - honayboyz on January 14, 2004 8:02:52 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by honayboyz
When you start giving it opengl commands it dosnt actualy do anything but just add them to list, and when you call swapbuffers it executes them.

No, commands are executed straight away, the only time the pipeline is actually flushed is operations which depend on earlier operations, like swapbuffers, or reading the framebuffer.

So you always have some parallel processing going on, the trick is to maximise this. By having all your data already avalible for rendering (ie by not touching it with the CPU where possible, offloading work onto pixel and vertex shaders, and caching geometry on the graphics card) a single command can be called and return immediatly. Then while your graphics card is off rendering the big batch of polys you can be preparing the next batch, etc.

It can also help to do:
- render scene
- update logic
- display scene. repeat.

Then you get the end of your rendering overlapping with your game logic (hopefully). Its all highly app dependant though, profiling and careful tweeking is the best idea.

Share this post


Link to post
Share on other sites
Thanks a lot, I can say that this is what i''m asking for and now I can easely implement it. I guess I didn''t know what glFlush() was doing(excuse my bad English) but now I know and that''s important. I encourage the visitors of this topic to write all there ideas because they help alot. For help in optimizing piplines I recommand(I don''t now the link) www.nvidia.com, the developers section-it''s a pdf about performance and optimization. A programmer can find there all he needs for optimizing graphics pipelines(and it''s not only about nVidia cards). Another interesting site is GDC(Game Developers Conference). good luck

Mihai

Share this post


Link to post
Share on other sites
I''ve got something else which I would like to implement in my BaseCode(I can''t call it an Engine yet).

I thought of implementing something like a Windows Kernel. To allocate a peace of time to perform a peace of the rendering pipe-line. For instance, You don''t want to check the keyboard on every frame (its a waiste), rather check it like 30 times a second or something, you know to save some time to do something else.

You can have a counter which counts every frame (you can reset it to 0 after a second if you want) and if the counter is above or below a value, you can perform these actions...

I hope this could give you an idea, I havn''t thought this thorugh yet but considder it an idea.


// Last Attacker \\---=( LA )=---// LA Extreme \\

ICQ Number : 120585863

E-mail: laextr@icqmail.com

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!