Pandora Advantages In Parallel Threading On Pandora?

[TrevorBradley]

While discussing my game with a programming buddy of mine a while back, he suggested placing the code to blit my game surface to the screen in a different thread. Presently it's taking me several milliseconds to blit my screen, and I'm trying to eek out all the performance I can get.

Pandora has a single core and logically I can't see an advantage in doing this. But my intuition is telling me that it's possible I might see a bit of performance increase, and I'm not sure which is right.

Is there any advantage in threading off frame blitting from the rest of the program (to blit the frame while the program continues to figure out what the next frame is in parallel), when there's only a single core to run code on?

Thanks in advance!

 

[sindbad]

Threading may be useful for blocking input/output, but it shouldn't bring anything other than a bit of overhead and a lot of programming headaches to the table.

 

[benjymous]

While discussing my game with a programming buddy of mine a while back, he suggested placing the code to blit my game surface to the screen in a different thread. Presently it's taking me several milliseconds to blit my screen, and I'm trying to eek out all the performance I can get.

Pandora has a single core and logically I can't see an advantage in doing this. But my intuition is telling me that it's possible I might see a bit of performance increase, and I'm not sure which is right.

Is there any advantage in threading off frame blitting from the rest of the program (to blit the frame while the program continues to figure out what the next frame is in parallel), when there's only a single core to run code on?

Thanks in advance!

Well, in theory, if your drawing code is all handled by the GPU then it would make sense to use the CPU to calculate the next frame (otherwise the CPU would just be stalled waiting for the GPU to finish)

If you're doing everything with SDL surfaces, it's likely to be heavily CPU bound anyway, so you probably wouldn't see much benefit.

If you're looking into optimisations, you're probably better off trying to get your head around the Intrinsics supported by the Arm processor

 

[senquack]

A few milliseconds to blit a screen is nothing, I think you're looking in the wrong spot. Where are your cycles *really* being spent?

 

[lulzfish]

If you're using SDL and software rendering, you will not see a lot of increase in performance.
If you're using OpenGL and hardware rendering, It might be more noticeable, since OpenGL programs basically sit idle while the OpenGL calls wait for the GPU to finish.

Since you're going to be rendering every frame sequentuially anyway, it won't give you a real speedup in rendering, but it will reduce the total frame time by allowing some of your physics and input code to run while you're rendering things in the background.

 

[darkblu]

While discussing my game with a programming buddy of mine a while back, he suggested placing the code to blit my game surface to the screen in a different thread. Presently it's taking me several milliseconds to blit my screen, and I'm trying to eek out all the performance I can get.

Pandora has a single core and logically I can't see an advantage in doing this. But my intuition is telling me that it's possible I might see a bit of performance increase, and I'm not sure which is right.

theading won't help you here. employing the neon unit, though, together with the int pipelines of the cpu, might speed up a blit.

 

[MilanC]

I don't know much about programming, but I guess the only use of threading here would be for portability: for Pandora, second thread running on DSP (there might be quite a lot of latency though); for GP2X, second thread on second core. However, I'm not sure you need a proper new thread for that.

 

[ldesnogu]

To expand on what sindbad and lulzfish said, if you have parts of your program that can dump data to some "slow" hardware component that can run asynchronously and you don't need to wait for the result, then multithreading could bring some benefit.
For instance :

- hardware blitting
- hardware OpenGL
- DSP

The idea is that you spawn these HW related tasks, forget about them and let the HW complete them. Of course that will make your program more complex, as you will need to synchronize

BTW you should not bother optimizing your program on your PC, in particular for features that are HW dependent such as SDL blitting, these will surely be very different on Pandora. OTOH multithreading your program on your PC might be a good idea (as long as you separate things that would make sense on Pandora).

 

[Rockthesmurf]

Just to let you know what I do (but hey, what do I know?):

- Double buffered 'render stream' which is basically a block of memory that all dynamic render data for that frame gets built up, and also links to static render data.
- During frame : Build up all data to render in to current render stream
- At frame end : Wait for previous frames draw to finish, then walk through render stream dispatching draw calls. Don't wait for draw to finish... simply start building up the next frames draw data.
- Repeat.

From my experience, this works pretty well, the only time you wait for draw to finish is literally when the next frames data is ready to start drawing, so you really do have to wait then (unless you triple buffer instead of double buffer). Once that wait is done you immediately issue next frames draw command and then do your processing as per usual. Getting the order wrong for drawing, waiting for vsync, processing is very easy to do and can really slow things down.

Just thought I'd mention it, *just* in case.

Steve

 

[darkblu]

Just to let you know what I do (but hey, what do I know?):

- Double buffered 'render stream' which is basically a block of memory that all dynamic render data for that frame gets built up, and also links to static render data.
- During frame : Build up all data to render in to current render stream
- At frame end : Wait for previous frames draw to finish, then walk through render stream dispatching draw calls. Don't wait for draw to finish... simply start building up the next frames draw data.
- Repeat.

From my experience, this works pretty well, the only time you wait for draw to finish is literally when the next frames data is ready to start drawing, so you really do have to wait then (unless you triple buffer instead of double buffer). Once that wait is done you immediately issue next frames draw command and then do your processing as per usual. Getting the order wrong for drawing, waiting for vsync, processing is very easy to do and can really slow things down.

Just thought I'd mention it, *just* in case.

Steve

Steve, what you describe is pretty much how modern 3D hw-targeting engines work. as far as i can understand, though, OP's question was about an unaccelerated blit operation, on a software pipe.

 

[TrevorBradley]

Just to get back to this..

I know it's unwise to optimize against Windows or Linux if I'm planning on releasing for Pandora, but I'm also planning to release for Windows and Linux... I've got to start some level of optimization now or otherwise I'll be waiting until June to get this thing released...

After a bit of investigation, that SDL_Surface blit call time can vary quite a lot on different machines. I'm testing on an Asus EEE 901 (the closest thing I have to a Pandora) and getting atrocious times with the blit call for a 800x480 screen... on the order of 50ms. Other faster machines with better graphics cards get 5ms. But that's an Asus EEE+SDL issue and not a general Linux issue.

Anyways I'm going to hold off on attempting to optimize by threading for now... I just threaded my network code and the little details of getting everything to work well is enough to make your eyes bleed.

EDIT: Just verified with the folks on #gamedev that the EEE has no hardware OpenGL support at all... making all render times crap.

 

[lulzfish]

How does the eee have no hardware OpenGL support?
That's like the dumbest thing since my friend's laptop didn't have it either.

Anyway, yeah, SDL is mostly a software library. It's good for input, simple graphics, and getting an OpenGL context, but its actual realtime graphics abilities are horrible unless you're using SDL_opengl or just OpenGL on top of SDL.

 

[ldesnogu]

EDIT: Just verified with the folks on #gamedev that the EEE has no hardware OpenGL support at all... making all render times crap.

Huh? The EEE 901 is using 945G for its graphics and this has HW OpenGL support for Linux (ref).

 

[Rockthesmurf]

Just to let you know what I do (but hey, what do I know?):

- Double buffered 'render stream' which is basically a block of memory that all dynamic render data for that frame gets built up, and also links to static render data.
- During frame : Build up all data to render in to current render stream
- At frame end : Wait for previous frames draw to finish, then walk through render stream dispatching draw calls. Don't wait for draw to finish... simply start building up the next frames draw data.
- Repeat.

From my experience, this works pretty well, the only time you wait for draw to finish is literally when the next frames data is ready to start drawing, so you really do have to wait then (unless you triple buffer instead of double buffer). Once that wait is done you immediately issue next frames draw command and then do your processing as per usual. Getting the order wrong for drawing, waiting for vsync, processing is very easy to do and can really slow things down.

Just thought I'd mention it, *just* in case.

Steve

Steve, what you describe is pretty much how modern 3D hw-targeting engines work. as far as i can understand, though, OP's question was about an unaccelerated blit operation, on a software pipe.


Oh right - well if it's a pure software blit then presumably it's done purely on the CPU so threading wouldn't really help as the CPU will already be held up doing the blit... I guess...

Steve