Announcement

Collapse
No announcement yet.

Nouveau Persevered In 2017 For Open-Source NVIDIA But 2018 Could Be Much Better

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

  • #11
    Since the critics focus on missing reclocking, does that mean every thing else is done and nouveau would be perfect once the firmware magically appears? I doubt it and believe there is enough other stuff that people have to work on.

    Comment


    • #12
      imirkin these firmware issues applies to the older cards too, the ones that don't need signed firmwares?

      Comment


      • #13
        Originally posted by andrei_me View Post
        imirkin these firmware issues applies to the older cards too, the ones that don't need signed firmwares?
        Cards before the pascal series of nvidia cards needed no firmware whatsoever unless you wanted GPU video decoding and encoding. After pascal you need signed firmware for anything to load or execute on the GPU. This is similar to AMD requiring a signed firmware VBIOS to be loaded by the linux kernel to be put onto the GPU. But AMD gives out that signed firmware and since nvidia never needed such firmware till pascal cards it is only now a problem. Old cards that run nouveau are entirely FOSS with no blobs except the read only firmware on the hardware itself. But that doesn't affect the linux kernel implementation.

        Comment


        • #14
          Originally posted by bemerk View Post
          Since the critics focus on missing reclocking, does that mean every thing else is done and nouveau would be perfect once the firmware magically appears? I doubt it and believe there is enough other stuff that people have to work on.
          It's a bit hard test games to find issues or implement features they need (and again test the games) if the card is stuck on boot clocks. At such low clocks the game does not run or its frames are measurable in fpm (frames per minute).

          Hardware acceleration for media is again bound by firmwares, so what else can they do?

          Comment


          • #15
            Originally posted by notanoob View Post
            This is similar to AMD requiring a signed firmware VBIOS to be loaded by the linux kernel to be put onto the GPU.
            Quick note - for unfortunate historical reasons VBIOS and microcode are both referred to as "firmware", but it's not the VBIOS that gets loaded into the GPU, it's separate microcode images. The VBIOS itself does not get loaded into the GPU, although VBIOS code (running on the CPU*) does load a couple of microcode images into the GPU itself.

            * The VBIOS code is actually written in a CPU-independent bytecode. The only x86-specific code in VBIOS is the bytecode interpreter and the INT15 handlers.
            Test signature

            Comment


            • #16
              Originally posted by bridgman View Post
              * The VBIOS code is actually written in a CPU-independent bytecode. The only x86-specific code in VBIOS is the bytecode interpreter and the INT15 handlers.
              Wait, so what are the supported architectures apart from x86? (I assume this was for supporting more than just x86)

              Is it possible to add arch-specific bytecode interpreters and "INT15 handlers" (whatever these handlers are) with VBIOS mods?

              Comment


              • #17
                The biggest issue with Nouveau is how distro maintainers are ignoring it. Even a latest live image of cutting-edge rolling release distros won't boot on Pascal because of Nouveau: unsupported chipset, and it's not Nouveau's fault, but of those who include outdated shit in distributions.

                Comment


                • #18
                  Originally posted by bridgman View Post

                  Quick note - for unfortunate historical reasons VBIOS and microcode are both referred to as "firmware", but it's not the VBIOS that gets loaded into the GPU, it's separate microcode images.
                  Is there a reason for AMD not to open source microcode and VBIOS (besides HDCP DRM related stuff?). I.e. can AMD for instance release DRM-free version of both that's FOSS?

                  Comment


                  • #19
                    Originally posted by shmerl View Post
                    Is there a reason for AMD not to open source microcode and VBIOS (besides HDCP DRM related stuff?). I.e. can AMD for instance release DRM-free version of both that's FOSS?
                    Legally, they can't release it as it would allow circumventing the DRM. It would violate the agreements they signed to be able to implement the various DRM systems in the first place.

                    Comment


                    • #20
                      Originally posted by starshipeleven View Post
                      Wait, so what are the supported architectures apart from x86? (I assume this was for supporting more than just x86) Is it possible to add arch-specific bytecode interpreters and "INT15 handlers" (whatever these handlers are) with VBIOS mods?
                      With nouveau before pascal and AMD cards using the old r300 driver you can compile the code to work on any architecture supporting using a pci(e) or AGP bus. But you are not going to be able to use it on anything but what the blobs support for just about any semi-modern AMD card and any post pascal nvidia card. Nvidia has had support for x86 and power pc for a while now with their blobs. I am not sure what AMD supports besides x86_64 and x86.
                      Originally posted by ua=42
                      Legally, they can't release it as it would allow circumventing the DRM. It would violate the agreements they signed to be able to implement the various DRM systems in the first place.
                      That makes it very odd that nvidia got away with such a thing for so long. I wonder what agreements AMD has that nvidia just recently has also agreed on that could cause this?

                      Comment

                      Working...
                      X