Announcement

Collapse
No announcement yet.

Nouveau NVC0 Gallium3D Now Supports Indirect Drawing

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

  • Nouveau NVC0 Gallium3D Now Supports Indirect Drawing

    Phoronix: Nouveau NVC0 Gallium3D Now Supports Indirect Drawing

    Nouveau's NVC0 Gallium3D driver for supporting NVIDIA "Fermi" hardware and newer has picked up support for indirect drawing...

    http://www.phoronix.com/vr.php?view=MTc0MjU

  • #2
    Nouveau is lately making good progress; is this all done through reverse engineering the binary blobs?

    Comment


    • #3
      Very useful progress.

      Comment


      • #4
        Originally posted by siavashserver View Post
        Nouveau is lately making good progress; is this all done through reverse engineering the binary blobs?
        As far as I understand nouveau developers never reverse engineered blob itself because this can be illegal in many countries. Instead they watch how state changes after blob sending some commands to GPU and restore specifications for hardware this way.

        Obviously there just no reason to reverse engineer 3D implementation because Gallium is too different from what Nvidia uses anyway.

        Comment


        • #5
          Originally posted by _SXX_ View Post
          As far as I understand nouveau developers never reverse engineered blob itself because this can be illegal in many countries. Instead they watch how state changes after blob sending some commands to GPU and restore specifications for hardware this way.
          I'm not sure what you consider reverse engineering, but that sounds like the definition of it to me...

          Comment


          • #6
            Originally posted by agd5f View Post
            I'm not sure what you consider reverse engineering, but that sounds like the definition of it to me...
            I suppose that "reverse engineering of blob" would mean disassemble parts of driver with something like IDA Pro and try to recreate driver code with reproduction of original driver logic include things like OpenGL implementation. This is obviously illegal in many parts of the world.

            If I understand correctly how REnouveau works then it's needed for reverse engineering of specs, but not driver itself.

            Am I missing something?

            Comment


            • #7
              Originally posted by _SXX_ View Post
              I suppose that "reverse engineering of blob" would mean disassemble parts of driver with something like IDA Pro and try to recreate driver code with reproduction of original driver logic include things like OpenGL implementation. This is obviously illegal in many parts of the world.

              If I understand correctly how REnouveau works then it's needed for reverse engineering of specs, but not driver itself.

              Am I missing something?
              My point is that it's still reverse engineering whether you are trying to figure out how the hw works or how the driver is structured.

              Comment


              • #8
                Originally posted by _SXX_ View Post
                I suppose that "reverse engineering of blob" would mean disassemble parts of driver with something like IDA Pro and try to recreate driver code with reproduction of original driver logic include things like OpenGL implementation. This is obviously illegal in many parts of the world.

                If I understand correctly how REnouveau works then it's needed for reverse engineering of specs, but not driver itself.

                Am I missing something?
                We are not using renouveau anymore. We use mmiotraces and valgrind-mmt instead. It is much more powerful

                And you are right, we don't do decompilation, unless absolutely necessary (firmwares).

                Comment


                • #9
                  Originally posted by agd5f View Post
                  My point is that it's still reverse engineering whether you are trying to figure out how the hw works or how the driver is structured.
                  Yeah I suppose you're right. Statement corrected.

                  Comment


                  • #10
                    Amateur 'reverse engineer' here.

                    There's two main ways to reverse engineer stuff. The first is, as mentioned above, to take the software (driver in this case) and decompile it to some meaningful programming code (most often very unreadible ASM). You then skim through and deduce or *ghasp* take little bits of logic (or raw data) and put it in your own version of the software. This is widely regarded as illegal, because it often breaches copy protection mechanisms (DMCA and all that), or plain copyright infringement because some unmodified code (however small) is copied. Example: the Skype library that claims to have reverse engineered the protocol (IIRC it has bits of the Skype disassembly in it).

                    The legal way to do it, often called 'clean room reverse engineering' is to not decompile, and not to copy stuff, but only look at the input and output of the software. For example, (binary) files it outputs, and writing a specification or program to parse or write it. When big companies do this, they hire one team to pick appart the files, document them, and have another team write the source code for IO library, just so they have a paper trail in case of a lawsuit. In Europe at least, this is explicitly legal, for the reason of data compatibility between packages to prevent vendor-lockin (MS and others lost quite a few lawsuits in the 90's). Example: libjpeg by IJG.

                    In the case of graphics drivers, you 'just' snoop on the command pipeline between the driver and the GPU. This is rather tedious because what comes back is usually just pixels (framebuffer) or transformed geometry (transform feedback), and thousands of states or resources may influence it, but it's perfectly legal (even in the USA).

                    Of course there's still gray areas in between. Decompiling a driver for example may reveal some hints, or narrow down which state changes affect what. I've reverse engineered a few binary file formats in my time, and it never hurts to skim through an executable with a hex editor. Sometimes some leftover debugging strings can reveil the name of a compression algorithm that's obfusicating your otherwise well-structured data. I gues one could, with possibly some soldering (and a lot of in-depth knowledge) possibly dump the GPU memory, pick around in that with hex editor and such and learn something as well. If you're lucky and find a debugging hook to do that placed there by the vendor, you may be moving back into the white area again, as exploiting undocumented hardware/software features is generally regarded as not illegal by many precedents.

                    Comment

                    Working...
                    X