Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 53

Thread: HyperZ: Errata & The Catalyst Command Stream

  1. #31

    Default

    Quote Originally Posted by bridgman View Post
    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/

    Quote Originally Posted by bridgman View Post
    Auggh !! My eyes !!!
    Another talent from me: psycho hypnosis by pictures LOL...
    Last edited by maldorordiscord; 07-14-2012 at 09:36 PM.

  2. #32
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by glisse View Post
    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.

  3. #33
    Join Date
    Jul 2009
    Posts
    260

    Default

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

  4. #34
    Join Date
    Jul 2009
    Posts
    260

    Default

    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"

  5. #35
    Join Date
    Oct 2009
    Posts
    131

    Default

    Quote Originally Posted by bridgman View Post
    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?

  6. #36
    Join Date
    Jul 2010
    Posts
    449

    Default

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

  7. #37
    Join Date
    Oct 2008
    Posts
    3,176

    Default

    Quote Originally Posted by archibald View Post
    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.

  8. #38
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by Khudsa View Post
    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.

    Quote Originally Posted by smitty3268 View Post
    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).
    Last edited by bridgman; 07-15-2012 at 05:28 PM.

  9. #39
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote 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?
    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.
    Last edited by bridgman; 07-15-2012 at 05:35 PM.

  10. #40

    Default

    Quote Originally Posted by maldorordiscord View Post
    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.

Posting Permissions

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