Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Nouveau NVC0 Gallium3D Now Supports Indirect Drawing

  1. #1
    Join Date
    Jan 2007
    Posts
    15,129

    Default 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. #2
    Join Date
    Oct 2013
    Posts
    195

    Default

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

  3. #3
    Join Date
    Sep 2010
    Posts
    474

    Default

    Very useful progress.

  4. #4
    Join Date
    Sep 2013
    Posts
    242

    Default

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

  5. #5
    Join Date
    Dec 2007
    Posts
    2,395

    Default

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

  6. #6
    Join Date
    Sep 2013
    Posts
    242

    Default

    Quote 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?

  7. #7
    Join Date
    Dec 2007
    Posts
    2,395

    Default

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

  8. #8
    Join Date
    Feb 2009
    Location
    France
    Posts
    309

    Default

    Quote 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).

  9. #9
    Join Date
    Sep 2013
    Posts
    242

    Default

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

  10. #10
    Join Date
    Sep 2013
    Location
    below sea-level
    Posts
    25

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •