Page 41 of 41 FirstFirst ... 31394041
Results 401 to 408 of 408

Thread: AMD's opensource lies exposed

  1. #401
    Join Date
    Oct 2010
    Posts
    145

    Default

    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

  2. #402
    Join Date
    Aug 2007
    Posts
    6,625

    Default

    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.

  3. #403
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    Quote 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?

  4. #404
    Join Date
    Jan 2007
    Posts
    459

    Default

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

  5. #405
    Join Date
    Oct 2009
    Location
    .ca
    Posts
    402

    Default

    Quote 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

  6. #406
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote 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

  7. #407
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    945

    Default

    Quote 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?

  8. #408
    Join Date
    Jan 2007
    Posts
    459

    Default

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

Tags for this Thread

Posting Permissions

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