Ubuntu

(Needs radeon-rewrite) 3D stuff breaks with Compiz: Redirected Direct Rendering is needed in DRI

Reported by Alexander Jones on 2007-03-27
446
This bug affects 28 people
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
High
xf86-video-ati
Invalid
Undecided
Unassigned
xf86-video-intel
Invalid
Undecided
Unassigned
xorg-server (Ubuntu)
Wishlist
Unassigned
xserver-xorg-video-ati (Ubuntu)
High
Unassigned
xserver-xorg-video-intel (Ubuntu)
Medium
Unassigned
xserver-xorg-video-nouveau (Ubuntu)
Wishlist
Unassigned

Bug Description

If I run glxgears or anything that uses 3D while running Compiz, it's pretty obvious that the graphics hardware is just rendering straight on top of the screen rather than to a window.

In windowed mode, the rendering stays always on top, and moving a window causes a stale rendering to be left behind.

In fullscreen mode, windows underneath cause a flickering effect.

This is on R350/radeon hardware.

ProblemType: Bug
Architecture: i386
Date: Tue Mar 27 15:57:27 2007
DistroRelease: Ubuntu 7.04
Uname: Linux flash 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux

-----
Issues with Composite and 3D are widely reported and show themselves in a variety of contexts, but all are derived from the same root problem. 3D apps wish to do direct rendering in order to maximize performance, but Compiz wishes to retain control over how all windows are painted and doesn't work well when apps are rendering directly. Thus, what's needed is a method to redirect these directly rendering apps. Redirected direct rendering is nicely described in this blog post:

http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html

The general effect is that when Compiz is active, running a 3D app like glxgears will show rendering errors when moving the glxgears window or putting it behind or over other windows. The standard workaround is to disable compiz while using the 3D programs and re-enable it when done.

This is a general problem in X's core architecture, and not an issue particular to a given driver. It's not exactly Compiz's fault either, and unfortunately it lacks a mechanism to hide or work around the problem. Solving it requires modification of a number of components including adding the TTM memory manager to libdrm, modifications of DRI in X, and on and on. It represents a significant amount of work to be done upstream and will probably take on the order of a year or two to get everything sorted out.

Created an attachment (id=7494)
Screenshot fo problem

This screenshot shows glxgears running behind Konsole with xcompmgr running,
but this happens with other composite managers as well and with other OpenGL
programs such as screensavers.

Created an attachment (id=7495)
Xorg Configuration File

Created an attachment (id=7496)
Xorg log

If I run glxgears or anything that uses 3D while running Compiz, it's pretty obvious that the graphics hardware is just rendering straight on top of the screen rather than to a window.

In windowed mode, the rendering stays always on top, and moving a window causes a stale rendering to be left behind.

In fullscreen mode, windows underneath cause a flickering effect.

This is on R350/radeon hardware.

ProblemType: Bug
Architecture: i386
Date: Tue Mar 27 15:57:27 2007
DistroRelease: Ubuntu 7.04
Uname: Linux flash 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux

Alexander Jones (alex-weej) wrote :
Alexander Jones (alex-weej) wrote :

This is still affecting 7.04.

Why does EVERYONE ELSE with this EXACT chip not have this problem. Is it actually a driver problem? I've read reports of people being able to run Beryl with no problem on this chip. How do I prove this is a Hardware fault so Toshiba will fix it?

(In reply to comment #5)
> Why does EVERYONE ELSE with this EXACT chip not have this problem.

How did you get that impression? Everybody should have the same problem under the same circumstances.

> Is it actually a driver problem?

It's more complicated than that, see comment #4.

> I've read reports of people being able to run Beryl with no problem on this
> chip.

I can only guess based on this little information, but maybe they're using Xgl.

> How do I prove this is a Hardware fault

It probably isn't.

It seems that indirect rendering is failing.

Bryce Harrington (bryce) wrote :

Hi Alex, thanks for reporting this bug.

Can you attach your /etc/X11/xorg.conf and /var/log/Xorg.0.log files?

Changed in xserver-xorg-video-ati:
status: Unconfirmed → Needs Info

I have the same problem on my laptop (incidentally also a Toshiba M100). I never noticed it until I stumbled across this bug report and checked for myself.

Is there any work currently to have it fixed? Or is the fix still being merely discussed...

(In reply to comment #8)
> Is there any work currently to have it fixed? Or is the fix still being merely
> discussed...

There is work going on here, but the scope of this is a lot bigger than your average bug fix. We need to rework the interaction and interface between the kernel drm, the X server and the 3D DRI drivers. We're probably talking man-years of work here, so you'll have to wait a little longer :) Michels roadmap mentioned in comment 4 gives an idea of the changes we're looking at.

Subject: 3D Windows plugin in Compiz Fusion:
Problem: Windows are breaking when they are in more than 1 viewport

This plugin was working perfectly in Beryl but in Compiz Fusion I having a problem as shown in screenshot.

I know that many of the things are in progress but just for your information

Alexander Jones (alex-weej) wrote :

s800human, this is not the same bug. Please file it elsewhere! Thanks.

AJ (s800human) wrote :

I forgot to mention that this problem arise when the window is lifted above from cube using this 3D plugin.

AJ (s800human) wrote :

Ok. Sorry Alex. I just read the title.

Alexander Jones (alex-weej) wrote :
Alexander Jones (alex-weej) wrote :
Alexander Jones (alex-weej) wrote :

Attached

Changed in xserver-xorg-video-ati:
status: Incomplete → New

*** Bug 6283 has been marked as a duplicate of this bug. ***

*** Bug 1208 has been marked as a duplicate of this bug. ***

I'm in gusty now, with ati 6.7.194 and I have the same problem of the screenshot

a similar (but not identic) thing happens when playing videos: when I move the window, the video becomes black (and when activating the scale plugin the window is black too, and returns with content only after having finished the scale animation)

glxgears + scale instead leaves the 3d output where the window was

Changed in xserver-xorg-video-ati:
status: New → Confirmed

Any progress? This bug is over a year old. I bought a laptop with an intel graphics chip because I wanted to use a free software driver but obviously that was a mistake. Next time I'll go with an NVIDIA chip. The drivers may be proprietary but at least their stuff WORKS! It's nearly 2008, I should be able to have nice effects on my computer. KDE 4 is coming out soon and I won't be able to use it to it's full potential because this is BROKEN!

It's your decision to make: don't let us stop you.

Joseph, there's been lots of progress on this front, but the final bits haven't been released yet afaik, though Kristian may have more details on what's available for testing etc.

Isn't there any kind of workaround for this? I don't care much for performance on the particular machine where this problem occurs, but it would be nice if toys like Google Earth or Celestia would have usable menus. Any idea?

(In reply to comment #15)
> Isn't there any kind of workaround for this?

Unfortunately not - the only way to get correct compositing is to properly redirect the rendering.

*** Bug 14034 has been marked as a duplicate of this bug. ***

I would be interested in amd64 testing, when something's available.

I'm having the same problem on my desktop.
Q965 Integrated Graphics Controller (rev 02) --> Intel® GMA 3000

It will likely affect my eeepc also.

thx

e

This is a general issue with the current infrastructure. Upstream is working on this, so maybe for Hardy+1 or 2 we'll have working redirected direct rendering in place.

Changed in xserver-xorg-video-ati:
importance: Undecided → Wishlist
Bryce Harrington (bryce) on 2008-02-20
description: updated
Bryce Harrington (bryce) on 2008-02-20
Changed in xorg-server:
milestone: none → later
status: Confirmed → Triaged

After installing Hardy Beta on a friend's PC this suddenly works without a flaw, but he's using the "new card" nvidia driver. However, when I tried it at home on my Intel GMA945 laptop I still had this bug.

Of course, this does not only affect glxgears but also more productive apps like stellarium and celestia who aren't usable at all.
So my question is, IF this is a problem with the current infrastructure, why does it work with the nvidia driver? Makes me think it's more driver related....

Timo Aaltonen (tjaalton) wrote :

This bug affects the opensource drivers.

Sven Lamers (mrfuji) wrote :

Uh, sure... Ok, my bad. Sorry :)

Indeed, the only setup for which this works is with NVidia cards and
their proprietary driver. (I am still astonished this is default
behaviour.)

The same here. I can upload a vid for everyone who cannot imagine it yet :-)

Oliver Mattos (omattos) wrote :

On some systems this "bug" causes flickering as both compiz and the 3d app are writing to the same bit of framebuffer even when there are no 3d effects going on, making the 3d app unusable. This also occurs in fullscreen mode where there is really no need for compiz to be touching the framebuffer at all.

The most visible effect of this is that most of the included screensavers flicker, the included 3d games are unusable, and apps like google earth or opengl toolkits are pretty hard to use.

Since this bug looks like it'll take quite a few releases to fix, could a little app be written to detect that a 3d app is running and turn composite off. when the 3d app quits it can restart composite? (thats what Windows does for legacy apps that communicate directly with the graphics hardware)

Alexander Jones (alex-weej) wrote :

Oliver, I'm not sure it's that bad -- "Un-direct fullscreen windows" should be enabled by default. i.e. full screen windows should draw directly to the framebuffer. Check your Compiz configuration if you've messed with it.

My advice, however, is if your driver doesn't support indirect 3D (that is, any driver other than proprietary nvidia), disable Compiz. It's really not worth the grief.

  • unnamed Edit (1.3 KiB, text/html; charset=ISO-8859-1)

yep, but remember a good 30% of users use non nvidia cards. This needs to
be detected more intelligently. Maybe compiz should not be enabled by
default for non-nvidia cards until this problem is fixed.

On Thu, Apr 24, 2008 at 8:01 PM, Alexander Jones <email address hidden> wrote:

> Oliver, I'm not sure it's that bad -- "Un-direct fullscreen windows"
> should be enabled by default. i.e. full screen windows should draw
> directly to the framebuffer. Check your Compiz configuration if you've
> messed with it.
>
> My advice, however, is if your driver doesn't support indirect 3D (that
> is, any driver other than proprietary nvidia), disable Compiz. It's
> really not worth the grief.
>
> --
> 3D stuff breaks with Compiz: Redirected Direct Rendering is needed in DRI
> https://bugs.launchpad.net/bugs/96991
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Bryce Harrington (bryce) on 2008-05-14
Changed in xorg-server:
milestone: later → intrepid-alpha-5
Changed in xorg-server:
status: Unknown → Confirmed
Changed in xorg-server:
status: Confirmed → Fix Released
Bryce Harrington (bryce) on 2008-07-18
Changed in xorg-server:
milestone: intrepid-alpha-5 → later
Changed in xorg-server:
status: Triaged → Fix Released
Bryce Harrington (bryce) on 2009-02-26
Changed in xserver-xorg-video-ati:
importance: Undecided → High
status: New → Triaged
Changed in xserver-xorg-video-intel:
status: New → In Progress
Changed in xserver-xorg-video-nouveau:
importance: Undecided → High
status: New → Triaged
Changed in xf86-video-ati:
status: New → Invalid
Changed in xserver-xorg-video-intel:
status: New → Invalid
39 comments hidden view all 119 comments

Yes, I'm in UXA and I can play 3d games with no more problmes

nouveau is still quite immature, and 3D is completely unsupported, so lowering importance due to that.

Changed in xserver-xorg-video-nouveau:
importance: High → Wishlist

 affects ubuntu/xserver-xorg-video-nouveau
 status wontfix

The nouveau drivers in Ubuntu offer absolutely no 3d support; this bug
doesn't really apply to them at the moment.

The upstream nouveau development does have some 3d support for some
cards, but this is aggressively unsupported - it is known to be
incomplete, and the best that can be expected is for it to run
undemanding 3d apps until VRAM is exhausted. Upstream does not want to
hear about problems with 3D unless there is a patch attached which fixes
them!

By the time nouveau's 3D support is worth shipping, it will support DRI2
- the initial work is already there.

Changed in xserver-xorg-video-nouveau:
status: Triaged → Won't Fix

I can confirm that this is fixed int ubuntu jaunty alpha5 by enabling dri2 and uxa. Thank you very much.

This is fixed for the intel driver int jaunty by enabling dri2 and uxa.

Bryce Harrington (bryce) on 2009-05-06
tags: added: 3d
tags: added: compiz
Julien Olivier (julo) wrote :

Marti Schaaf wrote: "This is fixed for the intel driver int jaunty by enabling dri2 and uxa."

I don't have a xorf.conf file, so I guess worg is auto-configured. If dri2 and uxa are needed to fix this bug, would it be made so that they are activated by default when not using any xorg.conf ?

Also, I'd like to test it, so how can I enable dri2 and uxa easily ?

Thanks for your help.

On Wed, May 6, 2009 at 12:56 PM, Julien Olivier <email address hidden> wrote:

> Also, I'd like to test it, so how can I enable dri2 and uxa easily ?

Easiest way is to add

 Option "AccelMethod" "UXA"

in your Device section in the /etc/X11/xorg.conf file.

--
thanks for letting me change the magnetic patterns on your hard disk.

Create an xorg.conf
sudo dexconf -o /etc/X11/xorg.conf
and then edit that.

And no, they are not enabled by default because they're experimental and on
some Intel graphics chips they make X crash.

Thanks for the information Mckenzie and David.

So, I managed to enable UXA and DRI2 and now OpenGL apps work flawlessly (even if way slower) in fullscreen mode with compiz enabled.

However, the bug with videos disappearing when moved/resized is still there.

Hi t fix all these things I updated xserver-xorg-video-intel to version 2.7 and put this in /etc/X11/xorg.conf:
Section "Device"
 Identifier "Configured Video Device"
 Option "UseFBDev" "true"
 Option "AccelMethod" "UXA"
EndSection

(It could be done with sudo gedit /etc/X11/xorg.conf)

Follow this page to get instructions how to install latest version of intel driver from x-updates: https://launchpad.net/~ubuntu-x-swat/+archive/x-updates

The latest version of intel video driver fixes many, many many things!!!

perfomance is really enhanced (test it with glxgears for example)

Many issues with video like glxgears, googleearth, compiz, and things like that are fixed!!

I suggested this version of driver should be default driver for Jaunty and others but somebody rejected my opinion and said to me "if you want to get latest driver install it from x-updates"

Then I'm trying to resolve this myself.

If you want to enable compiz in Jaunty you can do it adding this SKIP_CHECKS=yes
 to one of these files:

~/.config/compiz/compizconfig/config
~/.config/compiz/compiz-manager

I added the line to both files because I'm not sure wich one is correct in Ubuntu, but at least it is working really great than before!

Pablo Estigarribia (pablodav) wrote :

Look this screen is working with xserver-xorg-video-intel 2.7 and UXA, It's amazing! It never was possible for me before!

Robert Persson (ireneshusband) wrote :

Synaptic complains that it can't find the key for the x-updates repository. I have in fact successfully installed the correct key 0x3b22ab97af1cdfa9. The key that Synaptic is complaining about however is 0x5EB2EDFE1FCB21DB, i.e. a completely different key. Can anyone tell me what to do here?

Julien Olivier (julo) wrote :

I've just tested with XUA enable, DRI2 enabled and UseFBDev enabled and with the packages coming from x-updates on this device: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02). The result is really disappointing:
 - the bug with videos when compiz is running is still there
 - glxgears no run at about 300 fps instead of 500 fps before (without compiz enabled)
 - if I enable compiz, glxgears drop to 200 fps

PS: I submitted an entry to http://wiki.ubuntu.com/X/UxaTesting

Bryce Harrington (bryce) on 2009-05-13
summary: - 3D stuff breaks with Compiz: Redirected Direct Rendering is needed in
- DRI
+ (Needs UXA) 3D stuff breaks with Compiz: Redirected Direct Rendering is
+ needed in DRI
Bryce Harrington (bryce) on 2009-05-13
summary: - (Needs UXA) 3D stuff breaks with Compiz: Redirected Direct Rendering is
- needed in DRI
+ (Needs UXA/DRI2) 3D stuff breaks with Compiz: Redirected Direct
+ Rendering is needed in DRI

This bug was fixed in the package xserver-xorg-video-intel - 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1

---------------
xserver-xorg-video-intel (2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1) karmic; urgency=low

  * Update to git 20090602 (master branch) up to commit ec2fde7c
    - xvmc is disabled since DRI1 no longer supported
    - LP: #96991 - 3D stuff breaks with Compiz: Redirected Direct Rendering
      is needed in DRI
    - LP: #120834 - X freezes with I830WaitLpRing error when running OpenGL apps
    - LP: #337608 - X crashes in fbBlt() when using Sun Java Plugin 6 + firefox3.0
    - LP: #339555 - compiz slowmotion after Jaunty upgrade
    - LP: #363900 - X.org freezes with intel driver, no apparent trigger
    - LP: #331719 - VT switching doesn't work on Intel 915GM
    - LP: #339091 - X freezes a few minutes after resuming
    - LP: #348436 - Kubuntu: X server crash when screensaver is started (4500MHD)
    - LP: #279727 - Kubuntu: Display Corruption w/ Intel 4700MHD
    - LP: #357851 - Kubuntu: Distorted display after switching virtual desktops w/ exa
    - LP: #158415 - Front buffer dynamic resize not supported
    - LP: #324998 - x server restarts itself w/ compiz on Intel 945GM
    - LP: #355593 - after upgrade to 9.04, rotating desktop cube ran slow
    - LP: #357290 - 1 fps in 3d apps like neverball with EXA
    - LP: #360774 - Graphical Corruption with EXA on X4500
    - LP: #364126 - screensaver prefs dialog in 9.04 RC livecd leaves dirt
    - LP: #375712 - Native resolution for dell "2005fpw" monitor not listed
    - LP: #375264 - Choppy flash video and poor performance with compiz
    - LP: #349568 - Jaunty / Compiz slow and tearing on GMA 4500MHD
    - LP: #356056 - window tearing during movement on 965 (no compiz)
    - LP: #330460 - xorg shows black image/hangs with jpg in firefox
    - LP: #347587 - X asserts on pI830->batch_ptr != 0 on resume from suspend
  * Merge with Debian experimental. Remaining Ubuntu changes:
    - Add lpia architecture
    - Re-enable the patch system, add quilt to build-deps.
    - 110_quirk_hp_mini.patch: quirk (sent upstream)
    - 117_quirk_thinkpad_x30.patch: quirk (sent upstream)
  * Drop 116_8xx_disable_dri.patch. There have been fixes for 3d on 8xx
    chipsets upstream, so drop the DRI disablement so the fixes can be
    re-tested.
  * Drop 103_quirk_intel_mb890.patch. Better quirk available upstream.
    (LP: #305269)

 -- Bryce Harrington <email address hidden> Tue, 02 Jun 2009 10:47:32 -0700

Changed in xserver-xorg-video-intel (Ubuntu):
status: In Progress → Fix Released
Derek White (d-man97) wrote :

Regarding ati/radeon and the video not moving with the window when compiz is used, I have a workaround:

[I am using medibuntu's mplayer, I assume it will work with the normal one too. My xorg.conf is blank.]
Open video in mplayer, let it play, & stop the video - leave mplayer open. Open video in a new instance of mplayer: the video stays in its window when moved, all compiz effects (Alt-Tab, wobble, cube, etc.) work with the video staying inside its window. The original mplayer instance can be closed at any time after the second has started. [This might work in totem as well, but I do not know how to open multiple instances of totem.]

Once all instances of mplayer are closed, you have to re-do the workaround for it to work again.

Derek White (d-man97) wrote :

I also agree with: Oliver Mattos' postings from 2008-04-27 and 2008-07-18; Vytas' post from 2008-10-03 "...enabling obviously crippled software does more harm than good..." - just look at the dups; & David Fokkema's post on 2008-10-05. Compiz should not be enabled by default with ati driver until this is fixed.

Having a default not work properly when simply disabling the Visual Effects setting makes it work is annoying to users. Disabling it by default could prevent the user from being disappointed/annoyed. Then, when they activate it, it's their own fault for messing with things. Isn't that the Linux way? ;)

Extender (msveshnikov) wrote :

So, for ATI X700, UXA/DRI2 still not working?
I have this in Xorg.log:
 AIGLX: Screen 0 is not DRI2 capable

xorg.conf is configured correctly, I tried kernels 2.6.30 and 2.6.31rc3 and radeon driver from Xorg-edgers PPA.

Vish (vish) wrote :

Architecture: i386
DistroRelease: Ubuntu 9.10
Uname: Linux 2.6.31-4-generic i686
ATI Mobility Raedon X1400

Vish (vish) wrote :

Still present in :
Architecture: i386
DistroRelease: Ubuntu 9.10
Uname: Linux 2.6.31-4-generic i686
ATI Mobility Raedon X1400

Bryce Harrington (bryce) on 2009-07-30
summary: - (Needs UXA/DRI2) 3D stuff breaks with Compiz: Redirected Direct
+ (Needs radeon-rewrite) 3D stuff breaks with Compiz: Redirected Direct
Rendering is needed in DRI
Bryce Harrington (bryce) on 2009-08-14
Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-ati - 1:6.12.99+git20090825.fc74e119-0ubuntu1

---------------
xserver-xorg-video-ati (1:6.12.99+git20090825.fc74e119-0ubuntu1) karmic; urgency=low

  * Checkout from git 20090825 (master branch) up to commit
    fc74e1194c980d978667e02c60a29a761a694bde
    + Adds DRI2 / redirected direct rendering
      (LP: #96991)
    + Fix freeze on opengl games (bzflag, alienarena) (when KMS on)
      (LP: #348450)
    + Fix intermittent short screen blanking behavior
      (LP: #310864)
    + Fix faulty wine screen updates with EXA Compositing
      (LP: #314205)
    + Fix screen corruption issues when switching windows
      (LP: #406731)
    + Fix SIGSEGV crash in drmCommandNone()
      (LP: #352567)
    + Fix smeared/tearing of display on reboot
      (LP: #367741

  [Tormod Volden]
  * 199_add_git_version_to_log.diff: Log git commit id in RadeonPreInit()
  * sed -i s/DRI2BufferPtr/DRI2Buffer2Ptr/ src/radeon_dri2.c
      so it compiles against xserver 1.6.2.+

  [Bryce Harrington]
  * Restore patch system and quilt to build-depends
  * Drop patches already present upstream
    + 107_check_unsupported_composit_ops.patch
    + 108_quirk_agpmode_m6_ali.patch: AGPMode quirk.
    + 109_quirk_agpmode_m7_intel.patch: AGPMode quirk.
    + 110_quirk_agpmode_r420_sis.patch: AGPMode quirk.
    + 111_use_xaa_for_lowmem_or_nodri.patch

 -- Bryce Harrington <email address hidden> Sat, 29 Aug 2009 12:16:53 -0700

Changed in xserver-xorg-video-ati (Ubuntu):
status: Triaged → Fix Released
Extender (msveshnikov) wrote :

And how to test that?

Tormod Volden (tormodvolden) wrote :

You can test it in Karmic (or the Karmic alpha 5 live CD, due tomorrow) by adding the boot parameter "radeon.modeset=1".

Using the Alpha 5 Live CD, I pressed F6 to edit the options and added
radeon.modeset=1 just before the 'quiet splash -- ' parameters. Once the
boot process started, the screen said something like "unknown boot
option, ignoring" in reference to the modeset option. Boot process
continued normally, until after the boot splash went away (prior to gdm
starting): my screen went into power saving mode and the computer did
nothing. Ctrl-Alt-Del had no effect and I had to hard reset the system.

I am using an ATI Radeon 9550 (RV350) 256MB graphics card (manufactured
by ATI) on a Biostar M7NCD motherboard with an nVidia nForce2 400 + MCP
chipset. If there is any further testing/debugging I can do from the
Live CD, please let me know.

Vish (vish) wrote :

"radeon.modeset=1" needs to be added at the end of the kernel line, 1 space after "splash". [Well, that's how it works for me :) ]
But do note , there is regression with using KMS , the FPS will be much lower than without the KMS. [in my case nearly half]
So the system might *seem* a bit sluggish, well it is actually the slow rendering and not the cpu slowness.

For any other info > https://wiki.ubuntu.com/X or you can ask for help in irc #ubuntu-x .

Tormod Volden (tormodvolden) wrote :

You can put radeon.modeset=1 anywhere on the line. But see bug #410058 instead for this ati-specific issue.

Eugene Savelov (savelov) wrote :

Tested with Radeon XPRESS 200M - when in DRI2 mode, with KMS, Google earth have visual problems
without KMS, displays correctly

I have this bug on the oficial release of Karmic Koala using amd64 desktop edition on a radeon xpress 200 (RS482).
Some help is needed.
Thanks

If I run:
strace glxgears

the system (or xorg) freezes completely, but if I run:
strace -o glxgears.trace.log glxgears

it doesn't.
Maybe Its related to this bug.
May I open another bug?

the "strace glxgears issue" happens too using the proprietary driver (fglrx), but instead of karmic in intrepid.

I can assure you this has nothing to do with this bug. Please discuss
this elsewhere!

2009/11/10 Reynaldo Matos Hortensi <email address hidden>:
> the "strace glxgears issue" happens too using the proprietary driver
> (fglrx), but instead of karmic in intrepid.
>
> --
> (Needs radeon-rewrite) 3D stuff breaks with Compiz:  Redirected Direct Rendering is needed in DRI
> https://bugs.launchpad.net/bugs/96991
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Extender (msveshnikov) wrote :

Yes I can confirm that bug is fully resolved (ATI X700) with radeon.modeset=1 kernel parameter.
Windows overlap normal with Compiz on and off.
Gogle earth has NO artefacts and flickering (with Compiz on!)
Performance of glxgears is slightly decreased (1800 fps against 2400 fps).

Hi Extender,
I have tried with xorg-edger drivers and radeon.modset=1 kernel parameter... everything worked fine but googleearth (ATI Radeon Xpress 200, chipset RS482).
Glxgears worked fine (I can move the glxgears window without artefacts on screen).
Googleearth have produced artefacts (see attachment).
I will be back with number for glxgears and gtkperf.

Pauli (paniemin) wrote :

This is different problem. This looks a lot like rendering bug that should
be reported in new bug report (unless it is already reported in some newer
bug report)

On Fri, Dec 25, 2009 at 1:56 PM, Reynaldo Matos Hortensi <
<email address hidden>> wrote:

> Hi Extender,
> I have tried with xorg-edger drivers and radeon.modset=1 kernel
> parameter... everything worked fine but googleearth (ATI Radeon Xpress 200,
> chipset RS482).
> Glxgears worked fine (I can move the glxgears window without artefacts on
> screen).
> Googleearth have produced artefacts (see attachment).
> I will be back with number for glxgears and gtkperf.
>
>

*** Bug 27947 has been marked as a duplicate of this bug. ***

Why is this marked as FIXED? I see that one poster found a workaround by manually enabling dri2 and uxa on Ubuntu, but the fix was never ported to the released version of the driver. That is, even on Ubuntu, users are bitten by this bug unless the know how to enable dri2 and uxa, and assuming that they know that they even have to.

I am reopening until the issue is fixed, a workaround (or manually enabling dri2/uxa) is not a fix.

One of the main points of DRI2 was to fix GL + composite. It will only work as expected with a DRI2 capable driver. DRI2 is not a workaround, it is the fix.

> One of the main points of DRI2 was to fix GL + composite. It
> will only work as expected with a DRI2 capable driver. DRI2 is
> not a workaround, it is the fix.

I have misunderstood, then. I understood this issue to be for improving OpenGL (and DRI) support for a specific driver. I was too quick to mark my own bug as a dupe (see comment 25). I will reopen that bug as a request to enable DRI in radeonhd.

Thanks.

> --- Comment #28 from Dotan Cohen <email address hidden> 2010-05-03 12:19:42 PDT ---
> I will reopen that bug as a request to enable DRI in radeonhd.
>
don't. just use radeon instead.

Changed in xorg-server:
importance: Unknown → High
Changed in xorg-server:
importance: High → Unknown
Changed in xorg-server:
importance: Unknown → High

LinkedIn
------------

Bug,

Vorrei aggiungerti alla mia rete professionale su LinkedIn.

-gabriele

gabriele vidali
IT helpdesk presso Temera Srl
Firenze, Italia

Conferma che conosci gabriele vidali:
https://www.linkedin.com/e/-7gpsk-ha2yz419-3d/isd/9808074698/qAAR2ok5/?hs=false&tok=31Z9G8hHMbo5w1

--
Stai ricevendo inviti di collegamento. Clicca per annullare l'iscrizione:
http://www.linkedin.com/e/-7gpsk-ha2yz419-3d/Xk1OvfwjxCYck4FyPC5cBSoye1ERMckp7JxCqy/goo/96991%40bugs%2Elaunchpad%2Enet/20061/I3274259603_1/?hs=false&tok=2QRnqoBGIbo5w1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

Displaying first 40 and last 40 comments. View all 119 comments or add a comment.