Home
News
rFactor 2
rFactor 1
Forums
Contact
Company
Technology
Image Space Inc. YouTube rFactor 2 Twitter Image Space Inc. Google Plus rFactor 2 Facebook
Mediafire
Try or Buy rFactor 2
$43.99/84.99 Windows Only PCDL
Download rFactor 2 Demo Now!

NOTICE Notice: This is an old thread and information may be out of date. The last post was 1008 days ago. Please consider making a new thread.
Results 1 to 17 of 17

  Click here to go to the first staff post in this thread.   Thread: How about using GPU for physics calcs?

  1. #1
    gniewko's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    Oct 2010
    Location
    Poznań, Poland

    How about using GPU for physics calcs?

    I am really sorry if someone has started similar topic, but yeah, what about using GPU for physics calculations?
    vracingDisplay http://display.vracing.pl - connect your Android to rFactor

  2. #2
    andrerezende's Avatar
     

    Newer Member
    Jan 2012
    Location
    Brazil - Rio de Janeiro
    Time to the ATI owners start to cry!!!!!

  3. #3
    GregP's Avatar
     

    Newer Member
    Dec 2011
    Location
    Washington, DC
    Quote Originally Posted by andrerezende View Post
    Time to the ATI owners start to cry!!!!!
    Not necessarily. It is possible to add an Nvidia card to an ATI system in order to have PhysX calculations done on the Nvidia card alone:

    http://www.ngohq.com/graphic-cards/1...3-v1-05ff.html
    http://www.tomshardware.com/reviews/...deon,2764.html

    I'm currently doing this with a GeForce GT240 in addition to my 2x6970 Crossfire, and it works great. Of course, this only helps if the game is using PhysX, which I don't think is true for rF2.
    i5-2500K @ 4.8 GHz / Asus P8P67 Pro / 8GB DDR3-1600 / 2x Radeon 6970 2GB / Audigy X-Fi / Windows 7 Pro 64-bit / TrackIR5 / Fanatec CSR Elite Wheel & Clubsport Pedals / Three 27" LCDs in Eyefinity

  4. #4
    Arthur.Hermont's Avatar

     PC Specification 

    Newer Member
    Oct 2010
    OpenCL anyone?

  5. #5
    Nibo's Avatar

     rFactor 2 Not Validated PC Specification 

    Registered
    Oct 2010
    Of course, the only acceptable option would be OpenCL. But I think there may be simply not enough data that needs parallel computing for efficient use of OpenCL (CUDA, etc). Its not like we need to simulate thousands of cars in parallel, we drive only one.

    Upd. I do not know much about vehicle physics engines, so I may be mistaken about data.

  6. #6
    gniewko's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    Oct 2010
    Location
    Poznań, Poland
    yes, OpenCL was on my mind actually, can someone of ISI tell us if they were thinking of this?

    @Nibo - I was rather thinking of calculating the track surface changes as it changes now because of the weather and implying this into tyres, could help I guess, as I think a lot of CPU power is now focused on this topic, may be wrong however. Also I know the track surface changes per polygon, so giving more polygons gives more accurate approximations.
    Last edited by gniewko; 01-18-12 at 11:11 AM.
    vracingDisplay http://display.vracing.pl - connect your Android to rFactor

  7. #7
    jubuttib's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    Dec 2011
    As long as I don't even get a single core to reach 100% usage (currently hovering around 60% max) there's no real benefit from this.

    But GPU computing is something I'd like to see more off in the future, it's great for physics calculations.

  8. #8
    andrerezende's Avatar
     

    Newer Member
    Jan 2012
    Location
    Brazil - Rio de Janeiro
    I worked in OpenCL and CUDA programming on my Masterīs Thesis. This programming model must work (in a simplified way) in small nearby segments of memory to be as fast as possible (otherwise it would be slower than CPU). Also, Iīm not a mechanical engineer, but, I canīt see many dificulties to segment a car physical model on GPU.

  9. #9
    grumete's Avatar

     PC Specification 

    Newer Member
    Dec 2011
    Location
    BCN, Spain
    Is incomprensible they are doing in Dx9 When today the standard es DX11. And Grafics Cards whit Dx11 can't move this game. Is a big mistake of programming.
    Always whithout Helps

  10. #10
    thuGG's Avatar

     PC Specification 

    Registered
    Oct 2010
    Location
    Poland, Warsaw
    Quote Originally Posted by grumete View Post
    Is incomprensible they are doing in Dx9 When today the standard es DX11. And Grafics Cards whit Dx11 can't move this game. Is a big mistake of programming.
    Actually you sound like you know nothing about programming.

  11. #11
    Arthur.Hermont's Avatar

     PC Specification 

    Newer Member
    Oct 2010
    Quote Originally Posted by Nibo View Post
    Of course, the only acceptable option would be OpenCL. But I think there may be simply not enough data that needs parallel computing for efficient use of OpenCL (CUDA, etc). Its not like we need to simulate thousands of cars in parallel, we drive only one.

    Upd. I do not know much about vehicle physics engines, so I may be mistaken about data.
    My guess is that vehicle physics is as hard as it gets. Tire, aerodynamic, fluid dynamic, weather, surface, suspension, and so on. Today they can put N variables into it to keep it in real time, maybe with OpenCL they could squeeze a couple of extra N's in there and jump to another level.

  12. #12
    K Szczech's Avatar
     

    Registered
    Oct 2010
    Location
    Poland
    Using GPU for physics has been mentioned before. I have explained why it would be of little benefit for car simulation there.

    Many games use PhysX for large number of objects interacting with each other. For stuff like destruction, etc. In car simulation there is also force feedback on steering wheel, which can be controlled only by CPU and must be kept up to date with what's going on in physics.
    Constant communication betweeen CPU and GPU would require synchronization between them causing one to wait for another and vice versa. That would result in code running probably slower than the same thing running purely on CPU. Additionally, while GPU is busy rendering graphics, physics would be on hold.
    That's ok with games like Crysis, you can spend some time on physics, then on rendering, and so on. In car simulation you need physics to run truly in realtime if you're serious about what you do.


    As for DX11 - if programmers are not able to squeeze photorealistic graphics from DX9, then neither they would be able to do that with DX11. It's not DirectX version that determines performance and visual appearance of game. It's rendering techniques and optimizations that programmers have implemented.

    I remember first presentation of Unreal Engine 3 - it was back in 2006 and it ran on GeForce 6800 using DirectX 9. I've seen DX10 and DX11 games that didn't look as good as UE3 running on DX9.
    Yes, DX11 has it's advantages, but it does not determine how game looks like.
    SRPL Shader Pack v0.92 is now available for modders: announcements / discussion
    "Be kind whenever possible. It's always possible." - Dalai Lama

  13. #13
    gniewko's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    Oct 2010
    Location
    Poznań, Poland
    K Szczech, you are totally wrong. I think you don't quite get what OpenCL is. http://s08.idav.ucdavis.edu/munshi-opencl.pdf
    vracingDisplay http://display.vracing.pl - connect your Android to rFactor

  14.   This is the last staff post in this thread.   #14
    Terence Groening's Avatar ISI Staff
     

    Location
    Ann Arbor
    Last time I considered this subject, some of my random thoughts were as follows:

    1) In a racing simulation, the physics (at least for your own car) should be identical to everyone else's, otherwise the racing isn't "fair". It follows that the minimum-spec machine must be able to run the exact same physics as your latest and greatest 8-core machine, which means the latter is going to get under-utilized for *physics* purposes. (Yeah, we've discussed the possibility of there being a higher-fidelity model that can only be run by faster machines, with servers only allowing you to race against people using the same-fidelity physics, but we don't need that splintering effect right now).

    2) Our physics is run in double-precision. While OpenCL and the other libraries now (at least unofficially) support double-precision, I don't think all the older video cards do. This goes back to thought #1 ... if we can't improve the performance on the low-end machines, there's no point in doing it.

    3) But if we did, I would undoubtedly prefer writing to a standard that can be used on any video card, not nVidia or ATI-specific.

  15. #15
    jubuttib's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    Dec 2011
    Quote Originally Posted by Arthur.Hermont View Post
    My guess is that vehicle physics is as hard as it gets. Tire, aerodynamic, fluid dynamic, weather, surface, suspension, and so on. Today they can put N variables into it to keep it in real time, maybe with OpenCL they could squeeze a couple of extra N's in there and jump to another level.
    You are absolutely right. A great video here: http://channel9.msdn.com/Blogs/Charl...tion-Explained

    Physicist Brian Beckman, who works for MS and helped with the tyre physics in Forza 4. I like the part where he says that three wheels would still be OK, it would simplify a lot of things, but the fourth wheel is just too much. =)

  16. #16
    jubuttib's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    Dec 2011
    Quote Originally Posted by Terence Groening View Post
    Last time I considered this subject, some of my random thoughts were as follows:

    1) In a racing simulation, the physics (at least for your own car) should be identical to everyone else's, otherwise the racing isn't "fair". It follows that the minimum-spec machine must be able to run the exact same physics as your latest and greatest 8-core machine, which means the latter is going to get under-utilized for *physics* purposes. (Yeah, we've discussed the possibility of there being a higher-fidelity model that can only be run by faster machines, with servers only allowing you to race against people using the same-fidelity physics, but we don't need that splintering effect right now).

    2) Our physics is run in double-precision. While OpenCL and the other libraries now (at least unofficially) support double-precision, I don't think all the older video cards do. This goes back to thought #1 ... if we can't improve the performance on the low-end machines, there's no point in doing it.

    3) But if we did, I would undoubtedly prefer writing to a standard that can be used on any video card, not nVidia or ATI-specific.
    1)I do have to say that I'd love to be able to have GPU accelerated higher fidelity physics model if such a thing is indeed possible, and would hope it would be mod specific (meaning a mod built for it could only use it, so everyone with that mod had the same physics. Not everyone can run all the mods anyway due to performance reasons, so it seems like a semi-fair solution to that). Any physics improvements are definitely welcome.

    3) So OpenCL or DirectCompute it is, neither is nVidia or AMD specific. =)

  17. #17
    K Szczech's Avatar
     

    Registered
    Oct 2010
    Location
    Poland
    Quote Originally Posted by gniewko View Post
    K Szczech, you are totally wrong. I think you don't quite get what OpenCL is.
    Actually, I knew about OpenCL before even specs got released I've been progamming shaders since 2006 so I've learnt a bit about GPU architecture and driver behavior.

    I think you didn't give this subject enough thought. There is API like OpenCL, but there is also underlying architecture that actually runs the damn thing Sometimes it's easy to forget that and think that there is some "magic" parallelism just because something runs on Direct 3D and the other thing runs on OpenCL.

    Keep in mind that in our case GPU is very busy rendering - there is no quarantee that you will be given GPU time for computations exactly when you demand it.
    Typical approach is to do rendering and physics in turns, therefore updating physics only as often as picture gets updated - it's enough for many games, but not enough for us. In case of rFactor 2 physics must run in "realtime" just for the sake of FFB (if not for more reasons).
    GPU is just one resource, with multiple cores, yes, but still controlled by one graphics driver that may or may not schedule things - you never know what will be the response to issuing OpenCL command - will it be immediate or will it be delayed if GPU is currently busy rendering something.

    If physics can wait until rendering is done, and then get updated, then fine - you can do it on GPU. This is suitable for making physics of environment around player. It's a different case when you want to do physics of player himself and additionaly produce realtime FFB response or keep multiplayer lag as low as possible.
    OpenCL and other math libraries do not guarantee such low latency, even though they offer general performance.
    SRPL Shader Pack v0.92 is now available for modders: announcements / discussion
    "Be kind whenever possible. It's always possible." - Dalai Lama

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •