Announcement

Collapse
No announcement yet.

HyperZ: Errata & The Catalyst Command Stream

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

  • #46
    Preface... I have 30+ years in hardware design, currently treading the line between hardware and software that creates the hardware design - still in a hardware department, and still tied to specific hardware.

    I've had stuff that's been out in the field for years, and suddenly some customer does something new that causes a fail. Sometimes it's out-of-spec, but "everybody does it," sometimes it's "it's legal, but why would anyone do THAT!", etc.

    At any rate, the light went off when someone said "hardware simulation." I presume we're talking a verilog netlist of the chip, running either in software or some sort of acceleration engine, and you're running snippets of driver code. So here's the question... With some guidance from AMD, could the Mesa developers extract some sequences of their driver code to give to AMD. Could AMD then run that code and give the results back to Mesa? AMD gets to keep their verilog netlist private, yet gets another set of eyeballs and another perspective on their hardware. Mesa gets better debug info - since usually hardware is the hardest way to debug a problem.

    This would obviously start with old/existing hardware, but would give AMD a chance to run those same driver sequences against future hardware. Without divulging information or plans, it give a way to pull at least some Mesa development earlier in the design cycle - at least hopefully to verify old function.

    Alternatively, is there any sort of "encrypted verilog" that can be used with OSS tools?

    Comment


    • #47
      Good question. We can't do it with older hardware for the simple reason that the emulators are running 24/7 on new hardware and switching images back and forth would interfere non-trivially with other work that needs to be done.

      That said, since AMD developers write the initial Mesa support for new chips anyways we can (hopefully) do a bit of pre-silicon testing or at least find post-silicon problems early enough to try on the emulators so the HW folks can help us find out what is happening.

      Unfortunately the problems we're talking about here aren't the kind you can find with simple sequences, but usually need a lot of things going on in parallel to trigger the problem.
      Last edited by bridgman; 07-16-2012, 01:47 PM.

      Comment


      • #48
        Originally posted by bridgman View Post
        Good question. We can't do it with older hardware for the simple reason that the emulators are running 24/7 on new hardware and switching images back and forth would interfere non-trivially with other work that needs to be done.
        I thought that might be the case. There's never enough capacity, and though sometimes there may be a down day here or there, changeover can eat that up. Sounds like you're talking a hardware accelerator for simulation? Encrypted verilog aside, is the difference between hardware and software emulation so great that a patient OSS developer couldn't use it? (If an encrypted netlist existed and could be use say, by Icarus verilog.)

        Comment


        • #49
          Originally posted by jakubo View Post
          iirc there are at least 3 versions of HZ since the Radeon 9xxx series right? so i guess some people have sat quite some time to get things done and i think (ok, actually i very very very much hope) that someone would remember and could maybe donate the "missing link" to the open source devs.
          even though its 5 years ago (just when the open source policy started) ... would it be possible to ask around at AMD (or maybe some old ATI veteran) how things were managed?
          i honestly cannot believe that such important things went undocumented... concerning some code upgrade.. please there must be someone...
          and please dont tell me that AMD bases its business on "if you do it the same way it might work"
          The issue is not it not working, which would have been documented, the issue is that it triger lockup and yes there is tons of valid reason which might lead to this not being documented just read my post i explain most of them.

          Comment


          • #50
            Originally posted by phred14 View Post
            I thought that might be the case. There's never enough capacity, and though sometimes there may be a down day here or there, changeover can eat that up. Sounds like you're talking a hardware accelerator for simulation? Encrypted verilog aside, is the difference between hardware and software emulation so great that a patient OSS developer couldn't use it? (If an encrypted netlist existed and could be use say, by Icarus verilog.)
            Yep, I imagine everyone in the GPU business uses the same hardware emulators... GPUs are so big these days that very few systems can handle them.

            The big difference is speed... maybe 1/1000th of real time for a hardware emulator and another 100x slower for exact software emulation of the smallest variant of the chip. HW emulation isn't significantly affected by chip size -- it either fits on the parallel hardware or doesn't -- but SW emulation speed goes down dramatically as the chip size goes up. Inexact SW emulation can run faster, of course, but you typically need lower level emulation to properly model a lockup

            We haven't looked deeply into encrypted netlists but initial feedback wasn't particularly promising... at first glance they seem to really be "unencrypted netlists with encrypted debug info". We do need to spend more time looking into that area though...
            Last edited by bridgman; 07-16-2012, 01:57 PM.

            Comment


            • #51
              Originally posted by bridgman View Post
              We haven't looked deeply into encrypted netlists but initial feedback wasn't particularly promising... at first glance they seem to really be "unencrypted netlists with encrypted debug info". We do need to spend more time looking into that area though...
              I'm not too optimistic. From what I understand, the ability to simulate encrypted netlists is something the simulator vendors cook into their products, precisely so that proprietary IP can be given to customers for simulation without revealing internal details. But I would think that depends on the simulator not spilling the beans, in addition to, as you suggest, that a lot of encryption is done - poorly. Add to that the fact that OSS tends to be repulsed by the idea of using encryption to hide proprietary details, and that you could hack the source code to reprint the newly decrypted source, etc...

              So let's look at a different tack... Is it possible to release "obsolete" netlists? They're smaller, so maybe it's possible so simulate in a week or two with a Beowulf cluster or GPU-at-home. Presumably there's also some "familial" relationship between your products, so that even in the new product, the old feature may work pretty much the same way. (Is Hyper-Z old enough to be on an "obsolete" chip yet?) Even obsolete netlists could also give OSS driver developers new insights into the hardware and how to code for it.

              Comment


              • #52
                would there be any use setting up a system like folding@home has been some time ago to provide simulation and processing power to developers via internet? like some huge cluster of linux users using cpu power, and when matured openCL to help the linux community?
                is it even possible? security issues? other "things"..?

                Comment


                • #53
                  Originally posted by phred14 View Post
                  ...
                  So let's look at a different tack... Is it possible to release "obsolete" netlists? They're smaller, so maybe it's possible so simulate in a week or two with a Beowulf cluster or GPU-at-home. Presumably there's also some "familial" relationship between your products, so that even in the new product, the old feature may work pretty much the same way. (Is Hyper-Z old enough to be on an "obsolete" chip yet?) Even obsolete netlists could also give OSS driver developers new insights into the hardware and how to code for it.
                  If the industry hadn't taken a bit of a step back (where interest in ultra-low power dx9-level GPUs is high again) that would be a lot easier. Unfortunately what might be considered obsolete netlists are suddenly real valuable again, in the same way that old CPU cores are coming back in vogue as part of a many-core processing array.

                  Originally posted by jakubo View Post
                  would there be any use setting up a system like folding@home has been some time ago to provide simulation and processing power to developers via internet? like some huge cluster of linux users using cpu power, and when matured openCL to help the linux community?
                  is it even possible? security issues? other "things"..?
                  Security issues would probably be a showstopper unless we hosted the system internally, then it would only be a serious challenge. Simulators do seem to be getting better at scaling across a lot of cores, although I don't know if the scaling is at the point where anyone with less patience than an archaeologist could live with the performance.

                  Comment

                  Working...
                  X