Announcement

Collapse
No announcement yet.

AMD's opensource lies exposed

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

  • 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.

        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."

          Digital Signal Processing (DSP) extensions to the Arm instruction sets.

          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?



              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


              "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