Announcement

Collapse
No announcement yet.

NVIDIA Adds PhysX GPU Acceleration Support Under Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by curaga View Post
    G-sync is in no way "an implementation of Vesa AdaptiveSync". It cannot be, because Vesa AdaptiveSync is AMD's FreeSync - AMD pushed it to the standard. Further, if it were just an implementation of it, it would be compatible with it, which it isn't.
    You have obviously totally forgotten the history. Here are some simple facts to refresh your mind:
    - Adaptive Sync has been a part of the DP 1.3 draft for a while, even before G-Sync.
    - Nvidia wanted to provide Adaptive Sync for DP 1.2 compatible devices, and added G-Sync based on the DP 1.3 draft without the support for the whole standard.
    - AMD wanted to do the same as Nvidia, except making Vesa formalizing a DP 1.2 standard with Adaptive Sync (which is good, since it's easier to check for compatibility).

    Originally posted by erendorn View Post
    Are you a even GPU programmer? Architecture wise, GPU (both AMD and NVidia) are not meant to use flexibility (dynamic memory allocation and dynamic instruction fetching simply suck on GPGPU). While CUDA compute >= 2.0 supports some of it, you should simply refrain from using it. And as such any application that is well suited to GPGPU will perform just the same on optimized Cuda on NVidia, or optimized OpenCL on both AMD and NVidia (well, if you can put up with the 1.1 support on NVidia).
    You lack the basic knowledge of how CUDA works. CUDA currently support GPU threading, direct data communication with PCIe-devices(other GPUs, SSDs, SDI(for video), etc.), memory allocation, and much more without relying on CPU interference.

    Look here people, this proves erendorn knows nothing of GPU programming at all:
    Originally posted by erendorn View Post
    You can of course use OpenCL with Fortran, as there are Fortran bindings.. The kernel though are still written in OpenCL. Unless you have a SPIR compiler, except the "more flexible NVidia GPUs" don't implement SPIR :/
    I'm not talking about language bindings for an API, OpenCL and OpenGL are available to a huge amount of languages. I'm talking of the GPU kernel code, the code compiled to be executed inside the GPU. Using Cuda/Fortran you as a programmer can seamlessly work with Fortran code on the CPU and the GPU. That's the basic idea behind CUDA, you code almost as if the CPU and GPU were one processor. Porting code to CUDA can be easy, sometimes you just move a function or perhaps even a loop into a CUDA kernel:

    Comment


    • #42
      Originally posted by efikkan View Post
      Look here people, this proves erendorn knows nothing of GPU programming at all:
      I'm not talking about language bindings for an API, OpenCL and OpenGL are available to a huge amount of languages. I'm talking of the GPU kernel code, the code compiled to be executed inside the GPU. Using Cuda/Fortran you as a programmer can seamlessly work with Fortran code on the CPU and the GPU. That's the basic idea behind CUDA, you code almost as if the CPU and GPU were one processor. Porting code to CUDA can be easy, sometimes you just move a function or perhaps even a loop into a CUDA kernel:
      Seriously, how is the kernel code shown here any different than the very same kernel written in OpenCL? Yes, in CUDA you can write the kernel in the host source code, and the compiler separates them, it's cool stuff. But you were talking about the programming capabilities of the hardware (quoting you), how does that help here?

      Comment


      • #43
        Originally posted by erendorn View Post
        Seriously, how is the kernel code shown here any different than the very same kernel written in OpenCL? Yes, in CUDA you can write the kernel in the host source code, and the compiler separates them, it's cool stuff. But you were talking about the programming capabilities of the hardware (quoting you), how does that help here?
        If you'd paid some attention, you would realize by now that CUDA's programming capabilities greatly surpasses those of OpenCL, which enables more complex operations in the GPU code. This also means the conversion of code to CUDA enforces less restrictions, and sometimes the code can be transfered directly (like in the example shown above). I don't get why you even mix in the talk about writing the kernel in "the host source code", it does not matter where the code is actually stored, it might be a separate file, in-line strings or separate sections. This even goes for OpenCL and OpenGL. You simply don't get the point at all. With CUDA you can write a normal program in C, C++, Fortran, etc. designed to run on the CPU, and then you can take parts of that code to be executed on the GPU with minimal effort, and almost makes the GPU acceleration "transparent" to the programmer.

        Comment


        • #44
          Originally posted by efikkan View Post
          If you'd paid some attention, you would realize by now that CUDA's programming capabilities greatly surpasses those of OpenCL, which enables more complex operations in the GPU code. This also means the conversion of code to CUDA enforces less restrictions, and sometimes the code can be transfered directly (like in the example shown above). I don't get why you even mix in the talk about writing the kernel in "the host source code", it does not matter where the code is actually stored, it might be a separate file, in-line strings or separate sections. This even goes for OpenCL and OpenGL. You simply don't get the point at all. With CUDA you can write a normal program in C, C++, Fortran, etc. designed to run on the CPU, and then you can take parts of that code to be executed on the GPU with minimal effort, and almost makes the GPU acceleration "transparent" to the programmer.
          Lol at "normal program in C, C++, Fortran".
          You don't have function pointers, recursions, virtual classes, there are restrictions on pointers, etc... Which is absolutely expected for a GPU architecture, nothing wrong with that. But that's very, very far from a "normal program".
          And I'm only taking about the latest compute capabilities. The real fun start when you want to target different, slightly older NVidia GPUs. I've already addressed the fact that writing programs for CPU and GPU is anyway not a problem of syntax, but of architecture, which is very seldom "transparent".

          What is more advanced in CUDA is the SDK and tools, no doubt about it. Compiling from normal (actually a subset, of course) C, C++, Fortran to SPIR 2.0 is completely possible, but indeed, there's no compiler doing it right now. Still not a restriction of the GPUs.

          Comment


          • #45
            Now Nvidia needs to add their new high-res rendering mode to the Linux drivers, since Windows now offers it for every Fermi-Maxwell GPU with the Nvidia drivers.

            Comment


            • #46
              Originally posted by _SXX_ View Post
              Hard to say Havok isn't biased because it's Intel IP (acquired in end of 2007).
              They demonstrated OpenCL pipeline back in 2009 for AMD GPUs, but it's never seen daylight.
              I've not really seen many projects using OpenCL that impress me? What do you believe is the better of the three?

              Originally posted by GT220 View Post
              http://www.youtube.com/watch?v=ktVmLJ5i4NY

              PhysX is awesome, especially the upcoming FLEX. Clueless people here don't know crap as usual.
              That is amazing. Flex looks to be a standard soon.

              Comment


              • #47
                Originally posted by Master5000 View Post
                So when was physyx avalable for windows? So we can calculate how many years behind linux is.
                Hey turd! How about multiple workspaces available since forever on Linux? Go calculate something!

                Comment


                • #48
                  Originally posted by b15hop View Post
                  I've not really seen many projects using OpenCL that impress me? What do you believe is the better of the three?



                  That is amazing. Flex looks to be a standard soon.
                  Looks cool. When will it run on systems without Nvidia hardware? Just so we know when we should start caring.

                  My experience so far with Physx is cluttering up games with trash, weird cloths and nice particle effects. Still waiting on gameplay based on Physx the way HL2 started to do in 2004. This was of course physics that run on any platform so was widely used.

                  Comment


                  • #49
                    How to install these drivers?

                    Comment

                    Working...
                    X