No announcement yet.

Disabling BlockSignalsOnLock?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Disabling BlockSignalsOnLock?

    Blob 12.6 from AMD's site, not sure if it's different than the latest 12.6 beta mentioned here.
    E-350 hw, unrecognized by aticonfig (no supported adapters detected). It's 1002:9802, a standard E-350 AFAIK.

    Now, in order to use gDebugger on this without it locking up, I need to disable the blob's BlockSignalsOnLock option.

    gDebugger tells to run "aticonfig --sb off", which obviously gives the no supported adapters message.
    The release notes say that one can also add that to the Device section in xorg.conf, so I added it.

    /var/log/Xorg.0.logWW) fglrx(0): Option "BlockSignalsOnLock" is not used
    Any hints? The unofficial bugzilla gave zero hits for "block".

  • #2
    Replace /etc/ati/control with the version from 12.6b or 12.4.
    Please search the forum a bit more in detail as this question has been answered multiple times - never the less: have fun with the blob


    • #3
      Ah, thanks. I thought my problem was with the blob ignoring the xorg.conf option, but getting aticonfig to recognize the card should work too


      • #4
        Worked, now aticonfig recognizes it and gdebugger could start.

        Shame on you, blob release team, for removing Evergreen pci ids when they are still supported.


        Well, gdebugger fails to profile my app, heh. I'll take that to the AMD devguru forums.

        My respect for the blob itself has just been knocked down a few notches, it fails to draw my terrain, sky, and SSAO, all things that Mesa draws just fine. And this is the "superior" driver, reporting GL 4.2 support and having a team of hundreds of people? lol.


        • #5
          If you check the bug ticket, we're already investigating how the IDs got dropped. Stay tuned.

          Where did you get the idea there were hundreds of people working on the Linux-specific parts of the driver (everything related to install, IDs etc is Linux-specific) ? The whole idea of a code-shared driver is that only the Linux-specific parts need separate development effort.
          Last edited by bridgman; 07-15-2012, 10:11 AM.


          • #6
            The OpenGL part is cross-OS, and the failure to draw big parts of my app is about that part, not the linux-specific parts.

            Note that you should take this as an accomplishment, the FOSS drivers beat the blob here hands down


            • #7
              Ahh, I missed the point that you were talking about drawing. Could be the code for X bindings vs Windows bindings, but most of the other code is shared as you say.

              For GL-specific issues it generally is worth mentioning in the bug ticket that the open source driver renders correctly -- for the rest of the functionality it's less useful because the two stacks are different in so many ways.
              Last edited by bridgman; 07-15-2012, 10:27 AM.


              • #8
                No bugs filed on the rendering issues, because until the app is near release, I simply do not give any fucks how it runs on the blobs, to be honest
                Also since it's private while in development, a bit hard to give them something to test.

                Also the recently exposed piglit results of the blob do not give much confidence, the blob not being thread-safe and even in single-threaded mode failing far more tests than the open drivers. That's pretty sad, isn't it?

                My primary interest with getting this blob system up was to test gdebugger, which seems to be too buggy to use. Anyone know how Nvidia's tools are on linux? Does PerfHUD still require a special 172-series driver? I'd look at the official docs, but Nvidia's dev site is offline following the leak.