"Ask ATI" dev thread

[Mr_Ed]

Now, the (my) focus here is if the compositing window manager (in my case: compiz-fusion) is responsible for the blur ability or the driver.

According to what I read in this thread, the compositing manager should be because the current ATI driver should be mature enough to handle this feature.

I already filed a bug for this in the past:https://bugzilla.redhat.com/show_bug.cgi?id=479443

But this bug was closed by the bug maintainer with the following comment:

"Thanks for the report. We are sorry that we cannot help you with your problem, but we are not able to support binary-only drivers. If you would be able to reproduce this issue using only open source software, please, reopen this bug with the additional information, but in meantime I have no choice than to close
this bug as CANTFIX (because we really cannot fix it)."

To me, as a simple user, this feels like no-one is going to solve this.

[NeoBrain]

Blur windows _broke_ somewhere about 8.46. At that point, transparent windows got darkened instead of getting their background blurred. Focus blur seemed to work though IIRC.
Lateron, I guess about 8.11, blur still didn't work, but now it just didn't change anything about the window or its background. Turning on the plugin had the same effect as leaving it disabled (i.e. neither focus nor alpha blur worked).

About the usefullness of blurring transparent windows: It's quite practical in that way, that you can see if something changes in the "lower" windows (e.g. a new chat message) but at the same time the transparency doesn't make reading the text in the topmost window any harder.

[Mr_Ed]

I just tried the open source driver.

When I enable blur in compiz, it makes the windows lag like hell, moving a window takes about 5 seconds and traces of the background keep being visible in the window border after moving a window. Switching between windows (alt-tab) idem ditto. Everything works slow.

1. The "4xBilinear" blur does work.

2. Mipmap make the window borders dissapear.

2. Gaussian doesn't blur at all. And is slow too.

Google-Earth doesnt work with the open source driver.

When DPMS mode is enabled and the screen goes to sleep it will not wake up from it anymore.

Pretty much everything else I do with this driver is al least 50% slower then with the fglrx driver.

i.e. Watching a video on discovery it hicks like hell.

[bridgman]

I already filed a bug for this in the past:https://bugzilla.redhat.com/show_bug.cgi?id=479443

But this bug was closed by the bug maintainer with the following comment:

"Thanks for the report. We are sorry that we cannot help you with your problem, but we are not able to support binary-only drivers. If you would be able to reproduce this issue using only open source software, please, reopen this bug with the additional information, but in meantime I have no choice than to close
this bug as CANTFIX (because we really cannot fix it)."

To me, as a simple user, this feels like no-one is going to solve this.

For an fglrx bug, the place to file is http://ati.cchtml.com. Distros can fix bugs in open source drivers but not binary drivers, as they said.

If we're talking about the Compiz blur effect, I think there is already a ticket open on the fglrx tracker; at least now I know what it's talking about

[bridgman]

When I enable blur in compiz, it makes the windows lag like hell, moving a window takes about 5 seconds and traces of the background keep being visible in the window border after moving a window. Switching between windows (alt-tab) idem ditto. Everything works slow.

Sounds like the blur is being done in software, which would be very slow. If it's a GL 2.0 function being used in blur that would make sense; the open drivers should pick up GL 2.0 support once Gallium3D is up and running (Gallium3D was integrated into mesa master recently, which is *great* news).

For the other apps it also sounds like they are taking SW fallbacks; there's a way to disable that but I don't remember the details.

I need to talk to the Google folks; Google is such a big advocate of open source but it seems like they only test their apps on binary drivers, not open source

I'm not sure what the latest problem with Google Earth is; will ask around.

Pretty much everything else I do with this driver is al least 50% slower then with the fglrx driver.

i.e. Watching a video on discovery it hicks like hell.

Is that a flash video or something ? I would expect video playback to be faster on the open drivers than on fglrx these days; this should be fixable today.

[Mr_Ed]

Is that a flash video or something ? I would expect video playback to be faster on the open drivers than on fglrx these days; this should be fixable today.

Flash!

And I also tried the Adobe hack by creating /etc/adobe/mms.cfg and adding a line:

OverrideGPUValidation=true

in it.

[Mr_Ed]

Here my hw specs: http://www.smolts.org/client/show/pu...b-a6d4365840ca

[Mr_Ed]

I cannot get TV-in working with the open source driver.

I tried several options:

(**) RADEON(0): Option "RageTheatreCrystal" "2950"
(**) RADEON(0): Option "RageTheatreTunerPort" "0"
(**) RADEON(0): Option "RageTheatreCompositePort" "2"
(**) RADEON(0): Option "RageTheatreSVideoPort" "6"
(**) RADEON(0): Option "TunerType" "0"
(**) RADEON(0): Option "RageTheatreMicrocPath" "/usr/lib/xorg/modules/multimedia/ativmc20.cod"
(**) RADEON(0): Option "RageTheatreMicrocType" "BINARY"
(**) RADEON(0): Option "DefaultConnectorTable" "on"
(**) RADEON(0): Option "TVStandard" "PAL"

But the only output I get in xorg.log:

(II) Module exa: vendor="X.Org Foundation"
compiled for 1.5.3, module version = 2.4.0
ABI class: X.Org Video Driver, version 4.1
(**) RADEON(0): Rage Theatre Crystal frequency was specified as 29.50 Mhz
(**) RADEON(0): Rage Theatre tuner port was specified as 0
(**) RADEON(0): Rage Theatre composite port was specified as 2
(**) RADEON(0): Rage Theatre SVideo Port was specified as 6
(**) RADEON(0): Tuner type was specified as 0
(**) RADEON(0): Rage Theatre Microcode path was specified as /usr/lib/xorg/modules/multimedia/ativmc20.cod
(**) RADEON(0): Rage Theatre Microcode type was specified as BINARY
(==) RADEON(0): Assuming overlay scaler buffer width is 1920
(II) RADEON(0): Cannot access BIOS or it is not valid.
If your card is TV-in capable you will need to specify options RageTheatreCrystal, RageTheatreTunerPort,
RageTheatreSVideoPort and TunerType in /etc/X11/xorg.conf.
(!!) RADEON(0): For information on using the multimedia capabilities
of this adapter, please see http://gatos.sf.net.

With previous versions of the driver it was no problem.

Can somebody help me?

[Mr_Ed]

opengl screensaver hangs/crashes system with xorg-x11-drv-ati-6.10.0-2.fc10.i386

https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/106060

I changed my settings from gnome-screensaver-preferences using gconf-editor.
I was using "blocktube" as the preferred screensaver and changed that.

Now, when I start gnome-screensaver-preferences in a terminal I see:

** (gnome-screensaver-preferences:3698): DEBUG: Found best visual for GL: 0x21

[leidola]

AMD OpenCL roadmap, brook+

Hello!

Is there a time frame, in which we can expect OpenCL from AMD? I mean some kind of roadmap? I'd like to start with GPGPU programming and wonder if I'd start with brook+ or wait for OpenCL. Or use cuda, as it is said to be similar to OpenCL -- I need a new GPU anyways, but I'd prefer to stick to AMD. According to the AMD homepage there will be a migration way to OpenCL when it is ready. Does anybody know about it?

By the way, NVidia has presented this roadmap:

http://www.geeks3d.com/?p=2582&lang=de

Thanks for your help,

Olaf