If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
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
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.
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:
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.
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.