• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

153 Neutral

About JarkkoL

  • Rank
  1. Oh, you misunderstood what I said. I didn't advocate design where physics code has dependencies to audio code, but that having global access to resources doesn't hide such a dependency any more than explicitly passing the resources to the code. It means that some physics programmer doesn't accidentally write dependencies to audio code because of global resources, but that he needs to also access audio API's anyway thus is well aware of making such a dependency. And you are absolutely right that such a connection between the engine sub-systems should be made at a higher level.   I think global resources have their proper uses, but you need to weigh pros vs cons to see if they are the best solution for given problem. No one is saying you should make everything global ;)
  2. While I agree with your principle in general, there are practical scenarios where global access to resources is much more pragmatic solution. When you find the need to access a resource in the depths of the code, it can be very cumbersome to change all the interfaces & functions to pass the resource all way through the necessary callstack. You may even have some very generic functions in the callstack where it makes no sense to change the interface to pass specific resources through the interfaces.   If you have need to play sound in the depths of physics code, global access to sound resources doesn't endanger modularity any more than explicitly passing the resources. In both cases you need to #include sound code in your physics code, which should be enough of a red flag.
  3. It's perfectly fine to use globals in C++, though instead of accessing them directly you should access them via functions to provide some level of encapsulation. It's just good practice to minimize the number of globals to avoid your code becoming an unmanagable spaghetti mess. For resource management, I personally use globals since passing pointers to resource repositories everywhere where needed would be much worse option.   Cheers, Jarkko
  4. Hey fellow coders, I just released new update of [url="http://sourceforge.net/projects/spinxengine"]Spin-X Platform[/url] source code (changelist [url="http://community.spinxengine.com/sxe_news_announcements/6-spin-x_engine_changes.html#post49"]description[/url]). Cheers, Jarkko [center][url="http://www.spinxplatform.com/screenshots/sxed.jpg"][img]http://www.spinxplatform.com/screenshots/sxed_thumb.jpg[/img][/url][/center] [center][i][color=#808080][size=2]Spin-X Editor Screenshot (click to enlarge)[/size][/color][/i][/center]
  5. [quote name='SteveDeFacto' timestamp='1314618023' post='4855023']How does that even make sense?...[/quote] What do you mean? I assume you know how QuickHull algorithm in 3D works. Cheers, Jarkko
  6. [quote name='SteveDeFacto' timestamp='1314615752' post='4855016'] I have to use QuickHull to create the convex mesh anyway. It's cheaper to just use the tetrahedrons that my QuickHull functions iterates over instead of reiterating over them in a second pass to compute the volume. [/quote] It's faster to calculate the volume of the convex mesh in separate pass than integrate the calculation into the QuickHull algorithm. When you calculate the volume in a separate pass you need to only iterate through polygons of the convex mesh, while when integrated into QuickHull you need to calculate much more volumes. Also a word of warning, implementing robust QuickHull is major pain in the ass because of numerical precision issues. Cheers, Jarkko
  7. That's right, which is why it's a good test case for testing the scalability and overhead of a job queue implementation. People seem to be arguing that the contention is an issue in lock-free implementations, while the test seems to demonstrate that's not the case in practice at least with those tasks sizes and core counts. IIRC, Intel has lock-free job queue implementation in TBB, which uses work stealing technique to address potential issue with contention. Cheers, Jarkko
  8. The level of CPU usage depends on how well the systems are multi-threaded more than anything, and it's difficult to believe that your queue implementation would be the reason for such a poor performance. I don't think you should optimize for queue starvation case since it's not the case that occurs during frame rendering. If it does, then the solution is to do better job parallelizing different systems, not optimizing the starvation case. The jobs that are in the queue will recursively emit more jobs and the job queue wont be empty until main thread waits for all the jobs to complete. The performance of my job queue has been excellent in the stress tests and high contention cases. There isn't really any notable overhead even when the average task size has been even as small as ~0.04ms compared to larger task sizes. I have tested this only up to 16-core systems though, so can't say how well it scales beyond that. I recently wrote a simple ray-tracer for fun and got over 4x boost on Core i7 by multi-threading it with the job queue (0.2ms average task size). Of course this is quite an analytical case but it demonstrates that the lock-free job queue implementation itself doesn't impose much of an overhead for multi-threading tasks around that size at least. Cheers, Jarkko
  9. Right, the behavior of typeid() is compiler specific when you disable RTTI (disabling RTTI isn't part of C++ standard). Regarding your original code, it looks good to me. Thanks for sharing the trick (: Cheers, Jarkko
  10. You can use typeid(T).name() without RTTI. Cheers, Jarkko
  11. [quote name='dummynull' timestamp='1312959563' post='4847059']Money. If the game project is interesting for me (jrpg f.e.), then moral satisfaction is enough. All business is based on idea to be the first one against competitors.[/quote] I can tell you right now that you wont be able to monetize a single algorithm. You should either: 1) Have your implementation as part of some graphics middleware you license to AAA developers. Anyway, you told you got no access to console devkits, and most AAA developers wont be interested if you got no console port. Not many AAA developers develop for open platforms only and saying that "porting is a breeze" will not cut it, comes across as very unprofessional and shows you got no clue. 2) Indirectly monetize the algorithm by gaining reputation and publishing well written article of your algorithm, for example by trying to get it in GPU Pro or such if it's truly something good. Then use the reputation to advertise your consulting services, use it for negotiating better salary, etc. This would probably be your best bet. Cheers, Jarkko
  12. [quote name='Antheus' timestamp='1312825000' post='4846274']Not in traditional sense. If system relies on queue to provide messages before it can do useful work it's prone to live-lock. a->b->c->a. b is waiting for a and never produces any data to c which never provides work to a so b will keep waiting.[/quote] I'm talking about having worker threads enter into the wait state when queue has no tasks in it. You can't have dead-/livelock in that case. [quote name='Antheus' timestamp='1312825000' post='4846274'] 500k per second is still a lot at around 10k per frame. Way too much synchronization. It's similar to graphic state changes. Large batches, few changes. Ideally one should aim at triple digits.[/quote] I agree that 10k tasks per frame would be a lot, but that's not the number of tasks the system enables you to execute. It's the maximum throughput of tasks of the system, when 100% of the time is spent on management of tasks which do nothing. I mentioned in an earlier post that even with 500 tasks / frame you would still spend 1ms of the frame (~6%) just on the scheduling/management, which is pretty high number. [quote name='samoth' timestamp='1312836780' post='4846366']A semaphore is the right thing to do, but it means that for every task you post, you must also release the semaphore.[/quote] In my lock-free job queue implementation I don't have to do this. Workers enter into the wait state only when job queue runs out of tasks, which never happens in practice during the frame. Just to clarify, I don't set/reset the event that workers are waiting in case of the empty queue, except when the last job is popped from the queue or the first job is pushed to the queue, so there's no per job SetEvent/ResetEvent overhead. Cheers, Jarkko
  13. [quote name='Antheus' timestamp='1312822313' post='4846249']They spin in case of contention in worst possible way.[/quote] I was referring to samoth's remark that job queue will spin when there is nothing to do. Workers don't have to spin in that case. I agree that they will spin in the case of contention of course because that's how lock-less lifo/fifo queues work, but as far as I understand using locks instead wouldn't make this any better in high contention cases. So you should rather figure out how to lower the contention if that's an issue by using job stealing for example (it hasn't been an issue when I have stress-tested the queue). Regarding having the busy-wait, when new jobs are pushed to the queue, workers are freed to execute jobs, which as far as I can tell shouldn't cause any deadlock issues. [quote name='Antheus' timestamp='1312822313' post='4846249']500k synchronization tasks (passed between threads or to workers) are abysmal.[/quote] We are talking about 500k per second not per frame, and that's the max throughput the system can process not actual jobs doing something useful. Cheers, Jarkko
  14. Lock-free queue doesn't need to spin in the case there are no jobs in the queue to process. I know exactly what you mean, but you can have the workers enter in to event wait in the case the queue runs out of jobs. That's what I did with my job queue implementation to address the issue. 500k tasks per second isn't terribly bad but is still a bit on the low side. If a game is running at 60fps and spawns 500 jobs / frame, that would mean spending 6% of the CPU time (or 1ms) in a frame just for task management. You could argue about batching more jobs together to lower the overhead, but it's not as trivial as you may think. Important thing is to try to keep the size of jobs below some time threshold (e.g. <1ms) to minimize the time wasted at the end of the frame. However, by batching jobs you increase the potential end-of-frame wait time and depending on the case it's can be very difficult to control that batches don't significantly exceed the time limit. Another thing to consider is that by spreading similar work to be executed simultaneously on multiple threads you put less pressure on shared caches. Cheers, Jarkko
  15. You don't need access to console devkits for the performance figures. For Xbox360 you can use XNA and IIRC, you can also do some development on retail PS3. There are limitations on consoles that makes it non-trivial to get good performance on them, so having your algorithm running on those platforms significantly adds to the credibility of your algorithm in the eyes of AAA developers. Screenshots & videos are an easy way for people to judge the quality of your work, so I would suggest releasing those publicly here for example. If you get good feedback then you could port it for Xbox360 & PS3 for performance figures. Since you mentioned that gamers have proved the quality, what's the game you are referring to? Cheers, Jarkko
  • Advertisement