HyperZ: Errata & The Catalyst Command Stream

[maldorordiscord]

You da man.
Now we just need to get that onto a T-shirt for glisse.

Maybe I should earn money by designing nerd stuff.
Put this on a T-shirt is simple just print it cut it out get a black spray for cotton and spray it with the submission on the t-shirt.

There are also shops with that as a service: http://www.shirtcity.com/

Auggh !! My eyes !!!

Another talent from me: psycho hypnosis by pictures LOL...

[crazycheese]

I explain in my blog post why there might very well be no errata or special code in the closed source driver for the issue i am hitting. So to paraphrase myself, fglrx is doing things differently than the open source driver and this is the out come of many things :
- intentional to work around some issue
- out come of driver stack architecture
- human that wrote the code, wrote that register A before register B with no special intention to do so
...

- closed source driver has some parts "written" by a middle-ware algorithm, that knows every single chip's errata and generates final meta-code after optimization loops.
This chip errata documentation was not published, because only crew who designed that middle-ware knew about it.

Just a theory.

[jakubo]

so things that HW devs "said" were actually not documented so that when a new dev would start along he'd miss this info aswell?
oh dear... i fear for AMDs future...

[jakubo]

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"

[Khudsa]

That's probably a fair statement.

There are all kinds of advantages that come from designing the HW and SW together, but the downside is that you end up with some unspoken, undocumented assumptions.

Typical example -- during early design HW dev explains a particular function to SW dev on a whiteboard, explanation shows the HW getting inputs in a certain sequence. SW dev now thinks about the HW that way. When it comes time to write the code, they organize operations in the same sequence the HW dev talked about a few months earlier... not because it's the only way to do it, not because it's even the "official" way to do it, but it's what was in the HW dev's head at the time they designed the block. SW dev writes the code, it works and gets integrated into the rest of the driver stack, everyone is happy.

The only real solution for that is to write open source driver software at the same time as proprietary driver software, run it on the same simulators & emulators, and be able to talk to the HW folks about odd issues like this while everything is still fresh in their heads AND we can try to reproduce on the emulators to see what is happening inside the chip.

I know people complained a lot about us working on support for new hardware when features were still missing from older hardware, but realistically the only way for this to work is if open source drivers are written and tested alongside the rest of the engineering effort. Getting there took 5 years of really hard work from the developers (basically supporting 10 years of hardware in 5 years) and I'll take a bit of credit for getting open source drivers at least partially integrated into the top level planning efforts, but I'm hoping you'll see the benefits and understand why we did this in the future.

We were a bit too late for this to give much benefit for SI since the HW focus had already moved to the next gen even though we started months before SI launch, but (crosses fingers) hopefully that will be the last time.



Wait until it's working... then you can get one of those "I fought HyperZ and won... and so can you !!" stickers

EDIT -- tried to add "Hyper" to Captain Z-Ro's uniform ( http://www.dhark.com/CAPTAIN_Z-RO/index.html ) but it didn't work well...

Maybe the open source driver, right now not using the HW simulators because it's not wrote at same time than fglrx, can help to improve future versions of hardware because it can hit differents paths than fglrx, raising hardware bugs?

[archibald]

I think a few people might need to think about how hardware is designed and software written for it. It involves verbal discussions and conversations. The technical content of those discussions does not always make it into a formal specification. To suggest that AMD are negligent for this is to suggest that their hardware engineers should not be allowed to communicate to their software developers apart from via formal, documented methods, which is just untenable. It would be a fairly unpleasant working environment (dividing up the workforce in case some communication is not written down) and would slow down development significantly.

Yes, it's more convenient if things are documented, but as always, there's a cost involved in doing so - particularly since specifications can always be interpeted in different ways by different people (if you know of a complex spec that leaves nothing open to any kind of interpretation, please show me), and this interpretation cannot be documented (or else the interpretation documentation would need documenting...).

[smitty3268]

I think a few people might need to think about how hardware is designed and software written for it. It involves verbal discussions and conversations. The technical content of those discussions does not always make it into a formal specification. To suggest that AMD are negligent for this is to suggest that their hardware engineers should not be allowed to communicate to their software developers apart from via formal, documented methods, which is just untenable. It would be a fairly unpleasant working environment (dividing up the workforce in case some communication is not written down) and would slow down development significantly.

Yes, it's more convenient if things are documented, but as always, there's a cost involved in doing so - particularly since specifications can always be interpeted in different ways by different people (if you know of a complex spec that leaves nothing open to any kind of interpretation, please show me), and this interpretation cannot be documented (or else the interpretation documentation would need documenting...).

Yeah, and a lot of times you don't want to do the formal documentation until you've actually got something figured out and mostly working. You may have a lot of discussions and back and forth before that, when you are still creating the spec in your mind. The only possible way of getting all that recorded is if you stuck a webcam on everyone's head and recorded every single second of their work day - and i certainly wouldn't want to work in an environment like that. I'm sure AMD's employees don't either.

[bridgman]

Maybe the open source driver, right now not using the HW simulators because it's not wrote at same time than fglrx, can help to improve future versions of hardware because it can hit differents paths than fglrx, raising hardware bugs?

Yep, that's certainly possible... there are already a number of different code bases running on the hardware (drivers for multiple OSes plus several levels of diagnostics) but the open source drivers represent another fairly complex workload. Downside is that the emulators and simulators run a lot slower than real time so the amount of "real OS, real applications" testing you can do before the hardware tapes out is limited.

The only possible way of getting all that recorded is if you stuck a webcam on everyone's head and recorded every single second of their work day - and i certainly wouldn't want to work in an environment like that. I'm sure AMD's employees don't either.

Even if they could live with the recordings, I sure wouldn't want to sit through 30,000 employee-years of video to see if any of them talked about a hang that might have been related to HyperZ (even though the engineer might not have mentioned HyperZ at the time).

[bridgman]

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?

More like 7 years ago... most of the HW design would have happened around 2005. We've already asked around and are running out of people to ask. As far as we know the problem didn't show up with the proprietary driver, so there may not be a "missing link" to find.

Doesn't mean we've stopped looking, but it probably was time for Jerome to push the code he had and work on something else for a while until the next idea or hint turns up.

[halfmanhalfamazing]

Bridgman is not the one who code the driver he is a manager and his job is to communicate.

I could've swore I read somewhere that he was a software engineer, or developer, or something along those lines. But *shrug* oh well.