What is the rendering potential of FastPointer?
Blitz3D Forums/Blitz3D Userlibs/What is the rendering potential of FastPointer?
| ||
| I've only just unarchived and looked at FastPointer today, having had it lying about for 3 months. I need to get up-to-speed on this. Forget the pointer aspects for the moment, I am more interested in the multi-core threading aspect. Can we transfer, for example, the FastExtension UpdateShadows to another core - or, basically, just shunt part of any of the rendering process to another core? I'd love to be able to bring in at least a second core for this. I'm just really interested in knowing how useful FastPointer is/can be for shunting to a second (or more core) to give more rendering power to Blitz3D - ie pretty much double what I already have. |
| ||
| Without thinking too much about the details of FastPointer, how much of the task can actually be parallelized? Remember you can only run tasks in parallel if one doesn't depend on the result of the other. So you couldn't dedicate one thread to updating the shadow meshes/textures and another to running RenderWorld, because the shadow system has to be set up exactly once per frame, and before that frame is rendered. Of course, if the shadow system is built up of components that don't depend on each other, you could update them separately, eg. a separate thread for each caster (can't remember the details of FastExt shadows). If you have a lot of casters/independent elements, you might see a benefit here, but you'd need some way of blocking the render thread until all the setup threads are done. The other problem is the lack of thread support. FastPointer doesn't provide any thread services beyond actually launching them; you can't lock objects or wait for something to become available, so you'd be stuck with updating very preset things in order to ensure no conflicts. The management code for blocking the render thread and only running the update threads during the shadow update routine might weigh more than just doing it in a linear fashion (creating new threads each frame would cause a lot of slowdown and still leave you needing a way to block the render thread). Short answer: maybe. Depends. |
| ||
| My initial brute force tests did not yield much fruit, which is why I posted (just in case I was doing things wrong). Looks like FastPointer is pretty much what it says on the tin. The thing that troubles me is that someone may have already found a way to balance this all out. |
| ||
| I insistently don't recommend to use RenderWorld function (-> UpdateShadows==RenderWorld) in different threads :) |
| ||
| What kind of preprocessing can be done via core2 and handed back to core1 in time for a shunt? |
| ||
| Any other calculation, but not DirectX operations (DX7 not support multithreading, virtually only). |
| ||
| I appear to be wielding a banana instead of a mighty light sabre. I must be careful, in case I slip on the discarded skin and skewer myself. |
| ||
| Its possible to use it for multi-threading performance increases in areas of rendering, physics, etc. but you need to use immense care and a good understanding of the implications of multi-threading and data sharing. Its probably possible, tho even to start with a complex challenge, to port aspects of the fastext libs to it... but I'm not sure the increases in performance would be worth the work needed to implement and test properly. By far the biggest advantage to fastpointer is the ability to use function pointers - if you look at any game source code like quake 2/3, etc. you'll understand why. |
| ||
| Sorry for bump, but is it possible to load meshes in thread when the game runs in other thread? And if, how? |
| ||
Taken directly from one of the example files:; don't load meshes in thread, if you use RenderWorld function in main loop ... now I couldn't tell you why, but that's what Mikhail says. |
| ||
| You could create your own threaded mesh loader with it* - but you won't be able to use the built in mesh loading commands due to the unpredictability of access to the data between different threads = crash when ones not ready. *Prep dummy mesh in main thread, then call the threaded loader to pull the data out of the file into memory, then manipulate the dummy mesh. Last edited 2011 |
   |