If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

AMD Puts Out A Beta Catalyst Linux Driver For The Public

Phoronix: AMD Puts Out A Beta Catalyst Linux Driver For The Public

While NVIDIA puts out beta Linux graphics drivers quite often as a means of soliciting testing prior to declaring a new stable GPU driver update, AMD does not but rather they rely upon their NDA-covered select beta testers to put each Catalyst release through its paces before declaring a stable update in their timed monthly manner. Today though it seems AMD has put out a Catalyst Beta driver that's targeting their workstation customers (those with the FirePro / FireGL / FireMV hardware) but as in their usual unified manner, it will work with any supported Radeon (R600+ GPU) as well...

Another thing still there is if you un-fullscreen SMPlayer you still get corruption on the desktop. Grabbing a window and dragging it round the screen the corruption is fixed due to the repainting effect.

Yep driver still causes tearing here. Also some other annoying bugs that are present in 10.12 also present in this one. Looks like the same pile of crap as 10.12, just with an "Unsupported hardware" logo planted on it.

O.K. In the video playback department, if you use GL for output you can get V-Synced playback from VLC and SMPlayer.

From other's reports this was previously working only if you had a single monitor and as I had three I had to suffer the jitters and tears (as in video tearing, not tears from the eyes. Though it could bring some to tears I guess ). Now, yay, at last I can now playback video in tear free goodness. Now to configure Totem to use GL playback.

....But even though GL Vsync is set to force on in Catalyst Control Center and Compiz is set to V-Sync on, it still tears like a b_stard when moving windows around. This is the less important area for frame locked video out of the two though I guess, so I consider this a slight win.

Another thing it still does it when starting video playback via VLC or SMPlayer the monitor connected to the display port goes to black for about a second and then comes back. It's like when the playback software is grabbing a display context or something the driver probes that status of the port which throws the DP->DVI adaptor.

When starting a video from VLC the screen goes black and then comes back. If you pause playback and then re-start it you don't get the "to black" crap happening. If you stop the video playback and then hit play, you get another dose of blackness.

Now when starting a video from SMPlayer the screen goes black and then comes back. Pausing playback and then restarting it you don't get more blackness. When stopping playback and hitting play again, no blackness.

That's not the driver you are waiting for. You can certainly use gl output with mplayer but for vlc the cpu usage was way too high with it. vlc can only use xv in a half optimal way - even with xvba/libva the cpu usage is really high complared to mplayer.

That's not the driver you are waiting for. You can certainly use gl output with mplayer but for vlc the cpu usage was way too high with it. vlc can only use xv in a half optimal way - even with xvba/libva the cpu usage is really high complared to mplayer.