Announcement

Collapse
No announcement yet.

AMD and NVIDIA bitchfight over open-source?

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

  • #11
    Besides, when you compare this article to "Australia bans A-cup boobs" or "Human beings are aliens; Celine Dion explained" I think it comes across pretty well
    Test signature

    Comment


    • #12
      Still, you have to admit, the NV guy has a point - their driver is still the best one out there.

      Comment


      • #13
        Originally posted by Hoodlum View Post
        Considering they cross licence pretty much any graphics related patents (or they simply wouldn't be able to make a card) it can't be that. Likely it is some other companies IP in the driver which they licenced and simply cannot release. This was the reason fglrx wasn't open sourced wasn't it?
        That's what I'm getting at. AMD released documentation without revealing 3rd-party licensed stuff. I don't think anyone expects them to hand over the proprietary/patented bits, but Nvidia doesn't seem to think open specifications are viable like AMD has done? Nvidia keeps saying "our driver has IP" yet that's not even what the question was to begin with.

        Comment


        • #14
          Originally posted by BlueJayofEvil View Post
          That's what I'm getting at. AMD released documentation without revealing 3rd-party licensed stuff. I don't think anyone expects them to hand over the proprietary/patented bits, but Nvidia doesn't seem to think open specifications are viable like AMD has done? Nvidia keeps saying "our driver has IP" yet that's not even what the question was to begin with.
          Reading the phoronix interview with nvidia I got the impression it was more "no that costs us money, time & effort" / "you aren't important enough"

          Here's what he said:

          Q: AMD was able to open source and/or document a lot by separating out the parts they couldn't legally disclose. Similar problems have been cited as preventing NVIDIA from open sourcing their driver (licensed 3rd parts code, etc) or documentation. Could nVidia use the same strategy?

          A similar strategy might be technically possible for NVIDIA, but for better or worse I think it is quite unlikely. There are several reasons for this:

          -
          Snipped reasons for not opening the closed driver as they have already been mentioned earlier in this thread (the same reasons ATI didn't open fglrx).
          -

          "- Unfortunately the vast majority of our documentation is created solely for internal distribution. While at some point it may be possible to release some of this information in pubic form it would be quite a monumental effort to go through the vast amounts of internal documents and repurpose them for external consumption."

          Source

          Comment


          • #15
            Originally posted by Hoodlum View Post
            "- Unfortunately the vast majority of our documentation is created solely for internal distribution. While at some point it may be possible to release some of this information in pubic form it would be quite a monumental effort to go through the vast amounts of internal documents and repurpose them for external consumption."

            Source
            Ah, I forgot that interview. Thanks for bringing it up.
            Maybe someday they will have the power to help out like AMD has done but I guess they don't want to exhaust their resources at this time.

            Comment


            • #16
              Originally posted by BlueJayofEvil View Post
              Ah, I forgot that interview. Thanks for bringing it up.
              Maybe someday they will have the power to help out like AMD has done but I guess they don't want to exhaust their resources at this time.
              Well with Intel effectively declaring war on them with larrabee (which was ironically later cancelled) and pushing them out of every sector they can (ruined their chipset business) they really don't need another drain on cashflow. That said AMD hasn't been doing well for years and they bothered to make the effort...so.

              Comment


              • #17
                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.

                Comment


                • #18
                  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

                  Comment


                  • #19
                    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:

                    Code:
                    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?

                    Comment


                    • #20
                      Originally posted by xiando View Post
                      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 ?

                      Originally posted by xiando View Post
                      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.

                      Originally posted by xiando View Post
                      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.

                      Originally posted by xiando View Post
                      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.
                      Test signature

                      Comment

                      Working...
                      X