Catalyst 8.9 breaks MPlayer GL-Renderer

[LoRd_MuldeR]

It seems the new Cataylst 8.9 drivers break MPlayer's GL renderer :mad:

I just updated the drivers for my X1950 card and now I only see a "green" screen when using MPlayer with "gl" renderer.
It seems the "force-pbo" sub-option doesn't work anymore. Without that option I see the video again, but performance is unbearable.
The "directx" renderer gives dreadful performance for HD content too, so I might have to downgrade...

Can anybody confirm? Any ideas?

:confused:

[qyqgpower]

New Features
Catalyst™ 8.9 introduces the following new features:

• Catalyst™ Control Center: New Display mode support

• OverDrive™ support for QUAD CrossFireX configurations

• OpenGL™ 3.0 extension support

maybe this is what caused your issue

[LoRd_MuldeR]

Maybe. I really hate ATI drivers. When they implement one new feature, they break two old ones at the same time :(

I really hope the MPlayer team is still willing to workaround ATI diver bugs and will find a solution...

[ChronoReverse]

Same trouble here. The default mode works though for now =/

[LoRd_MuldeR]

Same trouble here. The default mode works though for now =/

Without "force-pbo" sub-option the gl renderer becomes useless (more or less), because performance drops to the ground :o

[ChronoReverse]

No, I meant default renderer. The GL mode is made completely useless by the new drivers.

[LoRd_MuldeR]

No, I meant default renderer. The GL mode is made completely useless by the new drivers.

Here the "gl" renderer still works, but only without the "force-pbo" sub-option.

The "directx" (default) renderer also works, but performance for HD content is dreadful. It used to run 100% smooth with "gl:fore-pbo:ati-hack" :rolleyes:

[ChronoReverse]

Ugh. I know, that's what I meant and understood about what you said already. I said the GL mode is completely useless because force-pbo doesn't work and the normal mode is slow (as usual).

As for the default renderer, I'm able to playback the 1080p trailers from Apple smoothly with an A64 x2 3800+. Not sure how that compares.

[LoRd_MuldeR]

So we agree on that :)

If I try to play one of these 1080p trailers with "directx" renderer I get jerky motion. Not even close to the smooth look of "gl:force-pbo:ati-hack" with previous Catalyst :(
Also the scaling quality for SD content on my 1680x1050 screen is much worse with "directx" renderer (compared to "gl:force-pbo:ati-hack:lscale=5")

[ChronoReverse]

I wonder why it is then. Your specs are WAY higher than mine. Could it be that you're running Vista (32 bit or 64 bit?)and I'm running XP?

[LoRd_MuldeR]

I wonder why it is then. Your specs are WAY higher than mine. Could it be that you're running Vista (32 bit or 64 bit?)and I'm running XP?

I'm not running Vista. I'm running WindowsXP x64-Edition ;)

I think it might be because of my Radeon X1950 card, which is not very powerful compared to the Radeon-HD-3000/4000 series...

[ChronoReverse]

Why would that matter with software decoding and rendering? Besides, I have a 3400...

[LoRd_MuldeR]

Why would that matter with software decoding and rendering? Besides, I have a 3400...

The "directx" renderer actually uses "Overlay" video. On WindowsXP the overlay video uses hardware-only scaling, on Vista it's emulated in software...

[Reimar]

I just updated the drivers for my X1950 card and now I only see a "green" screen when using MPlayer with "gl" renderer.


Does someone have contacts with ATI that are not only "drones"?
Since they break it all the time, MPlayer should be a good test case for their QA department (well, I have some doubts they have one).
I do not know if I will try to work around it, since I can not use gl on Linux at all with ATI drivers, going to fullscreen completely corrupts the screen with the 8.8 drivers, and remains corrupted (including the parts of the screen MPlayer does not draw to e.g. after switching back to windowed) until you exit MPlayer.

[Reimar]

their QA department (well, I have some doubts they have one).

Let me extend that their web page does not seem to have any either. All their developer links result in a server error. Though I appreciate that they let me know they use SharePoint and which version of ASP.NET. Well, at least their web admins finally found out they had been selling a product called "HD 4800" already for a few months.
I'll now try to suppress my rants for the future, I fear I have made my opinion too clear already.

[LoRd_MuldeR]

Thanks for your reply, Reimar!

Just for the notes: The "OpenGL" renderer in VLC Player still works fine with Catalyst 8.9 and plays smooth for HD content.
So if you are willing to workaround ATI's drivers once again (which I hope), this could be a starting point...

[blizard]

I played around with these setting in SMPlayer (gl:force-pbo:ati-hack) and 1080p Madagascar 2 trailer from Apple.com. It seem that neither SMPlayer, MPC+FFDSHOW (both from K-Lite Mega v. 4.1.7) or VLC manage 0.8.6i Janus do very well with on my system with the older version of ATI Catalyst driver 8.6 for my X1950XT video card.

Looking on Process Explorer bar for each CPU load it show me that there should be some room as mainly one core was working while playing trailer in SMPlayer with GL driver set as above. When I set to MPC+FFDSHOW and Haali splitter it showed that both CPU core where under load, but still same problem with increasing sound out of sync and jerky image in some places. VLC did not solve this problem while set in directx mode, so it looks like there is something that cause 1080p video to not decode very well on my system. Playing 720p on my machine is no problem what so ever.

First question would be if of the choice of splitter could have something to do with there problem in SMPlayer? Using MPC internal mov splitter and filter seem to run a lot better, but still have some trouble to keep up in a smooth play of trailer.


I use Mulders last build of SMPlayer right now.

[Reimar]

I played around with these setting in SMPlayer (gl:force-pbo:ati-hack)

You should be using e.g. yuv=2 in addition to that.
And did those with trouble with the 8.9 drivers also try "-vo gl -dr" ?
Even if it does not work, it should be fixable if performance is right.

[LoRd_MuldeR]

And did those with trouble with the 8.9 drivers also try "-vo gl -dr" ?


"-vo gl -dr" gives black image
"-vo gl:force-pbo:ati-hack -dr" gives green image
"-vo gl:force-pbo:ati-hack" gives green image
"-vo gl" gives proper image, but performance is unbearable

[ChronoReverse]

I wonder what mplayer does that's so weird with OpenGL. Rendering 3D isn't a problem with other OGL applications.

[LoRd_MuldeR]

I wonder what mplayer does that's so weird with OpenGL. Rendering 3D isn't a problem with other OGL applications.

MPlayer uses OpenGL for Video output, not for rendering 3D graphics. Not weird, but maybe not the most common usage of OpenGL...

[ChronoReverse]

I realize that much. The point is that rendering to a texture in OGL ultimately isn't anything special and mplayer having a hard with it is unusual.

[LoRd_MuldeR]

I realize that much. The point is that rendering to a texture in OGL ultimately isn't anything special and mplayer having a hard with it is unusual.

Doing the color-format conversion properly, implementing different scaling methods and supporting subtitles/OSD might not be that easy though...

Also a texture size of 1920x1080, which changes 30 times per second, is pretty unusual, isn't it ???

[Reimar]

I wonder what mplayer does that's so weird with OpenGL. Rendering 3D isn't a problem with other OGL applications.

It updates part of a texture from a buffer where the width is not a power of two, a case that ATI seems not to have optimized at all.
Optimizing it manually by using PBOs seems to hit a completely untested case, too.
So my guess is: ATI is stuck in a time where textures always had dimensions of a power of two and were always transferred completely and in addition texture transfer speed was not that critical. Which may work fine for most games but is the complete opposite of what MPlayer needs, and any workaround will cost performance (and thus has to be ATI-specific).

[clsid]

What about dividing a frame into multiple textures of sizes that are a power of 2? Or would that hurt performance more than it would gain?

[Reimar]

What about dividing a frame into multiple textures of sizes that are a power of 2? Or would that hurt performance more than it would gain?

gl2 does something like that (though only if larger textures are not supported). It is a pain to work with and breaks any advanced filtering/scaling.
I can't really see why VLC is supposed to have no such problems, they do not do anything special.
Things would be much easier if there was a 8.9 driver for Linux, I am missing tools left and right (esp. good profiling tools).
glGetError does not show any problems, though the speed IMO is a clear sign the driver is hitting some error case.
I now try to use ATI's GPUPerfStudio, but it does not work on XP x64. Server 2003 seems not even supported for the drivers, but I'll see if it works anyway.
And people say installing stuff on Linux is a pain...

[LoRd_MuldeR]

Good news, you are investigating it :)

[Reimar]

Ok, I can now tell you what MPlayer does differently: It uses ALPHA and LUMINANCE texture data.
For the RGB case (without yuv=...) that is easy to avoid (only used to initialize the texture, not exactly a good sign that this breaks performance also for later texture uploads) and I did that in MPlayer SVN r27653, so performance should again be the same as VLC in that mode now.
For YV12 and OSD support that is not really possible to avoid though, so performance is still bad in these cases.
Btw. the ATI drivers indeed seem not to work for Windows Server 2003. Well, more precisely only 2D support works...

[LoRd_MuldeR]

What if the YUV -> RGB conversion is done in software, so the GL renderer only has to handle RGB data? Too much performance killer ???

[SledgeHammer_999]

Does someone have contacts with ATI that are not only "drones"?
Since they break it all the time, MPlayer should be a good test case for their QA department (well, I have some doubts they have one).
I do not know if I will try to work around it, since I can not use gl on Linux at all with ATI drivers, going to fullscreen completely corrupts the screen with the 8.8 drivers, and remains corrupted (including the parts of the screen MPlayer does not draw to e.g. after switching back to windowed) until you exit MPlayer.

The "checkerboard" issue is fixed in the 8.9 drivers for Linux!(at last)

[Reimar]

The "checkerboard" issue is fixed in the 8.9 drivers for Linux!(at last)

Yay, so instead of unusable for MPlayer fullscreen they are now unusable for MPlayer in general. Not my idea of "progress".


What if the YUV -> RGB conversion is done in software, so the GL renderer only has to handle RGB data? Too much performance killer ???


As said, that is what you get with just -vo gl. Performance is acceptable after my fix/workaround but not good and none of the advanced filters/scalers are available.

[LoRd_MuldeR]

As said, that is what you get with just -vo gl. Performance is acceptable after my fix/workaround but not good and none of the advanced filters/scalers are available.

Hmmmm, I see...

Any chance for a workaround that works like that what "force-pbo" did on pre-8.9 Catalyst drivers? Or is that impossible with recent Catalyst?

(I don't really understand what "force-pbo" did do at all, because my knowledge about OpenGL is near zero)

[rvm]

As said, that is what you get with just -vo gl. Performance is acceptable after my fix/workaround but not good and none of the advanced filters/scalers are available.

I've just tested svn r27667 on linux and it seems now gl is even capable of playing HD (720p) videos :). gl2 can't.

[LoRd_MuldeR]

I've just tested svn r27667 on linux and it seems now gl is even capable of playing HD (720p) videos :). gl2 can't.

I don't know if this is a news for Linux, but on Win32 the gl renderer used to work for HD (720p and 1080p) just fine -- until damn ATI broke it :rolleyes:

[rvm]

Well, in my system gl could play HD videos but with the force-pbo:ati-hack options. Now it works even without those options.

[LoRd_MuldeR]

Well, in my system gl could play HD videos but with the force-pbo:ati-hack options. Now it works even without those options.

On my system "gl" alone plays with horrible performance, no chance to play HD content. And "gl:ati-hack:force-pbo" shows green screen with latest catalyst :mad:
But "force-pbo" used to work perfectly fine with older Catalyst drivers. I got 100% smooth playback for 1080p stuff at that time.

That is with MPlayer build r27323. Didn't have a chance to test a newer build yet...

[rvm]

I compiled r27666 and r27667 (one with mingw and the other with cygwin, as it seems mingw builds are not working very well):

http://sourceforge.net/project/showfiles.php?group_id=185512&package_id=254677&release_id=628845

They were compiled on a Windows XP running on virtual machine in linux, so I haven't tested myself how gl works on a real computer yet.

[LoRd_MuldeR]

It tried your r27666 build and I can confirm that "-vo gl" works good with that build. I can play 1080p content in a smooth way :)

However SMPlayer disables seeking with that build for some reason, so I cannot actually use that build. And idea why that is?

[rvm]

However SMPlayer disables seeking with that build for some reason, so I cannot actually use that build. And idea why that is?

At least with the few videos I tried, seeking worked.

[LoRd_MuldeR]

The seekbar in SMPlayer is grayed out all the time with your r27666 build :o

EDIT: I just tried again and now it suddenly works. I didn't change anything. Strange :confused:

[rvm]

The seekbar (along with the buttons in the control bar) is usually disabled if smplayer can't detect that mplayer has started to play, for instance if the option -quiet is passed to mplayer. Do you have something in the mplayer config file?

[LoRd_MuldeR]

I edited my previous post. Don't know why, but it works now.

However the "gl" renderer works now much better than with my previous build, but still not as fast as gl:force-pbo used to work :(
Some of my 1080p videos, that played 100% smooth before, are still stuttering...

[Reimar]

However the "gl" renderer works now much better than with my previous build, but still not as fast as gl:force-pbo used to work :(


Hm, not as fast as "gl:force-pbo" or do you mean not as fast as "gl:yuv=2:force-pbo"? The difference to the first should be really minor, whereas the later one means that the CPU does not have to do YUV->RGB and has to transfer only half the amount of data to the graphics card.
I currently have the feeling that "gl:yuv=2:force-pbo" working at all with ATI cards was a bug that they now fixed, seems like luminance-only/grayscale textures are not really supported by ATI's OpenGL - unfortunately, contrary to NVidia I was unable to find any documentation on what they _do_ support...

[LoRd_MuldeR]

I used to use "gl:force-pbo:ati-hack" and it was able to play all my 1080p trailers and stuff 100% smooth on older Catalyst drivers.
In fact I didn't really know what "yuv=2" was supposed to do and I couldn't see much difference...

How can removing support for a certain type of texture that was supported in the past be "fixing" a bug? :eek: