My goal is to ensure that you as a software developer:
Use this thread to provide feedback to AMD developer outreach. I am very interested in
You can start independent threads if you want, but it's handy if all the ideas are in one place. You can provide me feedback or ideas about:
I will try to respond to any suggestion within 1 business day, but you know, I do take time off occasionally. So I won't promise. I do promise to listen. And thanks in advance for the feedback.
Hi,
I think AMD is on the right track with their technologies (HSA/hUMA have a huge potential in scientific computing), but in my opinion they lack documentation. I would have two requests to make my development flow smoother. First, I would like to have an overview on which CPUs/GPUs/APUs support which version of GCN/HSA/hUMA along with a definition of the versions capabilities. Second, an online (HTML) documentation of ACMLscript would be nice to have.
Thank you!
Excellent. I likewise am impressed by the huge potential. This is a bit of a new domain for me (my background is in developer tools and microcontrollers). The compute power this will open up is phenomenal.
In my fairly brief time here, those seem like eminently reasonable requests. I can get them into the respective teams and we’ll see what we can do. Thanks for the feedback.
Kudos - what you think we're doing well
Complaints - what you think we are not doing well
Suggestions - what new ideas or approaches might help
Thanks! I'll see all of this gets to the various engineering teams. I _THINK_ CodeXL is on about a 6 month cadence. Not sure about that, so don't hold me to it .There is a significant downside to releasing too often - you spend more time updating and getting everything to work together.
Again personal opinion, I am very fond of sample code. SO I like that idea I love it when people agree with my pets. Trying to avoid confirmation bias, but I'm of the opinion that good example code is worth its weight in gold. Anyone have thoughts on this?
I have a suggestion. I think AMD should create online class that shows how to program using OpenCL. I learned about GPU programming through online MOOC (Coursera, Introduction to Parallel Programming With CUDA - Udacity) and taking those classes were a blast and help me understand what GPU computing is all about. Unfortunately, both those classes use CUDA. I also found that using CUDA environment was much easier to get started. After I learned CUDA and GPU programming, I tried to use CodeXL and AMD SDK to learn OpenCL. However, CodeXL was constantly crashing my VS and I found it more difficult to read different books and/or documentations to get going. It would have helped if I could get all the information I need to learn OpenCL from a single place.
Creating a MOOC about OpenCL and how to use AMD tools as well as fundamental parallel algorithms will be very helpful in getting new developers to adopt AMD development tools. There is even an open source MOOC platform (Open edX) so AMD do not have to partner with coursera/udacity if AMD wants to keep it internal to maintain full control of the content.
I think the success of AMD/HSA/GPGPU depends on wide adaption by the industry and educating more people to use OpenCL will be very important in the long term. OpenCL University Kit (http://developer.amd.com/india-developer-zone/university-kit-book/) was a good attempt but I find well built MOOCs much easier to follow and beneficial. Also, OCL University Kit needs to be updated for OCL2.0 and HSA anyway.
I'm sorry that AMD will not hold developer conference this year. I assume that it has something to do with the financial hardship the company is going through. However, I think it is vital to promote and educate developers to use AMD tools and show them all the benefits of HSA/GPGPU computing can do.
I'm glad to see that AMD is starting to pay more attention to developers and community (http://developer.amd.com/community/blog/2014/11/04/what-do-you-need/). I hope to see more great things from AMD in the future.
I personally really like the idea of a MOOC devoted to GPGPU using open standards, since I have a strong training background. I suspect the boss would like this idea too, since he has an academic background. As always, no promises. This one could be a real resource issue. But I think I'm going to start beating the bushes about this.
I'm glad that you like the idea. The beauty of online class is that it is very easy to offer and update, once you have something set up. If getting enough resource is a problem, I'd suggest that you start small and build it up. Some of the classes Coursera offers (ex. Coursera.org) are just 4 weeks long and a part of a series. They call it specialization. The first class in that series is about setting up tools and development environment. If AMD offers a class on how to setup AMD tools and put all the relevant resources in a single place, I'll definitely sign up.
NVidia is offering an online course on Deep Learning.
http://www.tomshardware.com/news/free-nvidia-deep-learning-course,29630.html
I know that AMD is short on resources. But AMD should increase investments in marketing and education for developers. Posting a few blogs without a way to reproduce the result is not a good way to market technology in this day and age where research project has main repository set up in github.
What I'm missing most from AMD is current GPU drivers for laptops. Let me explain: I own a HP Pavilion dv6 laptop with Switchable Graphics. HP seems not willing to provide current graphics drivers (both for the Intel and for the AMD GPU). The problem is that the current laptop drivers AMD provides will not install on my laptop - a message comes that I'm supposed to look at the laptop producer's website.
Since I also use my laptop for development, it is very complicated for me to use all the cool ressources AMD seems to be willing to provide, since this very often requires a reasonably current Catalyst driver installed. I know that there are ugly hacks available, such as the drivers from Leshcat Labs. I'm sure AMD knows what kind of problems this causes. But on the other hand: This shows how urgently some users require decent current Catalyst drivers for their laptops (often with Switchable Graphics). Thus I believe this should be a problem that AMD is able to solve (NVidia already solved it in the past with NVidia Verde: Just accept a button that you know that you better should look for drivers at the laptop producer's website and you can install a current graphics driver that almost always works).
Perhaps this complaint/suggestion might seem a little bit off topic here. But since AMD seems to be genuily interested in what problems developers have - this is my number 1. Even if I hadn't this problem (say, because, I developed on a desktop computer with a dedicated AMD graphics card), I surely have lots of users of my software using laptops that will not be able to use my software that uses AMD's latest features, because no decent current driver is available for them.
So my Number 1 wish: Provide current drivers for laptop GPUs that can also be installed and work even if the laptop manufacturer is not willing/able to provide a current driver. NVidia solved this problem with NVidia Verde - I'm sure, you can, too. How am I supposed to develop for the cool features AMD provides if no working driver is available?
I know where to go with your feedback, so thanks!
Kudos:
Going full open source on the linux stack. Thank you so much!
6 display out cards (coupled with the linux drivers)
OpenCL performance on consumer cards (might hurt your bottom line, but it helps mine )
HSA/hUMA are both awesome developments that I'd like to use
Complaints:
What happened to Berlin!? (Opteron version of kaveri). If i could get a cheap 1U system I'd be all over this as a dev system.
Libraries and examples (OpenCL) are either non-existent or hard to find.
A lot of your resources read/play like marketing material. STOP IT!
Suggestions:
Work with someone (supermicro maybe?) to get a line of cheap, current 1U or 2U systems available.
Run a blog series on coding in openCL/HSA models and don't try to sell me an IDE/CPU/APU/GPU/etc... in line with the education.
Provide some simple, independent, libraries that make use of HSA features. Abstract them so I can use them in my network widget program or my retro respin mspaint++ program without really understanding them.
Good stuff, thanks Jon. We are a company in the business of making money, so we are going to push our own APUs and dGPUs. I'm sure you understand BUT... having said that...
I am 100% with you that developer-oriented resources do not need and should not have marketing messages. If you're reading it, you're already playing with us. I am sensitive to this personally. When I got here I saw one blog post that was really nothing more than a rehash of a press release. I find that suboptimal. So to the extent that I can, you should see that kind of stuff diminish. And if you see something specific, by all means bring it to my attention.
I can direct content development to a degree, so requests for things like a blog series or some HSA-oriented code, I may be able to have impact. As a guide for where I want to go, see the OpenCL 2 example series we're running right now.
http://developer.amd.com/community/blog/2014/10/24/opencl-2-shared-virtual-memory/
http://developer.amd.com/community/blog/2014/10/31/opencl-2-0-pipes/
There are more coming. As HSA ripens, I want to do "like that" for HSA development.
On the other items you cover, I'll get them processed.
Different levels of users need a different level insight. For example: Taking something like Blender and optimising the hell of out of it for various archs like Fusion and regular CPU + GPU combinations, on AMD platforms all be it. Then take it as a case study and walk a regular developer through various steps on improving application performance. This addresses the need for optimising something that is slightly better than a Fibonacci series based example. In other words real world application performance tuning.
It would be really cool to scour the various forums based on popular games and optimising instances of "FPS sucks" and make that a community facing initiative.
Then there are cases where the proper use of a library including strongly concurrent coding/design styles are helpful. I am a strong believer in functional style programming but I continue to use C++. I'd love to use Erlang for more than a few example games. Then there is Clojure - my favourite language on JVM stack but I focus on development productivity and not on performance. The point is these are very different goals and AMD can potentially help by making example cases on both instances.
Perhaps build an AMD specific toolchain (read: Eclipse + G++/GCC) that provides a better insight into AMD's toolchain. Oh and the profilers. Please make them really really good with GPU and CPU integrated profiling. I can name my favourite one but I don't think it would be appropriate to mention a competitor's product on this board.
Thanks! The kind of things you describe: real world (at least better than "Hello World") examples on focused areas - that really show you how to do things; tips and tricks on implementing parallel code... Yah. What I want to get created and provide for you all.
On tools... there are some efforts getting started. What I'm aware of is our contribution to the HSA developer tools. But I'll dig into general tools development, and pass this into the team. We just posted a quick reference to compiler switches for optimizing for AMD. It's at the top of this page:
http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/
Not precisely what you're talking about, but at least in the same playground.
I hold AMD high on the Skyscraper of respect.
A few good examples:
1. Blender project (I don't know if AMD contributes)
2. ASM.JS for Mozilla
3. Highly concurrent systems (Erlang like systems programming but perhaps on C++ or on the JVM)
4. Parallel/Concurrent ready standardised IDE with AMD tools integrated. Think AMD's version of Parallel Studio (TM) available across OSes much like Android Studio by Google.
Thanks for the documentation.
First, update this page: http://developer.amd.com/partners/tools-partners/apps-running-on-boinc/
There are a lot of boinc projects that use OpenCL: ATI Radeon - BOINC
And, please, if possible, give support to this developer for their scientific project....like, for example, free gpu card to test their code.
Hmmm, Thanks for the pointer. I have to do some digging on BOINC. I participate personally with my main home computer. In fact, I should set up my laptop to participate as well. This is definitely something I personally support, and maybe I can do something while wearing my AMD hat. That would be fun.
Kudos:
I really like that AMD provides public datasheets for chipsets, and engaged in coreboot development several years ago.
Complaint:
AMD's involvement with coreboot reduced a lot, and delivering open source chipset support devolved into providing binaries only ([coreboot] AMD's binary-only AGESA libraries).
Suggestions:
Instead of reducing the open source effort in firmware "because it's hard", improve internal development processes to support it. From what I see from the outside, it might even help the other, non-open source development in the chipset group.
As an aside, providing a stable URL scheme for documents would be useful. Currently with every website revamp old links become useless. Documents have IDs, and having datasheet.amd.com/by-id/12345 (to pick an arbitrary scheme as example) redirect to whatever the current location of document #12345 is would be great, because those redesigns happen rather often.
Thanks Patrick.
"providing a stable URL scheme for documents would be useful. "
I'm grinning. You know, when I got here I of course think my own way. I'd organize the web site a little differently. I decided to NOT go down that road because... what would anyone really gain? I did a little digging, and as expected, most links into developer.amd.com come from search engines and bookmarks. So if I juggle all the pieces all I do is annoy people. About my first rule is, "Don't annoy your customers." I mean I'd like to please them, but aggravating them is a certifiable BAD IDEA. (I can affect developer.amd.com directly, not the overarching amd.com site - but I can certainly make myself heard.)
Having said that, we try to do two contrary things on the developer site when we reorganize:
I will process the other feedback as well, but thought I'd share a little of the irony. And let you know that one falls on open ears for sure.
Am 06.11.2014 um 16:22 schrieb jtrudeau:
I'm grinning. You know, when I got here I of course think my own way. I'd organize the web site a little differently. I decided to NOT go down that road because... what would anyone really gain? I did a little digging, and as expected, most links into developer.amd.com come from search engines and bookmarks. So if I juggle all the pieces all I do is annoy people. About my first rule is, "Don't annoy your customers." I mean I'd like to please them, but aggravating them is a certifiable BAD IDEA. (I can affect developer.amd.com directly, not the overarching amd.com site - but I can certainly make myself heard.)
If URLs remain stable from now, that's alright. http://support.amd.com/us/Processor_TechDocs/30430.pdf is now http://support.amd.com/TechDocs/30430.pdf - so there were some who weren't as careful.
And having a single entry point into the library that figures out for me that document #30430 is on support.amd.com while #48751 is on developer.amd.com would also be useful when tracking down cross references within the datasheets. (those two docs don't have much overlap, so it's unlikely that they're referenced from the same datasheet. I just picked them from our datasheet collection as examples).
Good afternoon.
Excuse me if my problem is actually similar to one of nubok, but I am not sure if it is so.
The question is about installing of proprietary driver on notebooks with muxless Intel/AMD graphics under Linux.
Could you explain somewhere, how properly do this?
Or, if this is a problem of driver, could you fix it?
--------------------------------
The problem is that the fglrx driver cannot be properly installed on my notebook (Intel HD Graphics 4000 + AMD Radeon HD 8750M; openSUSE 13.1). Formally, it is installed, but after reboot the black screen is obtained. I searched for solution in different forums, but nothing helps. The most frequent solution is to disable AMD card and enjoy Intel. In scarce cases when people was successful it looked like "take Intel driver of version xxx, fglrx driver of version yyy and all works; if you take fglrx version zzz instead of yyy -- nothing works" However, that posts are quite old, the version yyy doesn't support my card. I asked this question in several forums, but nobody can help me. Actually, it looks like problem in fglrx drivers...
This notebook was bought mainly for OpenCL programming (under Linux). The key feature to chose it was AMD Radeon HD 8750M. But really I cannot use it for this purpose -- only Intel card is used.
I know, there is GalliumCompute SDK for open radeon driver. However, it supports GPUs up to Tahiti only, but my card is newer (Oland).
I (and, I think, a lot of people who wants to have properly working hybrid Intel/AMD graphics under Linux) would be very grateful, if you helped obtain AMD card working (and ready for OpenCL) in such systems.
The more detailed description of the problem is, for example, here: AMD Support and Game Forums - Intel HD 4000 + AMD Radeon HD 8750M + Linux.
Regards,
Natalia
P.S.
Excuse me for my English. It is not my native language.
I'm missing attention to detail in the communication from AMD to developers. A small example: when I register to this forum, I get this [0]. What is Jive and why should I care about it? What really gets me though are things like this [1], a screenshot from the OpenCL optimization guide. The table is a mess. The formatting of the documentation overall makes it hard to read, the pages (OpenCL zone) are not very clear and hard to navigate.
One more: I have been trying for over a year now to get information on how to do p2p communication between AMD devices. There is supposed to be some SDK somewhere that was supposed to be "released soon" over a year ago. I can't find it. Does it exist?
But there are also good things of course. I applaud the fact that clMath is OpenSource. Unfortunately it is somewhat a mess as well, but at least we can change it if we want to 🙂
Cheers,
Sebastian
My experience has not been good thus far. I've been working on a game port to Mac and Linux and ran into an odd rendering issue that only occurs on AMD hardware. I was referred to someone on the OpenGL team to throw an API trace and description of the issue to.. That was back in August, and in September I got an update from the AMD contact apologizing for the delay and stating it they would have some info the next day.. I still have not received any response and recent email asking for an update have been ignored.
And IMHO using forums doesn't always work, especially if a developer is working on something that can't be made public. (e.g. like our ports). So do you have another mechanism which I can send this issue over to get some resolution to? (I'm fairly certain it's something screwy with the OpenGL render engine used in the game as it's just horrid horrid horrid). Right now this issue has become a major blocker for the game port we are working on.
Can you send me (privately) some info on whom you were working with? I can contact them and see what's going on.I definitely don't like people being ignored. Click the Create item at the top of the page, and you can send me a message.
Forums are not good for private discussions, like when you're working on projects that can't be discussed in public. There are things that can happen, but typically you would work with a contact here at AMD to set something up. Let's talk about what your situation is. No promises.
Thanks for looking into this. Once you approve me as a friend I'll be able to send you a PM.. (the system won't allow me otherwise)
Done!
You asked for developer feedback, but I can't pass up the chance to get a message through to the respective driver teams. I've been speaking with at least one game dev about the Java thing, so I might as well put this here on his behalf.
1) OpenCL <-> D3D interop cost is too high. (Ex: madVR, a popular video renderer)
2) 7870 and R9 270X series of cards totally tank FPS-wise when running 64-bit Java games that use OpenGL. (Ex: Minecraft, Starsector. My thread with details: AMD Support and Game Forums - R9 270X Java FPS Stutter)
Thanks, got it. I'll get it into the teams.
Thank you for doing this. As an individual developer, I love to have someone on your side actively saying that we're listening.
Kudos:
One feature I want to mention: Virtualization. It's a part of my usual workflow to have development environments on VMs. Runs on AMD *PU just fine.
I like make -j8.
This is a pretty vague one, but I get a vibe from AMD that it's a more ethical company than its competition. It makes me happier to pick or recommend AMD.
My wishlist/complaints:
I'll add a bit of background for the this one. Despite having a day job, I have various coding projects I participate in or run on my free time. I get more room to explore new things with those. One of them is a web site, and I have rented a dedicated server from Hetzner for that.
I have an interest in HSA. I could buy a Kaveri desktop and get started with it, but all the applications I'd have in mind for that would be online. I wouldn't want to route requests from my server via my home VDSL2, but run it all in someone else's data center, on a loaned server. I don't want to own the hardware or even see it, but get the convenience of having them set it all up and give me the root password, for a reasonable monthly fee.
Could AMD work with hosting providers to make sure that servers with HSA support are available for individual developers, too? I would love to build those skills. A company deciding to go with HSA enabled servers can buy them and put them in their own racks, but it's not really an accessible option for me, on my own. And how would they even do that in the first place, unless they had someone familiar with HSA to recommend its application. Not saying that I'm necessarily in such a position, with regard to my employer.
As an extra added bonus, hosting in Europe, payable in euro. I like to keep latency at a minimum for myself.
I'd like to add a bit about open source. I'd consider apt-get install the gold standard for distributing software. Looks like you're on the right track for this with the upcoming amdgpu Linux driver model. OpenCL, HSA support, you name it, I'd prefer it to be included with my distribution, with working support without proprietary binary drivers. I'd like it if you worked to get AMD's own Linux software properly packaged for distributions. Though I'm thinking of packaging bolt myself for Debian. If I get the inspiration and can get it compiled with what OpenCL support it has.
As I see it, AMD is banking on getting people to adopt using HSA features and things like OpenCL, where they have an advantage. I'd see it as an prerequisite for getting people to buy AMD hardware with those features. But to get there, you'd need developers who have been exposed to them, and Linux distributions can be your best friends to do just that.
This one is in pure wishful thinking territory, but I can't resist the temptation to gripe, now that I'm talking. AMD is not a laptop manufacturer, but you talk to them. I still use my 2007 model of ThinkPad, and the current Lenovo lineup has just no appeal to me. Could you tell them to bring back the classic ThinkPad? With an AMD APU in it. I'd buy one. Market them as UsefulBooks or something.
PS. I hope you don't mind that I exposed this to reddit. Someone was bound to.
I have an idea I'm about to explore with a colleague on setting up a "board farm." He's in a different business here, but I think we share a common need to help our developers, and that's to provide access to platforms where they can download code, test, reboot, and so on. This would be a long way out if it ever happens, because we have to figure use cases, how to arrange time on the boards, and so on. The idea is to provide network access to a range of hardware. I've seen this done, and I think it's brilliant. You may own a development system but need to test on six other configurations for example. LIkely would start in the Americas, but you never know. I hear there's at least one developer in Europe.
I'll get the other input into the product teams. THANKS.
I really like your idea for a "Board Farm". I am currently developing my app on an HD 7700 - it would be very useful to see performance
on a newer, more powerful card such as the 290x.
Thanks for asking,
I can only make comments about my limited experience with OpenCL on GCN cards coming from CUDA.
Kudos: very good hardware that is easy to optimize for most of the time.
Issues: OpenCL compiler is not an "optimizing" one - there is no way to control or optimize register usage, so multiple times I was in a situation when a kernel compiles using 60 registers on V7 card, and 65 registers on a V6 card. This was causing occupancy difference and performance difference of 20%, that was sometimes not easy to fix, since one can only guess where the registers are being used. It should not be developer's job to hunt for these small optimizations every time he makes a change - Nvidia solves it with maxrregcount parameter. And in general it always seems like kernel uses more registers than it "should" by looking at the code.
Suggestion: if AMD is serious about GPU compute, it should make an investment into compiler and tools to make them easier to develop for.
Thanks for the feedback. I cannot confirm/discuss future roadmaps and what we may/may not do with respect to investing in tools. But this is most excellent feedback. The good news is, I know PRECISELY where to send the input on optimizing the compiler. In addition, the coming HSA tools and compiler are open source, so that should help.
Thanks again.
I'd be happy to provide a more detailed feedback and several other (smaller) issues with compiler to interested parties and spend some time iterating if needed.
Please contact me directly for this.
one of the smaller issue is function inlining - OpenCL "should" be inlining functions, but in fact when I copy/paste function code into the location, register count decreases by a few registers and perf also decreases slightly.
Hi,
Kudos:
Really love how you're pushing low level API's, even if they are still not available for public use.
Quite easy to get 50% or so device utilization in OpenCL.
Complaints:
Nigh impossible to go over 50%: Register usage! Already mentioned before but it's really painful to tune performance when the compiler goes "It's better to save 4 clocks on recomputing this value than use one register less and thus increase occupancy!". A good register rematerialization pass which would take the device occupancy into account is a must! Even if the HSA compiler is going to be opensource the backend which does register allocation for GCN is probably going to be closed, so we cannot do this ourselves.
Linux drivers. They always require kernel/Xorg around 9 months old. It's absolutely impossible to keep up to date. Your biggest competition on GPU arena is not perfect but still far far better. And with great Linux drivers they were able to push new GPU on Android as it actually uses the same driver stack as their desktop Linux drivers. If you ever want to go into mobile space you really need to get this thing fixed. I mean seriously. Plug in a GCN based GPU into your new fancy ARM based CPU's and voila, you have an Android Tablet SOC! Also whereas your competition Linux drivers are around 20% faster in OpenGL than their Windows drivers (Due to no WDDM hampering it) your Linux drivers are maybe 20% slower than the Windows drivers.
In addition to use OpenCL you must have X running, which is kinda ridiculous. How can you tell to a customer that if they spend few millions on a massive FirePro cluster that they have to have X server on?
Suggestions:
Employ one or two engineers full time to work on just keeping your Linux drivers up to date. It seems currently it's a separate project, as in "Implement support for latest Ubuntu" and then completely abandoned until new iteration of $popular_distro comes out. It's relatively low intensity work so you could have a working driver out few days after new kernel/xorg release.
Focus on Ocl 2.0 really hard. To get to par with current CUDA one really must have dynamic parallelism and the work_group_reduce/broadcast functions in shape using the GCN register shuffles internally.
Captured. Thanks for taking the time. I'm still gathering info, but about to start seeding the various developer teams with this feedback.
Hi,
Kudos: The quality of the drivers and OpenCL support increased in the last years and there is at least some documentation available!
-- NaN
Hi,
here is something quick and easy: on the ACML download page, the userguide linked there is still for version 5.3, yet with the versions >=6.0 an updated userguide is part of the download; could the updated userguide also be linked on the download page? Also, on the matter of the ACML userguide, it would be helpful if the pdf would contain (hyper-) links ie for the table of contents or other references.
Thank you
Yeah, that should have already happened. I think we noticed that a week or two ago. Thanks for applying the boot. Let me go ping the people responsible. Kinda fell off my radar after I alerted them to the problem.