Page 1 of 3 123 LastLast
Results 1 to 10 of 28

Thread: Nouveau Gets Further Freed From Ctx_Voodoo

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    13,426

    Default Nouveau Gets Further Freed From Ctx_Voodoo

    Phoronix: Nouveau Gets Further Freed From Ctx_Voodoo

    One of the issues that was widely discussed when Linus Torvalds brought up finally merging the Nouveau DRM into the Linux 2.6.33 kernel was a microcode problem. The past few generations of NVIDIA graphics processors require this specialized microcode/firmware to be loaded in order to provide acceleration of any sort...

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

  2. #2
    Join Date
    Aug 2008
    Posts
    56

    Default

    Call me a skeptic, but I am finding it pretty hard to believe the advancements in the Nouveau driver have all occurred without any help from Nvidia. I know that they publicly have stated that they will neither help nor hinder the Nouveau developers. But I think the Nouveau guys/gals? have an inside source, whether that is official or not.

  3. #3
    Join Date
    Aug 2006
    Posts
    15

    Default

    gsacks, I can't speak for anyone else with 100% certainty (99% is closer), but NVIDIA haven't given away any info to me, despite what you find pretty hard to believe! Trust me, there's quite a lot of things I wish they *would* help with!

    A small note on the article itself, the nv40 ctxprog replacements *are* generated at runtime the same way as this lot... Not sure where the idea they're loaded blobs comes from exactly..

  4. #4
    Join Date
    Jan 2009
    Posts
    206

    Default

    Quote Originally Posted by gsacks View Post
    But I think the Nouveau guys/gals? have an inside source, whether that is official or not.
    Think again .

  5. #5
    Join Date
    Aug 2009
    Posts
    125

    Default

    Quote Originally Posted by gsacks View Post
    Call me a skeptic, but I am finding it pretty hard to believe the advancements in the Nouveau driver have all occurred without any help from Nvidia. I know that they publicly have stated that they will neither help nor hinder the Nouveau developers. But I think the Nouveau guys/gals? have an inside source, whether that is official or not.
    Nouveau is mostly developed by Red Hat and they would never risk to do what you are suggesting.

  6. #6
    Join Date
    Dec 2008
    Posts
    315

    Default

    Quote Originally Posted by gsacks View Post
    Call me a skeptic, but I am finding it pretty hard to believe the advancements in the Nouveau driver have all occurred without any help from Nvidia. I know that they publicly have stated that they will neither help nor hinder the Nouveau developers. But I think the Nouveau guys/gals? have an inside source, whether that is official or not.
    The hardware industry is surprisingly codependant and intertwined. You'd be surprised just how much alike everything is just because of how it all forms from the ground up from various same source springs. All these big fat gpu's and cpu's and chipset chips. They all came from smaller fat cpu's and chipsets and those came from even less merged cpu's and gpu's and chipsets. Until you eventually get down to ttl logic and various standard ways of doing things. You're seeing the packages change little by little slowly over time.
    I think nvidia is going to suck for complete widespread support and bugs for quite a while but Nouveau had NV to help start out. If it had binary blob code the rest would be easy but just various programming and other docs released to show developers and engine makers how to do stuff will eventually get it understood.
    I used to read chipset documents all the time years ago. They are a bit more tight lipped about it all now but they still have to explain things sooner or later. Arrow electronics used to have tons of documents on it's BBS back in the dialup days.

  7. #7
    Join Date
    Jan 2008
    Posts
    772

    Default

    I think most people just don't understand how this kind of reverse-engineering works. The trick is mostly knowing what to look for and having the dedication to keep on looking. Having the hardware in hand helps too.

  8. #8
    Join Date
    Jan 2009
    Posts
    141

    Default

    so does this have any advantages? generating it's own firmware instead of using a set one sounds good.

    like, can it change the firmware on the fly by optimizing it for whatever you're doing? 2d/3d desktop/games?

  9. #9
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,099

    Default

    Quote Originally Posted by portets43 View Post
    so does this have any advantages? generating it's own firmware instead of using a set one sounds good.

    like, can it change the firmware on the fly by optimizing it for whatever you're doing? 2d/3d desktop/games?
    Nope, this just alleviates some licensing/copyright worries.

  10. #10
    Join Date
    Jan 2009
    Posts
    141

    Default

    okay. i was just thinking that it would be cool if it could communicate with the llvm compiler that's etting hooked into gallium3d that optimizes shader code "on the fly".

    do the binary drivers have dynamic shader recompilers linked into them like gallium is getting?

Posting Permissions

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