AMD and NVIDIA bitchfight over open-source?

[bridgman]

I believe it's called NVCUVID. The description (CUDA library for video decode) is a bit of a misnomer - AFAIK it uses the dedicated on-chip decode hardware to go from bitstream to YCbCr frames, then makes those decoded frames available to the calling app for further processing with CUDA, GL or CPU code.

The "CUDA-ness" comes from the fact that the library is intended to be called by a CUDA app, not that it uses CUDA for decoding.

[gbeauche]

I was specifically talking about drivers. I know that NVidia contributes in other areas, and that some of their proprietary driver bits get used in other open source projects (eg the CUDA lib for video decode which gets used by open source transcoding projects).

Interesting, do you have more details on this CUDA lib? AFAIK, the video decode acceleration done through CUDA for CoreAVC for example is not executing on GPU in reality but still using the VPU. i.e. it's not shader based either. One CoreAVC dev said there is no GPU fast enough to do that. BTW, there will be the same on Linux through the VDPAU/CUDA interop.

[ivanovic]

The free software driver works great with kde4.4 kwin 3d effects (ab)using kernel 2.6.33-rc7 with KMS and a recent Xorg server with a git snapshot, sure, but very few people have the know-how to get this software technology working. If you pop in any mainstream linux distro and install it then you are hurded into using the AMD binary blob. And people who do have the skills have to use extra time getting the free driver working, and it doesn't always work, even right now, the mesa git doesn't even compile, WHICH IS A TOTAL OUTRAGE. It FAILS with:

x86_64-pc-linux-gnu-gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm    -march=amdfam10 -O2 -pipe -ffast-math -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm   -DRADEON_R600 r600_texstate.c -o r600_texstate.o
r600_texstate.c: In function 'r600SetTexBuffer':
r600_texstate.c:1119: error: '__DRM_TEXTURE_FORMAT_RGBA' undeclared (first use in this function)
r600_texstate.c:1119: error: (Each undeclared identifier is reported only once
r600_texstate.c:1119: error: for each function it appears in.)
gmake[6]: *** [r600_texstate.o] Error 1
gmake[6]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/r600'
gmake[5]: *** [lib] Error 2
gmake[5]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/r600'
gmake[4]: *** [subdirs] Error 1
gmake[4]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers'
gmake[2]: *** [driver_subdirs] Error 2
gmake[2]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src'
make: *** [default] Error 1

Fixed in latest git master!

[xiando]

A number of current distros offer prebuilt packages to give users the latest open source driver code for 6xx/7xx GPUs (3D for earlier parts shipped with the distro release). In most cases the X driver and kernel driver in the distro release are sufficiently new and only a mesa update is required. The packages vary from distro to distro but from what I have seen anyone asking on a distro forum usually gets pretty good information.

You admit you must do something (update mesa) and the easiest thing to do on Ubuntu is the binary blob. This will works itself out soon enough. Lucid | fedora I use the git so I see what those stable people get in half a year.

Looks like this commit (earlier today) introduced a typo; if you replace "DRM" with "DRI" on that line (in r600_texstate.c) it should build OK for now until the commit gets fixed.

Just curious, why is it a TOTAL OUTRAGE that something gets temporarily broken in the development tree ? Wouldn't someone looking for stable code build off the 7.7 release branch, not the unreleased code in git master.

It annoyed. Thank you for looking into it.

I was asked a very specific question about NVidia. It was hard to answer the question without talking about them.

This would have been a lot more clear (but a lot less interesting ) if the article had listed both questions and answers.

Interesting. I'll come up with some very good questions to secure some adsense milk-money later.

[bridgman]

BTW if you mean it's a TOTAL OUTRAGE that a commit went in which broke the build of a specific driver, yeah that shouldn't have happened.

Might be that KRH had some funky headers so it built for him, or maybe he made one last tweak without doing a final build, not sure.

If you mean "the development branch should always be ready for an unskilled user to build for everyday use" I'm not so sure that's true and I suspect the devs would point to a stable release branch instead.

I miss the good old days when all this could go into the original post

[bridgman]

Forgot to paste the commit :

http://cgit.freedesktop.org/mesa/mesa/commit/?id=debf00e5fc3828f63e0f99d72c7fa6cd6ce012c5

[bridgman]

This is true, even here at Phoronix, the AMD assets seem to be hell-bent making sure that everybody reads that nvidia only provides a binary blob. Their accusation is of course true.

I didn't understand the NVidia statement or yours. I can think of maybe 5-10 minutes in the last 2 years, not just for me but for all of the AMD staff interacting with the public. What am I missing ?

A problem with their badmouthing is that AMD too requires most of their users to accept the binary blob at this point.

The free software driver works great with kde4.4 kwin 3d effects (ab)using kernel 2.6.33-rc7 with KMS and a recent Xorg server with a git snapshot, sure, but very few people have the know-how to get this software technology working. If you pop in any mainstream linux distro and install it then you are hurded into using the AMD binary blob.

A number of current distros offer prebuilt packages to give users the latest open source driver code for 6xx/7xx GPUs (3D for earlier parts shipped with the distro release). In most cases the X driver and kernel driver in the distro release are sufficiently new and only a mesa update is required. The packages vary from distro to distro but from what I have seen anyone asking on a distro forum usually gets pretty good information.

And people who do have the skills have to use extra time getting the free driver working, and it doesn't always work, even right now, the mesa git doesn't even compile, WHICH IS A TOTAL OUTRAGE.

<snip>

this is a TOTAL OUTRAGE!!!!!!!

Looks like this commit (earlier today) introduced a typo; if you replace "DRM" with "DRI" on that line (in r600_texstate.c) it should build OK for now until the commit gets fixed.

Just curious, why is it a TOTAL OUTRAGE that something gets temporarily broken in the development tree ? Wouldn't someone looking for stable code build off the 7.7 release branch, not the unreleased code in git master.

Just one last little tip to the Bridgman drone...: Why not talk more, or simply only, about the work that AMD is actually doing when journalists pump you for information? Why even mention the Nvidia?

I was asked a very specific question about NVidia. It was hard to answer the question without talking about them.

This would have been a lot more clear (but a lot less interesting ) if the article had listed both questions and answers.

[xiando]

The NVidia drone in the article brings up a few valid points.

Humber ranted that AMD invested ?extraordinary amounts of time trying to position Nvidia as closed/proprietary,?

This is true, even here at Phoronix, the AMD assets seem to be hell-bent making sure that everybody reads that nvidia only provides a binary blob. Their accusation is of course true. A problem with their badmouthing is that AMD too requires most of their users to accept the binary blob at this point.

The free software driver works great with kde4.4 kwin 3d effects (ab)using kernel 2.6.33-rc7 with KMS and a recent Xorg server with a git snapshot, sure, but very few people have the know-how to get this software technology working. If you pop in any mainstream linux distro and install it then you are hurded into using the AMD binary blob. And people who do have the skills have to use extra time getting the free driver working, and it doesn't always work, even right now, the mesa git doesn't even compile, WHICH IS A TOTAL OUTRAGE. It FAILS with:

x86_64-pc-linux-gnu-gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm    -march=amdfam10 -O2 -pipe -ffast-math -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm   -DRADEON_R600 r600_texstate.c -o r600_texstate.o
r600_texstate.c: In function 'r600SetTexBuffer':
r600_texstate.c:1119: error: '__DRM_TEXTURE_FORMAT_RGBA' undeclared (first use in this function)
r600_texstate.c:1119: error: (Each undeclared identifier is reported only once
r600_texstate.c:1119: error: for each function it appears in.)
gmake[6]: *** [r600_texstate.o] Error 1
gmake[6]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/r600'
gmake[5]: *** [lib] Error 2
gmake[5]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/r600'
gmake[4]: *** [subdirs] Error 1
gmake[4]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers'
gmake[2]: *** [driver_subdirs] Error 2
gmake[2]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src'
make: *** [default] Error 1

this is a TOTAL OUTRAGE!!!!!!!

Just one last little tip to the Bridgman drone...: Why not talk more, or simply only, about the work that AMD is actually doing when journalists pump you for information? Why even mention the Nvidia?

[xiando]

The NVidia drone in the article brings up a few valid points.

Humber ranted that AMD invested ?extraordinary amounts of time trying to position Nvidia as closed/proprietary,?

a

[Vash63]

Yeah, as much as I dislike nvidia for their proprietary nature with SLI certs, physx and their lack of OSS support, Intel really did try to destroy them in pretty unfair ways.