Announcement

Collapse
No announcement yet.

AMD's Radeon RX Announcement For E3 2016

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

  • #61
    Originally posted by bridgman View Post

    Pretty much zero awareness needed by the OS or driver, which makes it exactly like a hardware part doesn't it ? The only exception is MEC where we are still developing the compute stack and adding features to the microcode (so feature level matters, just like with HW). How is that invasion ?
    We just said to open it, not to free it for every possible use. Also I am afraid for OpenCL and C_Amp like futures, we will be able to develop similar new things, or it is forbidden to target the hardware any lower?

    Comment


    • #62
      Originally posted by artivision View Post
      We just said to open it, not to free it for every possible use.
      We may not be communicating here... we have no plans to open the microcode.

      I don't understand the distinction between "open it" and "free it for every possible use", can you help ?

      Originally posted by artivision View Post
      Also I am afraid for OpenCL and C_Amp like futures, we will be able to develop similar new things, or it is forbidden to target the hardware any lower?
      Assume you are talking about the MEC microcode here ? You can certainly develop similar new things and target the hardware at a lower level, just not by altering the microcode itself. The microcode supports a couple of different modes including a very close-to-the-metal option where queue-pipe mapping is done entirely by the driver. You'll see an example of that in the next ROC release.
      Last edited by bridgman; 06-16-2016, 12:17 PM.

      Comment


      • #63
        Michael bridgman what is the future of opencl on radeonsi?
        ​​​​​What is the relation of it and ROC or other Open GPU efforts?

        Comment


        • #64
          The clover implemention in radeonsi is moving pretty slowly right now - main focus has been getting the HSA/ROC stack solid.

          We were looking at porting clover to run on top of ROC but had the opportunity to open source our proprietary OpenCL stack instead (after porting it to ROC) so that approach is our current thinking.

          Comment


          • #65
            Originally posted by pal666 View Post
            imbecile
            Originally posted by pal666 View Post
            i think you are idiot
            Classy.

            Originally posted by pal666 View Post
            it is still modifiable even in rom, it is just harder to modify
            Originally posted by bridgman View Post
            ... which makes no sense, because you could replace the PROM with one that has different contents and you have just updated your firmware in exactly the same way as a microcode flash or filesystem update...
            Originally posted by wizard69 View Post
            Mind you you a good portion of all hardware is generated from software these days. So why doesn't the FSF demand the code to whatever high level language was used to design the chip?
            Yes, and you can change the hardwired circuits in a computer chip also if you want given the tools and enough patience. You have to draw the line somewhere, and the FSF draws the line between hardware and software. Software being the reprogrammable part, and hardware being the part that is not.

            Originally posted by wizard69 View Post
            Which makes no sense at all because code burned into PROM can have bugs also.
            What do bugs have to do with anything?

            Originally posted by bridgman View Post
            ... and in the end this is the ONLY reason for the current belief set regarding HW microcode, with no logical justification whatsoever.
            That the FSF will not be complicit in distributing proprietary software is neither surprising nor illogical to me.

            Originally posted by bridgman View Post
            Purely a matter of convenience, like people criticizing fur but not leather because old ladies are easier to harass than bikers.


            An arbitrary decision was made to hack binaries out of packaged distros, and any hardware which still works after that is arbitrarily defined as "good"... leaving us in the situation where microcode stored in a file is bad but EXACTLY THE SAME MICROCODE stored in flash is acceptable.

            Stallman and the FSF have done many good things but IMO this is not one of them.

            I really have trouble understanding why the HW microcode which runs the GDDR5 link training state machine in the memory controller ABSOLUTELY HAS TO BE OPEN but the rest of the memory controller does not.
            Originally posted by wizard69 View Post
            I really think the FSF position is asinine.
            Originally posted by wizard69 View Post
            Does that make sense to anybody?
            It doesn't make sense to you because you don't understand that the FSF has an ethical position against proprietary software (as a tool for subjugation of users). They freely admit that the ethical choice is often the less convenient or less practical one.
            But you keep on looking for practical reasons and find none, then conclude that the FSF position is asinine.

            Comment


            • #66
              I'm not saying it's asinine, just that it has what appear to be unintended consequences and on balance might actually make things worse rather than improving them.

              Comment


              • #67
                Originally posted by wizard69 View Post
                In general GPL takes away more freedom then it grants which is why I see a lot of people involved in free software moving away from GPL.
                you just didn't get that gpl grants freedom not to you(to steal), but to software

                Comment


                • #68
                  Originally posted by bridgman View Post
                  The clover implemention in radeonsi is moving pretty slowly right now - main focus has been getting the HSA/ROC stack solid.

                  We were looking at porting clover to run on top of ROC but had the opportunity to open source our proprietary OpenCL stack instead (after porting it to ROC) so that approach is our current thinking.
                  Yeah, It's mostly a question of manpower. I used to spend time working on the libclc library implementation, but parenthood got in the way of most of my free time. Jan Vesely and Tom Stellard obviously do a bit, but in general, there's no dedicated focus on what kind of goal everyone is trying to achieve, and therefore no real drive to get specific things done.

                  At least in my case, and probably Jan's, we don't have access to the CL CTS either, so we end up either having to find CL suites that have their own internal tests, or we have to write our own piglit tests before we can attempt to validate the implementation ourselves.

                  We are within spitting distance of the cppamp driver (from multicoreware) being able to run on Clover, but I haven't been able to find time to finish off the half dozen or so math builtins that need doing. i'm sure there's other similar programs out there that are almost able to work, but missing one or two key built-in functions that we just haven't gotten around to yet.

                  And at this point, if AMD opens up their full CL driver for me to build/debug, I'm ok with that.... I'll mourn the time I wasted on some software that no longer matters, but I'll get over it (and maybe spend some time going over the AMD code and trying to find some vectorization/optimization opportunities.

                  Comment


                  • #69
                    Originally posted by bridgman View Post
                    The clover implemention in radeonsi is moving pretty slowly right now - main focus has been getting the HSA/ROC stack solid.

                    We were looking at porting clover to run on top of ROC but had the opportunity to open source our proprietary OpenCL stack instead (after porting it to ROC) so that approach is our current thinking.
                    Will the ROC stack ever support 300/400 based cards?

                    Comment

                    Working...
                    X