Announcement

Collapse
No announcement yet.

Bridgman Is No Longer "The AMD Open-Source Guy"

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

  • darkbasic
    replied
    I still have to understand why f@h takes 100% of my cpu with the opencl client (HD5870) while it takes nearly 0% on nvidia with cuda.

    Leave a comment:


  • mdk777
    replied
    Switched from CAL to OpenCL last year.


    Hence my hope that the new GNC would continue to function.

    Again, thanks for your interest and insight.

    Leave a comment:


  • bridgman
    replied
    Actually the VLIW core is the older one (Cayman and previous). Compiler issues there (whatever they might be) wouldn't affect work on the newer cores, would it ?

    EDIT -- hmm... a quick skim of the F@H site suggests that the client is going in at the CAL level (essentially assembler) rather than OpenCL. If true, and if the IL has been optimized for VLIW GPUs, that would explain why the GCN performance isn't scaling the way it usually does. Will ask Mike.
    Last edited by bridgman; 22 September 2012, 07:38 PM.

    Leave a comment:


  • mdk777
    replied
    so I would not expect them to think that code paths optimized for a VLIW core would also be optimal for a scalar core.

    Reply With Quote Reply With Quote
    The assertion is that the delay in optimization is due to the lack of working compiler from AMD for the VLIW core.

    Perhaps it is all CYA. As, I mentioned, just looking for an inside perspective. I am just an educated end user.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by tstrunk View Post
    The scientific community still swears by CUDA, because nvidia dumped a lot of marketing effort into the science community.
    I don't think that it's the marketing. The main reasons are:

    1) CUDA was there first, years ago, and they have lots of CUDA code around that would take quite an effort to convert to OpenCL
    2) CUDA has a set of very nice, very fast libraries. OpenCL is more bare-bones. Even finding a good FFT is tricky -- there is the Apple one, but it is not as complete as the Nvidia one, and it's full of OSX-isms. If you know a good, drop-in FFT for OpenCL, let me know. This will improve with time, but once again, CUDA has a head start here.

    Many people choose to use OpenCL for new projects, but CUDA is already well entrenched in many places.

    Leave a comment:


  • bridgman
    replied
    Originally posted by mdk777 View Post
    The difference is attributed by the programers to a lack of robust drivers compilers on the part of AMD...ie. the functions supported on the previous compiler stack are not now supported/optimized to run on the new open source stack.
    I'm surprised by that conclusion. The FAH team has always maintained differently optimized code paths for different hardware architectures (eg NVidia vs ATI/AMD) so I would not expect them to think that code paths optimized for a VLIW core would also be optimal for a scalar core.

    Leave a comment:


  • mdk777
    replied
    Yes, going from a 6850 to a 7970 yields a 3x improvement in Luxmark V2.0 running on open cl 1.2

    However, FAH yields a negative, ie. a 7970 does not work as well as the 6850. Running the same (open version) Opencl program.

    The difference is attributed by the programers to a lack of robust drivers compilers on the part of AMD...ie. the functions supported on the previous compiler stack are not now supported/optimized to run on the new open source stack.

    FAH cores themselves are not open source. Mike Houston could give you some insight as he was actively participating at one time.

    But thanks for responding even though you have no immediate experience with the issue.

    Best regards,
    Last edited by mdk777; 22 September 2012, 06:24 PM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by mdk777 View Post
    This first point in Bridgeman's post is what I was talking about.

    These steps made code optimized for the previous architecture run like crap on the new.
    I don't understand. I was talking about a new shader compiler for the new architecture in the open source graphics stack. You seem to be talking about proprietary OpenCL.

    Leave a comment:


  • mdk777
    replied
    1. Moving to a new shader architecture (GCN), new memory management (GPUVM) and new shader compiler (llvm) at the same time. This was kind-of necessary but it meant that we had far more work in process where you couldn't see an obvious benefit. Using llvm was partly to build a good foundation for an open source OpenCL stack, and partly to get a more capable shader compiler into the graphics stack.

    This first point in Bridgeman's post is what I was talking about.

    These steps made code optimized for the previous architecture run like crap on the new.

    While your experience:

    This is not true from my experience. Back in the Stream SDK < 2.4 days there were always some bugs encountered, but OpenCL is fully supported now.
    May be true of some software, for others the deficit can run in 70-90%.

    I understand that HSA will benefit from eliminating the PCIE bus and associated legacy.

    However, it will be difficult to develop a software ecosystem when you can't model a integrated GPU on the start of the art discrete card (AMD 7970 performing worse than a AMD 6850)

    Anyway, I didn't come to complain, just asking how they see the SDK development, if they are achieving their goals.

    Leave a comment:


  • Khudsa
    replied
    Thanks Bridgman for all your work, patience and reponses on this forum.

    Tim, good luck in your new work!

    Leave a comment:

Working...
X