HyperZ: Errata & The Catalyst Command Stream

[bridgman]

I have a few different jobs. Some are more architect-ish, some are more manager-ish.

I'm trying to get back down to one or two jobs so I can have time to write code again (other than perl scripts for generating status reports ).

[maldorordiscord]

I have a few different jobs. Some are more architect-ish, some are more manager-ish.

I'm trying to get back down to one or two jobs so I can have time to write code again (other than perl scripts for generating status reports ).

You can give me your "Bridgman@phoronix" account access data then I write here for you and you can code again.
I'm sure I can handle this job. I do this even for free! You will not regret it!

[bridgman]

I'm sure a similar discussion took place in the reactor #4 control room at Chernobyl.

"Sure the alarm is going off but I can fix it. I am sure I can handle this job. You will not regret it."

[GreatEmerald]

I'm sure a similar discussion took place in the reactor #4 control room at Chernobyl.

"Sure the alarm is going off but I can fix it. I am sure I can handle this job. You will not regret it."

Nah, it was more like "The alarm's going off? *unplugs* What alarm?"

[maldorordiscord]

I'm sure a similar discussion took place in the reactor #4 control room at Chernobyl.

"Sure the alarm is going *(on)off but I can fix it. I am sure I can handle this job. You will not regret it."

I'm an engineer with 30 years experience I was there when they successfully controlled: 29 September 1957 at Kyshtym Town.
What you don't know it? That's my perfect job I managed it to censorship this 40-50 years in a round!
And Today it's even more successfully because no one gives a fuck about old stories anyway!
Be sure I will manage your job perfectly. Anyone who criticize AMD will get a permanent ban and any negative message will be suppressed and we will censorship any negative news about AMD!

To learn from communism is learning how to win!

[phred14]

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?

[bridgman]

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.

[phred14]

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

[glisse]

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.

[bridgman]

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