Announcement

Collapse
No announcement yet.

NVIDIA Publicly Releases Its OpenCL Linux Drivers

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

  • #31
    Originally posted by nanonyme View Post
    Yeah and he claimed encoding process doesn't use such stuff that would be useful to offload to GPU. It is possible that the situation between encoding and decoding is asymmetric and they don't benefit of the same kind of system resources equally but as I said, to find out whether that's true or not needs going more in-depth than you two seem willing to go.
    Sigh...

    You don't qualify what you mean by "in-depth" but keep in mind this topic is suitable for PhD-level research. There are not many people out there who have the necessary background and would attempt to implement a GPU-accelerated transcoder for free.

    This also happens to be an area of active research. For anyone interested:
    1. Motion estimation for H.264/AVC on multiple GPUs using NVIDIA CUDA
    2. Intra Frame Encoding Using Programmable Graphics Hardware
    3. H.264 Video Encoding Algorithm on Cell Broadband Engine

    Comment


    • #32
      Apologies if this doesn't make sense, but I've not read that deeply into how OpenCL works within the system as a whole: with an nivida beta library, and the amd cpu library, can those two work together? (i.e sending off code to the cpu or gpu as appropriate)

      Comment


      • #33
        Originally posted by mirv View Post
        Apologies if this doesn't make sense, but I've not read that deeply into how OpenCL works within the system as a whole: with an nivida beta library, and the amd cpu library, can those two work together? (i.e sending off code to the cpu or gpu as appropriate)
        Ehm... OpenCL is a specification just like OpenGL and you can have multiple implementations. That is it. The implementations can differ hugely between implementations. The only requirements is that OpenCL code can be compiled and executed according to the spec.

        What it comes down to is: you as a developper write an OpenCL app. Your code never has to change because it's not platform dependant. You can compile it with gcc under Linux and you need the OpenCL state tracker for Gallium3D or the latest nVidia binary driver to run it. As for the library I do not know. I don't think you need to compile it against both the AMD and the nVidia lib, but perhaps somebody else here can awnser this.

        As for the rest; you either asked the wrong question or my head just explodes, which always happens with OpenCL and Gallium3D topics :')

        Comment


        • #34
          Originally posted by V!NCENT View Post
          Ehm... OpenCL is a specification just like OpenGL and you can have multiple implementations. That is it. The implementations can differ hugely between implementations. The only requirements is that OpenCL code can be compiled and executed according to the spec.
          We might quickly bump into the good old territory there too as what happened with C library implementations: the specification left tons of gaps and when vendors implemented these as they saw fit, we were left with libc implementations that aren't fully compatible with each other. (and that's just before some smart-asses thought it's a good idea to start extending them way beyond specifications)

          Comment


          • #35
            Originally posted by nanonyme View Post
            We might quickly bump into the good old territory there too as what happened with C library implementations: the specification left tons of gaps and when vendors implemented these as they saw fit, we were left with libc implementations that aren't fully compatible with each other. (and that's just before some smart-asses thought it's a good idea to start extending them way beyond specifications)
            Wow that sounds awesome... And just to think that OpenCL already allows extensions. That's what the LLVM is for when JIT compiling right? It looks for extensions that are available and sends kernel code to whatever extension it can find, else it executes it without extension, right?

            Comment


            • #36
              Ah ok, I wasn't sure if the drivers were attached to more system "pass it off to whatever's free" or simply standalone. I do find OpenCL interesting, but haven't had an opportunity to work with it.

              Comment


              • #37
                Today I wrote a test profile for the ati-stream-sdk. Afterwards I installed nvidia drivers and voila many of the ati examples run fine with nvidias libOpenGL.so.

                Here are a few results:
                http://global.phoronix-test-suite.co...15-22137-12990

                I ran all tests with standard parameters and I think the overhead caused by memory transfers and initialization causes some of the low gfx results.

                Here are results for one test with different matrix sizes.

                http://global.phoronix-test-suite.co...5145-2893-4183

                Comment


                • #38
                  Originally posted by V!NCENT View Post
                  Wow that sounds awesome... And just to think that OpenCL already allows extensions. That's what the LLVM is for when JIT compiling right? It looks for extensions that are available and sends kernel code to whatever extension it can find, else it executes it without extension, right?
                  As long as usage of extensions isn't required and the program doesn't see they're used, it doesn't matter that much. On the other paw, if an OpenCL program gets the ability to directly use OpenCL extensions which might have multiple different implementations and possibly bad (read: leave a lot for vendor interpretation) specifications, we end up in trouble.

                  Comment


                  • #39
                    Originally posted by justapost View Post
                    I ran all tests with standard parameters and I think the overhead caused by memory transfers and initialization causes some of the low gfx results.
                    It's worth watching this video tutorial on nVidia hardware:
                    http://www.macresearch.org/opencl_episode4

                    Comment


                    • #40
                      Originally posted by V!NCENT View Post
                      It's worth watching this video tutorial on nVidia hardware:
                      http://www.macresearch.org/opencl_episode4
                      PS: It's a .m4v file and 124MB, so you might want to use VLC for playback because you can also stream the link so you can instantly watch it.

                      Comment


                      • #41
                        Originally posted by BlackStar View Post
                        Unfortunately, you'd need an OpenCL-capable GPU for this - and OpenCL-capable GPUs tend to have dedicated (and faster!) video decoding blocks already. Given the shared buffers between OpenCL/OpenGL, this would probably be a viable approach for video decoding on Gallium drivers (unless there are plans to add a dedicated video decoding API/tracker - no idea).

                        Now, OpenCL-based encoding and we are talking.
                        I'm going to have to disagree with you here- the folks behind x264 (the lead programmers, plus one of the major company supporters) aren't going to be doing anything with it, because it actually doesn't work as well for video encoding as the hype would make you believe.

                        Comment


                        • #42
                          Strange thing is, I'm highly considering to buy an ATi graphics card just because it's the first dx11 card out there.. Even though using such a card in linux is not viable at this stage and maybe not for the next year or so.. =/

                          Personally, I'm thinking OpenCL is revolutionary. I bet in the next 4 years there will be some really cool stuff out there that takes advantage of this powerful tool. =)

                          Comment


                          • #43
                            Oy vey.

                            Basically, CPUs are general-purpose processors, and GPUs are special-purpose processors (again, _basically_!). The GPU can do some things at a speed that destroys any CPU at that price point, including a couple handy things for decoding video. However, the world's most awesome GPU API and encoder still won't make a GPU faster than a CPU for a task it's not designed for, unless your GPU is way more powerful than the CPU -- or they start making the GPU more general-purpose, which defeats the purpose of the GPU in the first place. And no, OpenCL will not help budget buyers -- their GPU is their CPU anyways!

                            Yes, you could write an awesome encoder and have it offload some portions of the encoding task to the GPU for an appreciateable speed boost. The GPU _can_ handle general computations, just not as well as the CPU, so it would still be some extra muscle (and a very select few parts of the encoding process could work very well on a GPU). The x264 devs have discussed this. The problem is (from what they've said), that GPU programming is _hard_. Or, at least hard to get it anywhere near useful for x264, which has the vast majority of its processor-intensive code written in assembly

                            So basically, from what I understand, they've said "Patches welcome, it's too hard for too little gain for us at least for now."


                            @Blackstar: Most general-purpose GPU "research", etc. is just that -- research. If I may quote the lead x264 devs (akupenguin and DS, source: http://mirror05.x264.nl/Dark/loren.html):

                            <Dark_Shikari> ok, its a motion estimation algorithm in a paper
                            <Dark_Shikari> 99% chance its totally useless
                            <wally4u> because?
                            <pengvado> because there have been about 4 useful motion estimation papers ever, and a lot more than 400 attempts


                            The majority of the rest is marketing chest-thumping by those who would benefit. AMD, NVIDIA, etc. Show me a _real-world_ test where a believeably configured PC (GTX 280s are not paired with Intel Atoms) with a GPU encoder beats a current build of x264's high-speed presets at the same quality (or better quality at same speed), and I'll eat my words

                            OpenCL is cool, and I think it's important in quite a few areas (Folding@home style computations and video decoding come to mind), but they've really gotta stop trying to make it seem like a silver bullet. A GPU is special-purpose. You can make it general-purpose -- but then you have a CPU anyways.
                            Last edited by Ranguvar; 10-03-2009, 01:24 AM.

                            Comment


                            • #44
                              Originally posted by Ranguvar View Post
                              Oy vey.

                              Basically, CPUs are general-purpose processors, and GPUs are special-purpose processors (again, _basically_!). [...] start making the GPU more general-purpose, which defeats the purpose of the GPU in the first place.
                              Cough, Larabee, cough. Not to mention the last 9 years in GPU design.

                              GPUs are becoming more general-purpose, generation by generation. They are becoming suitable for increasingly more complex tasks: five years ago, you could hardly squeeze a perlin generator. Nowadays you can generate complete voxel landscapes, accelerate F@H or even Photoshop.

                              I'm not saying that GPUs will ever reach CPUs in versatility (their massively parallel design prohibits that) - however, there's no indication that they'll stop becoming more generic in the near future.

                              Yes, you could write an awesome encoder and have it offload some portions of the encoding task to the GPU for an appreciateable speed boost. [...] The x264 devs have discussed this. The problem is (from what they've said), that GPU programming is _hard_. Or, at least hard to get it anywhere near useful for x264, which has the vast majority of its processor-intensive code written in assembly

                              So basically, from what I understand, they've said "Patches welcome, it's too hard for too little gain for us at least for now."
                              Obviously, GPGPU is a very new field. It's about two years old, in fact (introduction of G80), whereas we have more than 30 years of accumulated CPU programming experience and tools.

                              @Blackstar: Most general-purpose GPU "research", etc. is just that -- research. If I may quote the lead x264 devs (akupenguin and DS, source: http://mirror05.x264.nl/Dark/loren.html):

                              <Dark_Shikari> ok, its a motion estimation algorithm in a paper
                              <Dark_Shikari> 99% chance its totally useless
                              <wally4u> because?
                              <pengvado> because there have been about 4 useful motion estimation papers ever, and a lot more than 400 attempts
                              Research is research, duh - what else would it be?

                              You can bet that as soon as a researcher produces a viable solution, everyone and their mother will rush to implement it (first to market and all that). In a little while, even Nero will have it.

                              Remember the rush to implement and relief mapping a few years ago? The situation is pretty similar: at first, the technology was out of our reach - we didn't have the hardware, experience (or even drivers!) to implement this. Then someone came up with a viable approach, the hardware got better and people rushed to implement this cool new effect. Nowadays, if a game or engine demo doesn't display a form of relief mapping, its graphics are bashed as obsolete!

                              The majority of the rest is marketing chest-thumping by those who would benefit. AMD, NVIDIA, etc. Show me a _real-world_ test where a believeably configured PC (GTX 280s are not paired with Intel Atoms) with a GPU encoder beats a current build of x264's high-speed presets at the same quality (or better quality at same speed), and I'll eat my words

                              OpenCL is cool, and I think it's important in quite a few areas (Folding@home style computations and video decoding come to mind), but they've really gotta stop trying to make it seem like a silver bullet. A GPU is special-purpose. You can make it general-purpose -- but then you have a CPU anyways.
                              I don't recall anyone claiming that OpenCL is a silver bullet - but maybe I just don't pay attention to marketing attempts. Actually, it is developers who have undeniably shown a high level of interest in the technology.

                              With good reason, too. CPUs are getting more and more parallel but parallel programming is still something of a dark art. Anything that makes our lives easier is more than welcome: OpenCL, DirectCompute, Parallel.Net...

                              Also, don't forget that OpenCL can be used on more than just GPUs.
                              Last edited by BlackStar; 10-05-2009, 02:36 PM.

                              Comment


                              • #45
                                OpenCL could be used for the next-generation graphics -> Ray Tracing. It has the power to succeed OpenGL entirely.

                                Comment

                                Working...
                                X