AMD's opensource lies exposed

[glxextxexlg]

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

[Kano]

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.

[pingufunkybeat]

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?

[popper]

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.

[not.sure]

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

[popper]

That's a Big MAC, eh.
http://bigmac.yolasite.com/resources...lds_bigmac.jpg

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

[devius]

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

[popper]

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