Announcement

Collapse
No announcement yet.

Radeon ROCm 3.5 Released With New Features But Still No Navi Support

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

  • Originally posted by Aeder View Post
    Why does this sound to me like they are aiming for the datacenter while gaining 0 traction among devs? Is there some information I'm missing?
    Their current strategy seems to be using their HiP CUDA-workalike API + code translation tools to help people port existing CUDA codebases. Remains to be seen how successful that will be, but it represents a departure from their OpenCL-centric strategy they had until a few years ago.

    This leaves Intel as the lone OpenCL holdout - the last one truly embracing it as a central pillar of their GPU compute strategy.

    Comment


    • Well, datacenters would bring a lot more money and developer attention to ROCm. Having a stable ROCm to keep developing an OpenCL layer on top of isn't a bad idea IMHO.

      Besides, it's better to get Vega really stable first and then move on to Navi. The Navi support probably isn't official because it's not that stable yet. For instance, DaVinci Studio has a hard dependency on OpenCL and works fine through ROCm on my Polaris card, but on my Navi card I get graphical corruption and after clicking any UI element I get an application crash.

      Comment


      • Originally posted by Djhg2000 View Post
        Well, datacenters would bring a lot more money and developer attention to ROCm. Having a stable ROCm to keep developing an OpenCL layer on top of isn't a bad idea IMHO.
        This isn't a bad idea but still SPIR-V is not supported. This lack of supporting a common intermediate language runtime is forcing the maintainance of different SYCL runtimes for each available backend, i.e. SPIR-V, CUDA/PTX & Rocm. Doesn't seem effective.

        Comment


        • Originally posted by bridgman View Post

          Hawaii (gfx7) had an early version of MEC with a fixed microcode store in the MEC block, while the later gfx8 parts could support larger microcode images by executing directly out of VRAM via an instruction cache. I had not heard about Hawaii support being broken until today but will take a look. It was always a challenge to fit even stripped-down ROCm functionality into the fixed microcode store so it's possible that we just outgrew it.
          Support of gfx7 in ROCm would very valuable for those people with S8150 and similar cards. These GPUs are quite capable and with HIP support they could be very efficient for many.
          E.g. see https://github.com/RadeonOpenCompute...ment-647033796

          Comment

          Working...
          X