Announcement

Collapse
No announcement yet.

Radeon's ROCm OpenCL Runtime Finally Open-Sourced

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

  • dungeon
    replied
    Originally posted by smitty3268 View Post

    The thing is, dungeon doesn't care about it. He uses the proprietary drivers anyway. This whole thing was just him trying to start a flamewar for whatever reason. I guess no good news can go without someone trying to shit all over it.
    How is that flamewar:

    1. someone posted a link...
    2. so, i read it...
    3. spotted something in my POV incorrect...
    4. sort of false advertising so i reported it

    https://www.phoronix.com/forums/foru...424#post951424

    And then someone else comment on that, without knowing maybe or reading anything from GNU/FSF sites at all to at least learn a bit what is their stance on this...

    With that in mine head Free/Libre is nowhere Yes, but more like Free/Libre No(blb fw req)
    Last edited by dungeon; 15 May 2017, 05:42 AM.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by bridgman View Post

    ... and harder to maintain.

    When we announced the Radeon Pro SSG products my first thought was "hey we can put microcode images on the SSD...".

    My second thought was "... and then watch everyone scramble to redefine the rules again".
    Does this microcode contain card-specific quirks? If so, who's going to be adding those for cards no longer sold or under warranty? Or is the general idea that it's easier to put the quirks inside the driver?

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Zucca View Post
    @bridgman: I don't belong to any church or worship any gods, but I'll say this: Amen.

    I guess some people are satisfied only after manufacturers put a flash chip on to the card, load firmware from there and call it a day. In the end it's the same thing as now, but more expensive to produce.
    The thing is, dungeon doesn't care about it. He uses the proprietary drivers anyway. This whole thing was just him trying to start a flamewar for whatever reason. I guess no good news can go without someone trying to shit all over it.

    Personally, I feel like the UVD (video decode acceleration) firmware actually is high level enough to count as part of the driver software - but it's obvious why it's done that way, to allow them to keep their DRM stuff secret. The rest of the firmware, which is enough to run all the 3D acceleration bits, seems fine and on the hardware side of things to me.
    Last edited by smitty3268; 15 May 2017, 01:56 AM.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by bridgman View Post
    All the driver does is...
    ...nothing without the hardware, which in turn needs the microcode.

    Leave a comment:


  • RussianNeuroMancer
    replied
    Radeon reverse engineering tools. Contribute to fail0verflow/radeon-tools development by creating an account on GitHub.


    People who want to see Radeon microcode content, what are you waiting for?

    Leave a comment:


  • bridgman
    replied
    Originally posted by Zucca View Post
    I guess some people are satisfied only after manufacturers put a flash chip on to the card, load firmware from there and call it a day. In the end it's the same thing as now, but more expensive to produce.
    ... and harder to maintain.

    When we announced the Radeon Pro SSG products my first thought was "hey we can put microcode images on the SSD...".

    My second thought was "... and then watch everyone scramble to redefine the rules again".

    Leave a comment:


  • bridgman
    replied
    Originally posted by artivision View Post
    Clarification for children: If something is loaded on the CPU and exist inside the CPU RAM or Cache, then is just the opposite from that you said.
    So children get stricter rules. For adults the usual rule is "if something is executed by the CPU" not "if data is processed or copied by the CPU".

    I don't have a problem with more stringent data standards for children, although GPU microcode would probably not be my first priority.

    Originally posted by artivision View Post
    If it can be replaced with driver code, then it is also the opposite from that you said. Basically if it is general code or can be general code, then you do something not very good.
    The microcode can not be replaced by driver code, other than the subset of the MEC microcode handling HW scheduling and for that we provide an open source alternative in amdkfd. We don't even try to work around the microcode during early bringup of emulated or real silicon, except to the extent that the hardware can run without microcode (eg you can run without SMU microcode but locked to low clocks, and you can run without UVD/VCE microcode if you are only using the 3D engine).

    There are exceptions but in general the microcode controls hardware at a deeper level than what we expose via CPU-accessible registers.

    Originally posted by artivision View Post
    If it is necessary and real HW code then you are ok.
    It is necessary and real HW code.
    Last edited by bridgman; 14 May 2017, 02:40 PM.

    Leave a comment:


  • Zucca
    replied
    @bridgman: I don't belong to any church or worship any gods, but I'll say this: Amen.

    I guess some people are satisfied only after manufacturers put a flash chip on to the card, load firmware from there and call it a day. In the end it's the same thing as now, but more expensive to produce.

    Leave a comment:


  • artivision
    replied
    Originally posted by bridgman View Post
    Time for the usual reminder - the drivers work just fine without microcode images and do not rely on them in any way, it's the hardware that needs microcode to operate (since the microcode is part of the hardware design).

    All the driver does is load the microcode images into the chip at power-on and generate an error message if something goes wrong (so you know why the hardware isn't working).
    Clarification for children: If something is loaded on the CPU and exist inside the CPU RAM or Cache, then is just the opposite from that you said. If it is loaded on the GPU and exists only inside the GPU RAM or Cache, then it is exactly what you said. If it can be replaced with driver code, then it is also the opposite from that you said. Basically if it is general code or can be general code, then you do something not very good. If it is necessary and real HW code then you are ok.

    Leave a comment:


  • bridgman
    replied
    Time for the usual reminder - the drivers work just fine without microcode images and do not rely on them in any way, it's the hardware that needs microcode to operate (since the microcode is part of the hardware design).

    All the driver does is load the microcode images into the chip at power-on and generate an error message if something goes wrong (so you know why the hardware isn't working).

    Leave a comment:

Working...
X