AI Driver separate thread?

[reece146]

I tried out the AI driver setup tonight.

Pretty cool! But, it eats my machine (2 x 2.0GHz G5) in places, even with only one AI driver. I guess the VAMOS engine is quite intensive.

I was wondering if there would be any merit in making each AI driver a separate thread? I understand that vdrift is a single treaded program, but if the AI was a second thread it might stand a chance of getting stuck on the second CPU?

JAT

[rookie1]

The AI computation is nothing intensive. I'm getting acceptable frame rate with a 3-year old AthlonXP (overclocked at 2GHz) and Ti4200. Could your problem be Mac specific? Is G5 slower compared to AthlonXP for the same clock speed?

[reece146]

The AI computation is nothing intensive. I'm getting acceptable frame rate with a 3-year old AthlonXP (overclocked at 2GHz) and Ti4200. Could your problem be Mac specific? Is G5 slower compared to AthlonXP for the same clock speed?

I dunno... I don't think so... Probably within "pissing distance" of once another for compute power.

I'm wondering if this is more video related now that you say you are running fine. I should let the other car get ahead of me and out of sight and see if the frame rate is still in the basement.

[thelusiv]

Yeah I'd say your problem is more likely a graphics one than a CPU power one. What kind of video card do you have?

[reece146]

Yeah I'd say your problem is more likely a graphics one than a CPU power one. What kind of video card do you have?

ATI 9800 Pro (AGP 8X)...

Been watching ebay for a Mac specific ATI X800 but at ~$300 I was going to try to defer that for a while.

[thelusiv]

Well which track are you using and what are you running in the background? I have about the same system as rookie1. Athlon XP 2600+ overclocked a little, Nvidia TI4200. On Jarama with a robot I get decent framerates ( > 20 fps) all the way around, however on Kyalami with a robot things get sorta slow on the long straights when many objects are visible (but speed up in more enclosed areas of the track). Also what resolution do you play at, and what other display settings are you using? If you like just post the display section of your VDrift.config in a code block.

Also, while VDrift could be adapted to use multiple threads, I've done threaded programming before and there are several problems. For one, VDrift has a lot of shared resources that would be a problem to use properly while protecting them from race conditions. This would cause a lot of problems and would not be trivial to fix. Second, only a few developers have access to multiple CPU machines to test this with. Third, the locking mechanisms necessary to prevent abuse of shared resources would hurt performance much more than the gain provided by the second thread running on another CPU.

[joevenzon]

I agree, multi-threaded stuff is difficult to get working well for games... that's why even the big fancy games are still single threaded, for the most part. The AI isn't intensive at all, as reece said... the slow-down is likely due to the fact that two cars must be rendered and have physics computed. I doubt it's the vamos engine causing the slow-down... it's fairly complex, but the culprit is probably my collision detection code. It's about as optimized as it will get without major changes, so maybe this is another reason to go with ODE for collision detection.

[Nigo]

I agree, multi-threaded stuff is difficult to get working well for games

couldn't agree more...
oftently people want to use several threads when they don't know how to implement basics timely behaviors...
threads mean synchronisation, and synchronisation means programming headaches, system requests and waiting... as a result the whole thing is getting exponentially slower by the size of the project there is a reason why the best libraries are not thread safe... avoid multi-thread programming as much as you can unless you REALLY know what you're doing