Render, Update, then flip the pancake?

Started by
25 comments, last by Etnu 19 years, 9 months ago
Wow, >= 9/10ths of my Render() time goes to flipping!!!

Also, if I flip at the end of the loop instead of in Render(), my Render() time stays the same but my Calculations() time goes up again.

Where do you presume I'm doing the wrong calculations then? You are right, the difference is bugger all, but I want to know why it changed.
"Learn as though you would never be able to master it,
hold it as though you would be in fear of losing it" - Confucius
Advertisement
Can you post some pseudo code showing how you do timing?
BTW, if your GPU time is much larger than CPU time, you aren't balanced. You could safely increase the accuracy of the physics engine, improve the AI, etc. until both timings are approximately the same.

Etnu: sorry, I still fail to see your logic. I guess the only way is to try it. If I have some extra time I'll give it a try but I'm pretty sure your reasoning is faulty here.
Hi everybody.
Present should stall the CPU if you're synchronised to the screen refresh rate, so i don't see why the update of the game logic would be parallelized if it's done after the swap buffer.
I'm developping a game for playstation 2 & XBox, and I can say the parallelism is one of the most important things to have decent performance.
Microsoft has made a tool called PIX which show how the parallelism is done, where it's break, etc...
If you have one day the luck to try it, you will learn a lot of things. It will be available soon for PC.
Don't forget to look at the paper from ATI & NVidia, they are very important, and I've never see them to advice multi-threading. It won't help you to have a better parallelism, and I don't see either why it's advantageous to draw twice the same frame.
Ron
Quote:Original post by CoffeeMug
I guess the only way is to try it. If I have some extra time I'll give it a try but I'm pretty sure your reasoning is faulty here.


Yeah, that's really the only way to answer these kind of questions. I won't be able to test it for a little while, as I'm still designing/coding some of the major parts of my engine. But I wanted to hear others' advice on the matter. I look forward to running some tests.
Quote:Original post by Anonymous Poster
Don't forget to look at the paper from ATI & NVidia, they are very important, and I've never see them to advice multi-threading. It won't help you to have a better parallelism, and I don't see either why it's advantageous to draw twice the same frame.

Yeah, I fail to see the benefit multithreading would give as well.
Quote:Original post by okonomiyaki
I look forward to running some tests.

Want to place some bets on whether multithreading will improve your performance? Fifty bucks says it won't [smile]
Quote:Original post by CoffeeMug
Want to place some bets on whether multithreading will improve your performance? Fifty bucks says it won't [smile]


Haha! Unfortunately, I tend to side with a single threaded approach. I wouldn't be willing the lose 50 bucks that easily :p But like I said, I'll never know until I play around with it myself.
Quote:Original post by CoffeeMug
Quote:Original post by Anonymous Poster
Don't forget to look at the paper from ATI & NVidia, they are very important, and I've never see them to advice multi-threading. It won't help you to have a better parallelism, and I don't see either why it's advantageous to draw twice the same frame.

Yeah, I fail to see the benefit multithreading would give as well.
Quote:Original post by okonomiyaki
I look forward to running some tests.

Want to place some bets on whether multithreading will improve your performance? Fifty bucks says it won't [smile]


I'm already seeing improvement (as my link pointed out) in performance over doing calculations between EndScene() and Present(). *shrug*.

---------------------------Hello, and Welcome to some arbitrary temporal location in the space-time continuum.

This topic is closed to new replies.

Advertisement