Announcement

Collapse
No announcement yet.

AMD's opensource lies exposed

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

  • glxextxexlg
    started a topic AMD's opensource lies exposed

    AMD's opensource lies exposed

    The famous argument of AMD spec fanboys is that AMD will allways go on with providing full specs for their hardware while binary blob support can eventually break. In fact the truth is the opposite of it. It appears that the false opensource prophecy can break any time soon:

    http://www.cs.auckland.ac.nz/~pgut00..._cost.html#oss

    From that text:
    The only way to protect the HFS process therefore is to not release any technical details on the device beyond a minimum required for web site reviews and comparison with other products.
    Will opensource "drivers" from AMD support OpenGL 3x/4x and video acceleration in the future? Given the patented floating point support in OGL 3 and s3tc and these DRM arrangements, I've my doubts.
    So amd linux users will have half-baked featureless opensource drivers when amd will drop binary driver support for r600/r700 hardware and another waiting period will start for these people to be able to play OilRush.

    Wake up.

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

    Leave a comment:


  • devius
    replied
    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?

    Leave a comment:


  • popper
    replied
    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

    Leave a comment:


  • not.sure
    replied
    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

    Leave a comment:


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

    Leave a comment:


  • pingufunkybeat
    replied
    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?

    Leave a comment:


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

    Leave a comment:


  • glxextxexlg
    replied
    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

    Leave a comment:


  • mirv
    replied
    This thread has always been here.

    Leave a comment:

Working...
X