Ubuntu 17.04 and Polaris 11 GPU cannot run MATLAB/PTB

1

Hi,


I've recently bought a new workstation for PTB with a Radeon Pro WX 4100 GPU. I installed Ubuntu 17.04 and although everything else seems to work fine, MATLAB cannot use hardware acceleration for OpenGL (low-level graphics error). I tried updating to the latest stable kernel (4.12) and tried both the Padoka stable and cutting edge MESA drivers just in case it helped (it didn't). I cannot install the closed source Radeon drivers because they don't support the 4.10 kernel in Ubuntu 17.04.


Has any one had any luck using Polaris (GCN 4th) cards under Linux and can they share any tips? I'd rather use the open-source drivers (I think Mario prefers them anyway?). I'll revert to the older Ubuntu if I know it will help.


Ian

2
What is "a low level graphics error"? Be specific, there can't be too much information. Does Octave work? Do other graphics apps work, e.g., glxgears, the "hello world" of OpenGL apps?
-mario
3
Dear Mario, before I saw your reply I tried to follow the Mathworks advice to use the AMDPRO drivers, this involved downgrading to Ubuntu 16.10 and making sure to NOT update the kernel or X. I installed 17.30 of the AMDPRO drivers and now MATLAB works great, 2D and 3D speed in bench() is the fastest I've seen and 3D transparent figures draw and update quickly.

BUT there is a conflict with PTB. Rather than spam the forums with log dumps, I've made a bug on github:


Ian
4
XX---In PSYCHTOOLBOX@yahoogroups.com, <iandol@...> wrote :

Dear Mario, before I saw your reply I tried to follow the Mathworks advice to use the AMDPRO drivers, this involved downgrading to Ubuntu 16.10 and making sure to NOT update the kernel or X. I installed 17.30 of the AMDPRO drivers and now MATLAB works great, 2D and 3D speed in bench() is the fastest I've seen and 3D transparent figures draw and update quickly.

--> THAT was their advice?!?!? How incompetent and irresponsible can one be and still sell very expensive, and at the same time badly engineered products to customers???

I told you already the graphics drivers were not at fault *at all*. This is clearly a Matlab bug, caused by intentional refusal of Mathworks to do the job you are paying them to do, to save them a few bucks on quality assurance. The same bug btw. causes various problems on macOS and Windows as well, since many years, just in other areas than failure of the graphics drivers. Apparently Mathworks just doesn't care about proper software engineering in some areas. I guess as long as the money flows...

If you had installed the matlab-support package as adviced it would probably have fixed it, by the operating system doing the job Mathworks engineering should have done many years ago.

Now you use a proprietary graphics driver with known limitations on an operating system version that has reached its end-of-life a couple of weeks ago and will not receive any software updates or security updates anymore, and thereby leave you more vulnerable to attacks.

The amdgpu-pro 17.30 driver is a substantial improvement over the previous versions, as i worked with the developers of the open-source part of the driver at AMD to get most issues fixed, partially by me developing bug fixes and improvements and them accepting them into the new driver release, partially be them swiftly fixing problems. It's so pleasant to work with developers that actually care about the quality of their products, instead of most proprietary software vendors. Almost everytime i have to deal with proprietary software vendors, i can't eat as much as i want to puke.

The three remaining known bugs, mostly in the proprietary OpenGL library, have been internally reported to the relevant team inside AMD, but when those will finally get fixed is out of my control:

- 1 bug is in the open-source component, and that one will resolve itself, once the amdgpu-pro driver supports Linux kernel 4.10. It is already resolved for Linux 4.9, so downgrading to kernel 4.9 would have been a much better idea than downgrading to Ubuntu 16.10. I assume AMD will update their drivers soon, but if not, i can fix that bug with a simple workaround in a PTB release.

- 2 bugs are in the proprietary OpenGL library, whose use is almost never necessary, unless you listen to the idiotic advice from Mathworks. One bug causes a PTB-Warning about broken swap scheduling, which is mostly inconsequential in practice, apart from the scary warning, as PTB can work around the issues. The fallback code path could cause more missed flip deadlines under demanding system workloads though - still not as bad as any typical Windows or macOS system though. The other more serious bug will cause random occasional hard crashes of Matlab or Octave during calls to Screen 'OpenWindow' or when closing an onscreen window. Nothing we could do about it, apart from hoping for a fix by AMD's proprietary OpenGL team. They know about the bug, but apparently it wasn't affecting enough users of the pro driver to be a high priority to fix for the 17.30 release. So obviously save all experiment date before closing the onscreen window if you want to continue to follow Mathworks dumb advice.

BUT there is a conflict with PTB. Rather than spam the forums with log dumps, I've made a bug on github:

yeah, the missing glut library. Installing from Neurodebian automatically takes care of all dependencies. For a fully manual install via DownloadPsychtoolbox, this is what our installer tells you:

"* The OpenGL utility toolkit GLUT: glut, glut-3 or freeglut are typical provider packages in most Linux distributions."

My bet would be on a package called freeglut or similar.

The only reason to use parts of the amdgpu-pro driver on a current Linux system is if you want to use some special displays which only the pro low-level display driver can handle perfectly at the moment, e.g., some very high refresh rate monitors in the >= 144 Hz range (BenQ Zowie, and some ASUS ROQ PG models with defective monitor firmware come to mind).

The other reason is if you wanted to use the brand-new AMD VEGA gpu's, who afaik go into sale today.

In both cases there isn't any need to install the full driver with the proprietary OpenGL library, regardless what Mathworks incompetent "customer support" may tell you. One way to get the good low-level open-source bits of the pro driver without the problematic proprietary high level component is to install this kernel package with a suitable enhanced Linux 4.12 kernel provided for Ubuntu by Phoronix


-mario



Ian
5
-> That's up to you. If you think you need the extra latest features or another performance boost? 

As long as there are no bugs fixed in the newer MESA that affect PTB I really would also rather be conservative. I was quite surprised that the Uniengine Valley (1920x1080 at medium settings) benchmark gives no more than 23FPS on the MESA that comes with Ubuntu, that goes up to ~43 with MESA 17.1. But I doubt this type of benchmark is indicative of any performance difference for PTB? I've tested using my object-oriented stimulus groups and everything works quickly enough at the moment.

 -> Also, as an update, AMD released a new amdgpu-pro-17.30 version yesterday, in sync with the launch of their new Vega consumer graphics cards. This one is fully compatible with Ubuntu 16.04.3-LTS, kernel 4.10, X-Server 1.19 and should (unofficially!) also work with Ubuntu 17.04, as the fully upgraded display stack of 16.04.3 (with all the *hwe-16.04* packages installed) and 17.04 is identical.

OK, that is good to know. As my previous Linux setp was using an NVidia Quadro card I naively assumed that the closed source driver would be better for AMD too. Your XOrgConfCreator is awesome, and though I didn't use it in the end for the Nvidia machine, it works great on the AMD GPU.

 -> But as said before, i can't think of a single reason to use the proprietary OpenGL library in the first place.

Your recommendation to use the open source drivers is more than good enough for me. I will probably make a wiki page with some of this information, I know recommendations may change but because you are clear that AMD + Linux provides the best support for PTB needs, knowing the options for how to configure the myriad options you can take to get graphics to work may help others...

 -> But then, with a Polaris gpu, none of this really matters for you, unless you hit some real limitation, e.g., with special display devices.

We just bought a couple of Display++ so the next step is getting the 10bit output from the AMD working reliably when the monitors arrive. I already run all my experiments with normalised 0 - 1 range and Floating32bit settings, so I this wont slow things down much. 

Ian

6
XXX---In PSYCHTOOLBOX@yahoogroups.com, <iandol@...> wrote :

-> That's up to you. If you think you need the extra latest features or another performance boost? 

As long as there are no bugs fixed in the newer MESA that affect PTB I really would also rather be

-> None that i am aware of, or their fixes would likely show up here:


I'm almost ready to submit some improvements hopefully for the next Mesa release, but these are for higher color precision on Intel gfx.

conservative. I was quite surprised that the Uniengine Valley (1920x1080 at medium settings) benchmark gives no more than 23FPS on the MESA that comes with Ubuntu, that goes up to ~43 with MESA 17.1. But I doubt this type of benchmark is indicative of any performance difference for PTB? I've tested using my object-oriented stimulus groups and everything works quickly enough at the moment.

-> Mesa reached full OpenGL 4.5 compliance on many modern gpu's a while ago, so a lot of work is invested atm. into performance optimizations. Valve is very involved in pushing the open-source graphics drivers for AAA gaming and VR, and has hired or contracted a couple of top people, so things seem to develop nicely lately in the performance area, at least for Intel and AMD. But it likely mostly doesn't affect PTB performance that much. While PTB uses the same functionality as high end games in some areas, the way we use it is often quite different. And the typical workloads for typical visual stimuli are way less demanding of the driver than what a AAA video game or benchmark does. E.g., most visual stimuli are very homogeneous, e.g., lots of dots, or lots of lines, or lots of gabors or other blobs or some images, maybe a few different shaders at most. Maybe some relatively simple 3d rendering, using a limited set of textures or shaders per frame. It's rare to use possibly hundreds of different shaders or textures or parameter sets per rendered frame, as a complex video game would do for photo-realistic graphics. The key concept is gpu state changes, causing driver overhead on the cpu, which are typically way less frequent for vision science stuff than for AAA gaming. OpenGL 4.x and the new Vulkan api are mostly meant to reduce driver/app overhead or to allow to use as many cpu cores as possible, but most of this stuff doesn't apply to PTB, or couldn't be used that efficiently without our users first taking some intense high performance graphics programming courses first and then designing their experiments around gpu's.

 -> Also, as an update, AMD released a new amdgpu-pro-17.30 version yesterday, in sync with the launch of their new Vega consumer graphics cards. This one is fully compatible with Ubuntu 16.04.3-LTS, kernel 4.10, X-Server 1.19 and should (unofficially!) also work with Ubuntu 17.04, as the fully upgraded display stack of 16.04.3 (with all the *hwe-16.04* packages installed) and 17.04 is identical.

OK, that is good to know. As my previous Linux setp was using an NVidia Quadro card I naively assumed that the closed source driver would be better for AMD too. Your XOrgConfCreator is awesome, and though I didn't use it in the end for the Nvidia machine, it works great on the AMD GPU.

-> There's no absolute "better". It's a high dimensional space of different axis to measure against, not a scalar, so "better" always depends on your specific needs. The drivers being open-source is a huge advantage for quality, for testing/diagnosing/working around/fixing bugs, and for the ability to improve them in areas where they need improvements for special applications like vision science, but your typical gpu vendor wouldn't care about an economically utterly irrelevant 0.01% niche market. Apart from that, functionality-wise the oss drivers are now on par in many relevant areas with the proprietary ones for most modern gpu's, and performance wise they are catching up as well. The main exception is NVidia. Intel and AMD invest a lot into the open-source drivers, with sizable and growing teams of full time open-source developers. NVidia is mostly indifferent and not very helpful at best for desktop gpu's, for the latest gen gpu's they are making the job of the oss developers much more difficult. That's why the open-source nouveau driver is only useable for older gpu's as far as speed/performance is concerned, and behind in other areas due to lack of support by NVidia and way less man power on the OSS side than on Intel or AMD. That's why i tend to recommend to avoid NVidia cards for vision science applications, unless you depend on some very specific features, maybe some GPGPU computing tasks which are more efficient with CUDA instead of OpenCL? I don't know. Their drivers work well most of the time, but if they don't do what you want, you are almost as helpless as on Windows.
 -> But as said before, i can't think of a single reason to use the proprietary OpenGL library in the first place.

Your recommendation to use the open source drivers is more than good enough for me. I will probably make a wiki page with some of this information, I know recommendations may change but because you are clear that AMD + Linux provides the best support for PTB needs, knowing the options for how to configure the myriad options you can take to get graphics to work may help others...

-> But please on the PTB Wiki or rebular webpage (via fork + edit + pull-request), so information doesn't get diluted over the internet.

 -> But then, with a Polaris gpu, none of this really matters for you, unless you hit some real limitation, e.g., with special display devices.

We just bought a couple of Display++ so the next step is getting the 10bit output from the AMD working reliably when the monitors arrive. I already run all my experiments with normalised 0 - 1 range and Floating32bit settings, so I this wont slow things down much. 

-> I assume the Display++ works the same way as a Bits#, so you won't use the 10 bit output of the AMD card, but the 14 bit modes of PTB for Bits+/Bits# devices, ie. the Mono++, Mono++Overlay and Color++ PsychImaging tasks.

-mario

Ian