Announcement

Collapse
No announcement yet.

AMD's opensource lies exposed

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

  • Nvidia doesn't even provide drivers for all their hardware. Unlike AMD
    Unlike AMD's inferior, buggy and feature poor linux support, nvidia's linux drivers work as expected, with good xserver-kernel support updates and good bug fixing, stabilization.



    This chip (being released in 2001) is still supported by nvidia's legacy drivers, with proper up-to-date xserver-kernel support.

    http://www.nvidia.com/object/linux-d...19-driver.html

    Comment


    • Your definition of proper means without KDE 4 effects support as then the screen tends to turn black with 96.xx series. But for some simple games a geforce 3 is still faster than a 9800 pro with oss drivers.

      Comment


      • Originally posted by glxextxexlg View Post
        Unlike AMD's inferior, buggy and feature poor linux support, nvidia's linux drivers work as expected, with good xserver-kernel support updates and good bug fixing, stabilization.
        Xrandr 1.3 is still not supported, 17 months after release.

        Good xserver-kernel support indeed. Multi-monitor broken.

        This chip (being released in 2001) is still supported by nvidia's legacy drivers, with proper up-to-date xserver-kernel support.
        Is that Optimus? How well is that supported with good xserver-kernel support?

        Why don't you buy one and tell us?

        Comment


        • Originally posted by bridgman View Post
          Here's the problem :

          BTW I've read 37 pages of thread and haven't found any actual AMD opensource lies yet, did I miss something juicy ?
          well "opensource lies" is such as derogatory label i suppose , perhaps "PR innovations" are a more acceptable label and we can get the thread name changed LOL....

          on a totally separate subject before i forget....FYI

          as regards getting some good and valid PR i noticed in the x264dev log's that the assembly devs are looking to add AMD AVX and perhaps improve AMD Encoding performance for the up and coming 2011
          http://www.compression.ru/video/code...ion_movies.png MSU video codec comparison http://www.compression.ru/video/codec_comparison/

          "2011-01-28 05:36:46 < pengvado> but there is a vpcomltb and there is no vpcmpltb
          2011-01-28 05:36:57 < Dark_Shikari> oh you mean vcmp has gt only
          2011-01-28 05:36:58 < Dark_Shikari> ic
          2011-01-28 05:37:24 < Dark_Shikari> vphsubbw might be interesting?
          2011-01-28 05:38:44 < Dark_Shikari> hmm. VPMACSDD would be useful for high bit depth quant perhaps
          2011-01-28 05:38:53 < Dark_Shikari> 32 * 32 + 32 -> 32
          2011-01-28 05:39:25 < Dark_Shikari> and VPMACSSDD (saturating)
          2011-01-28 05:39:55 < Dark_Shikari> ... they have 16x16 MAC too
          2011-01-28 05:39:56 < Dark_Shikari> for integer
          2011-01-28 05:39:58 < Dark_Shikari> this might be useful.
          "

          but with it only a around week away and their having to use the http://developer.amd.com/cpu/simnow/Pages/default.aspx it makes it hard to help and test AMD CPU improvements.

          it might be in you're interest bridgman to pop over there #x264dev ASAP and find a way to offer them some remote shell access to your current AVX capable and other new CPU's so they can write the AVX assembly routines etc and test it on the real things... if your so inclined, OC Intel Francois Piednoel was also so inclined and in a position to organise this remote access but apparently that didn't happen , so you have an opportunity to on up him and get a good but of PR and praise in the codec_comparison etc.

          Comment


          • Originally posted by popper View Post
            2011-01-28 05:39:55 < Dark_Shikari> ... they have 16x16 MAC too
            That's a Big MAC, eh.
            http://bigmac.yolasite.com/resources...lds_bigmac.jpg

            Comment


            • Originally posted by not.sure View Post
              yeah, although your link shows a double/triple cycle 16x16 MAC so slower and not very good for you

              in the case of the IRC log they are referring to DSP SIMD instructions, for instance ARM cortex has among others the Single-cycle 16x16 and 32x16 MAC implementations.

              "Compilers targeting the [ARM] architecture can use these DSP extensions to improve code-generation for standard C and C++ software, or allow software developers to explicitly request use of these extension via intrinsics or inline assembly code.

              Performance
              The ARM DSP extensions enable increased DSP performance without the need for very high clock frequencies. This performance is achieved with almost no increase in power consumption on a typical implementation."

              http://www.arm.com/products/processo...s/dsp-simd.php

              Comment


              • Originally posted by popper View Post
                "2011-01-28 05:36:46 < pengvado> but there is a vpcomltb and there is no vpcmpltb
                2011-01-28 05:36:57 < Dark_Shikari> oh you mean vcmp has gt only
                2011-01-28 05:36:58 < Dark_Shikari> ic
                2011-01-28 05:37:24 < Dark_Shikari> vphsubbw might be interesting?
                2011-01-28 05:38:44 < Dark_Shikari> hmm. VPMACSDD would be useful for high bit depth quant perhaps
                2011-01-28 05:38:53 < Dark_Shikari> 32 * 32 + 32 -> 32
                2011-01-28 05:39:25 < Dark_Shikari> and VPMACSSDD (saturating)
                2011-01-28 05:39:55 < Dark_Shikari> ... they have 16x16 MAC too
                2011-01-28 05:39:56 < Dark_Shikari> for integer
                2011-01-28 05:39:58 < Dark_Shikari> this might be useful.
                "
                Are they actually communicating or that's just gibberish to make it look like they know what they're talking about to non-tech people? How do you know they are even talking about AVX?

                Comment


                • Originally posted by devius View Post
                  Are they actually communicating or that's just gibberish to make it look like they know what they're talking about to non-tech people? How do you know they are even talking about AVX?
                  LOL read the log in sections sometime ,it goes back a long time so start at say
                  2010-10-30 22:15:27 < kierank> is x264 participating in google code-in?

                  http://akuvian.org/src/x264/freenode-x264dev.log.bz2

                  its interesting for even non assembly reader's and you get good advice/idea's you can take to other projects etc, how you might improve audio codecs AAC etc being the latest insight for instance, not to mention why even professional GFX coders seem to have an aversion to writing working Gfx cuda/opencl etc x264 encoder patches once they ask on x264dev, all people who try are eaten by the cuda monster


                  and OC if you goggled vphsubbw for instance you would find
                  https://docs.google.com/viewer?url=h...Docs/26568.pdf

                  "AMD64 Architecture
                  Programmerís Manual

                  Volume 4:
                  128-Bit and 256-Bit
                  Media Instructions"

                  AKA SIMD/AVX etc

                  and OC if you look above that section of the log i posted you would see they are writing AVX and mention AVX pathes etc...

                  Comment

                  Working...
                  X