AMD and NVIDIA bitchfight over open-source?

[bridgman]

Forgot to paste the commit :

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

[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

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

[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!

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

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