Announcement

Collapse
No announcement yet.

It's Going To Take More Time To Get Vega Compute Support With The Mainline Kernel

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

  • bridgman
    replied
    Originally posted by uentity View Post
    Just a little question: when 18.10 is planned to be released to the public?
    Thought I already responded to this, sorry - some time around late March / early April.

    Leave a comment:


  • bridgman
    replied
    Originally posted by Meteorhead View Post
    There must be some misunderstanding here. The fact that there is DRM and AMDKFD, one kernel hook that the Mesa drivers use and another that AMD uses solely for compute workloads immediately means that having graphics-compute interop is going to be a no go on AMD hardware in the near future, when all remnants of fglrx (inside AMDGPU-PRO) have been rooted out.

    Having a uniform hook, as is the case on Windows with WDDM, it is much easier to issue drivers that can do both. Perhaps bridgman can shed some light onto this case.
    I don't understand your comment - we have been supporting compute/graphics interop using KFD for a while in embedded engagements.

    Graphics and HSA/ROC/KFD compute use different addressing models anyways. CPU and GPU address spaces are distinct for graphics (and for compute running over amdgpu) but common for KFD compute so you need an API call to map from one to the other, but that's not a problem.
    Last edited by bridgman; 02-08-2018, 02:22 PM.

    Leave a comment:


  • Meteorhead
    replied
    Originally posted by schmidtbag View Post
    As far as I'm aware, having a "uniform place" would not improve anything. If anything, it would slow down development, since you have to consider regressions and following a single release schedule rather than multiple independent ones.
    There must be some misunderstanding here. The fact that there is DRM and AMDKFD, one kernel hook that the Mesa drivers use and another that AMD uses solely for compute workloads immediately means that having graphics-compute interop is going to be a no go on AMD hardware in the near future, when all remnants of fglrx (inside AMDGPU-PRO) have been rooted out.

    Having a uniform hook, as is the case on Windows with WDDM, it is much easier to issue drivers that can do both. Perhaps bridgman can shed some light onto this case.

    Leave a comment:


  • coder
    replied
    Originally posted by duby229 View Post
    Wow, there's a whole lot of clueless people in this thread.
    This is not a helpful comment.

    Leave a comment:


  • uentity
    replied
    Originally posted by bridgman View Post

    We are working on a separate solution for OpenCL without PCIE atomics - with a bit of luck it will hit the next (18.10) release.
    I already git this insight info from this issue from ROCm project github, but thanks for double confirming this!
    Just a little question: when 18.10 is planned to be released to the public?

    Leave a comment:


  • duby229
    replied
    Wow, there's a whole lot of clueless people in this thread.

    Leave a comment:


  • clintar
    replied
    Originally posted by bridgman View Post

    Pretty simple... we have been re-doing the Linux stack from bottom to top, rebuilding it around open source components, and so not all of the areas are going to get finished at the same time.

    In 2016 we finished the kernel driver transition from fglrx to amdgpu open/PRO. In 2017 we got the major userspace graphics tasks finished (although open source Vulkan took longer than we hoped), and first part of 2018 should see similar progress on reconciling compute.
    So based on how much longer than you thought to implement these, how far out do you think vulkan support will REALLY take?

    Leave a comment:


  • pcxmac
    replied
    Originally posted by ThoreauHD View Post
    What a bunch of lazy assholes. What are people supposed to do with AMD on Linux? They've sold out of every damned GPU and chip they got. You'd think they could bother to hire more than 1 developer without a fucking timeline. This is bordering on operational negligence.
    Just keep this in mind, AMD can't just turn around and order a whole bunch of chips from a fab, there are many months involved in that process, reservations, tooling, etc... It requires a lot of time for a turn around, that is why its going to take INTEL at least a year to address their security issues, given how far out they design and run their business. AMD has a long lead time on it's profit margins, given the way the market is moving, it's a risky game, and they need more funds to pump out more siliicon so they can profit and THEN hire developers. It will be a while before AMD can 'afford' to support open source in a more meaningful way. Now NVIDIA, their margins are ridiculous, and they only offer a pittance of what AMD does, and they make so much more, that's ridiculous IMO. AMD is behind the ball, and it takes a long time to catch up in this industry, especially if you don't control a fab (several) like INTEL does.

    Leave a comment:


  • bridgman
    replied
    Originally posted by uentity View Post
    Just a little question: when 18.10 is planned to be released?
    Late March IIRC.

    Leave a comment:


  • bridgman
    replied
    Originally posted by StillStuckOnSI View Post
    A quick question, if I may: does "reconciling compute" include support for OpenCL and/or ROCM support on GCN 1.0 cards (without using fglrx and pre-4.0 kernels)?
    We can't really extend ROCM any further back without changing the programming and delivery models, since it is based on having at least a core set of HSA hardware features, but the OpenCL support should be able to go further back. That said, it will still depend on amdgpu support for SI, which is still rough in places.

    Leave a comment:

Working...
X