You are not logged in.
Is that even after a reboot? A wedged GPU definitely doesn't sound good.
Yes, I get them all the time.
Previously it was working OK, but the new (xf86-video-intel 2.20.1) drivers are a bit slow.
I haven't even bothered to google what's that wedged thing about ;P
Offline
Wedged is just another word for hung. Which is a fancy way of saying borked . Like I said, report it. That's the only way you'll get a fully functional driver. I unfortunately don't have gen2 hardware to play with. Or maybe I'm fortunate that I don't . Though I do have a laptop with SiS graphics, which isn't much better - for a while it's been running on Shadow, because both xaa and exa were making X crash like crazy.
Offline
Al right, all right, I see what I can do ;P
Even though both hung and wedged gpu talk about disabling acceleration, the outcome is very different: with the hung gpu the system is unusable (scrolling a page / window or switching windows / tags takes a couple seconds), with a wedged gpu it was slower than uxa with shadow, but not nearly as bad as a hung gpu.
Offline
There's no xaa in the driver, hasn't been there for a loooong time.
Does that mean the post_install message is wrong:
>>> This driver now allows to switch
>>> between several acceleration methods.
>>> Add to the device section in /etc/X11/xorg.conf
>>> Option "AccelMethod" "sna"
>>> use uxa/xaa method if you run into trouble with sna.
? (emphasis mine)
Should I file a bug against the intel manpage too? There's nothing about AccelMethod in there.
I do get a hung gpu with intel-git.
Offline
I reported that bug: https://bugs.freedesktop.org/show_bug.cgi?id=52624
At least with xf86-video-intel 2.20.2-2 I got a 'hung gpu' error too after a while:
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 17.645] (WW) intel(0): Detected unsupported/dysfunctional hardware, disabling acceleration.
[ 18.252] (WW) intel(0): Textured video not supported on this hardware
[ 18.264] (WW) intel(0): loading DRI2 whilst the GPU is wedged.
[ 7948.252] (EE) intel(0): Detected a hung GPU, disabling acceleration.
[ 7948.252] (EE) intel(0): When reporting this, please include i915_error_state from debugfs and the full dmesg.
The effect is different from a hung gpu while using uxa - with sna there's little if any difference before and after the hung gpu.
It's still slower than uxa with shadow.
Offline
The conversation in that bug and the resulting code changes are quite interesting, I must say. Basically, if the driver saw a i8xx, it immediately marked it as "wedged", thus disabling GPU acceleration. But there are some checks missing, which meant some functions attempted GPU acceleration despite the "wedged" state. This caused issues.
What Chris did now is he enabled GPU acceleration by not immediately marking the GPU as "wedged", and if you don't like it (because of instability or because you find it slower), you can disable it with Option "NoAccel" "true". I'm really curious what you get now. Try first with acceleration, see how it feels. Then disable acceleration using NoAccel and compare.
Offline
I've just compiled the -git version of the driver and already managed to hang the gpu ;P
$ dmesg | tail
[ 9.078338] Adding 265068k swap on /dev/sda2. Priority:-1 extents:1 across:265068k
[ 11.234558] Adding 255996k swap on /dev/zram0. Priority:60 extents:1 across:255996k SS
[ 11.534584] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 11.536840] e100 0000:02:08.0: eth0: NIC Link is Up 100 Mbps Full Duplex
[ 11.537128] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 313.836677] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[ 313.836694] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[ 317.059991] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[ 317.060185] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[ 317.060190] [drm:i915_reset] *ERROR* Failed to reset chip.
$ grep -E '\((WW|EE)' /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 22.874] (WW) intel(0): Textured video not supported on this hardware
[ 318.101] (EE) intel(0): Detected a hung GPU, disabling acceleration.
[ 318.101] (EE) intel(0): When reporting this, please include i915_error_state from debugfs and the full dmesg.
but even in this state the machine is pretty usable.
Tomorrow I'll test if I can reproducibly hang it etc.
Offline
After testing different configurations for xf86-video-intel 2.20.3 I found
Section "Device"
Identifier "card0"
Driver "intel"
Option "AccelMethod" "uxa"
Option "NoAccel" "true"
Option "DRI" "false"
EndSection
to be the most stable and pleasant to work with. I have to disable 2D acceleration (Option "NoAccel" "true") otherwise the GPU hangs. No acceleration sucks but I guess such is life ;P
SNA is considered experimental and that's why it's not mentioned in the man page: https://bugs.freedesktop.org/show_bug.cgi?id=52628
Offline
Isn't "AccelMethod" "uxa" redundant? Cos right now you're setting an accel method and in the next step removing acceleration. So why set it if you're removing it anyway
Though you could use SNA and not disable accel - that way you could enjoy acceleration... in the three or so minutes until the GPU hangs
Also, is it necessary to disable DRI? You could have no 2D acceleration, but still have DRI active for 3D stuff. Or does the 3D stuff also hang immediately?
Last edited by Gusar (2012-08-07 13:09:12)
Offline
Isn't "AccelMethod" "uxa" redundant? Cos right now you're setting an accel method and in the next step removing acceleration. So why set it if you're removing it anyway
Good point.
Though you could use SNA and not disable accel - that way you could enjoy acceleration... in the three or so minutes until the GPU hangs
And in that three minutes stuff like switching tags in dwm, opening new terminals etc. is blindingly fast.
Once I get a new computer I'll be able to enjoy it :-)
Also, is it necessary to disable DRI? You could have no 2D acceleration, but still have DRI active for 3D stuff. Or does the 3D stuff also hang immediately?
I don't do 3D stuff. The only drawback of not disabling DRI is a warning from the X log:
[ 18.284] (WW) intel(0): cannot enable DRI2 whilst forcing software fallbacks
Plus, it seems that my WM is a bit more responsive with DRI disabled, but I haven't measured it.
Offline
I created a package, which reverts the shadow hack, so the
Option "Shadow" "True"
can be used with the latest 2.20.4 release: https://aur.archlinux.org/packages.php?ID=62137 (Available in my [city] repo also as a compiled package.)
UPDATE:
The package was removed, because the shadow hack is no longer work, I still get GPU hangs with the Shadow option.
Last edited by City-busz (2012-08-26 21:33:57)
Offline
Not sure how much that makes sense. Shadow was an incomplete hack, whereas SNA's CPU code is not a hack. So setting "NoAccel" "true" (which makes SNA use CPU only) is a better solution than shadow.
Offline
Offline
From my experience, "NoAccel" "true" is much slower than the shadow hack. (E.g. windows are painted slowly from the top to the bottom when I move them).
It's true for me too.
UXA w/ shadow was really nice wrt window switching and the like. As noted above, SNA is even better, but it hangs really quick w/o "NoAccel" "true" :-(
Offline
Decided to revisit my 82845G pc.
SNA seems to be working ok now.
I no longer see any glaring glitches or slowness, with the exception of tearing in non compositing WM. It seems to work ok.
Going to try a compositing WM, maybe compiz to see how it goes.
Last edited by snoxu (2012-12-11 16:40:00)
Offline
Can you post the output of 'lspci | grep VGA'?
Offline
lol sure:
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
Is there any way to check on wether acceleration is active or not?
Last edited by snoxu (2012-12-11 16:39:10)
Offline
Looked at /var/log/Xorg.0.log found this:
SNA initialized with gen2 backend
edit: Compiz does not seem to work, unless I'm doing something wrong:
fusion-icon
* Detected Session: xfce
* Searching for installed applications...
* No GLX_EXT_texture_from_pixmap with direct rendering context
... nor with indirect rendering, this isn't going to work!
* Using the GTK Interface
* Starting Compiz
... executing: compiz --replace --sm-disable --ignore-desktop-hints ccp
On the plus side Xfce4 compositing seems to work
Last edited by snoxu (2012-12-11 18:02:24)
Offline
I have the same GPU and it hangs with SNA enabled.
/etc/X11/xorg.conf.d/20-intel.conf:
Section "Device"
Identifier "card0"
Driver "intel"
Option "AccelMethod" "sna"
EndSection
Offline
A few months back SNA or UXA didn't work for me either, can't remember which.
I just did a clean install of Arch yesterday and to my surprise SNA seems to be functional. I can't really know whether acceleration is enabled or not unless someone tells me how to check for that.
Offline
Great news! After three years Chris Wilson fixed the problem finally: https://bugs.freedesktop.org/show_bug.cgi?id=26345#c152
I'll test my system with xf86-video-intel-git in the next days.
Offline
Great news! After three years Chris Wilson fixed the problem finally: https://bugs.freedesktop.org/show_bug.cgi?id=26345#c152
I'll test my system with xf86-video-intel-git in the next days.
I doesn't seem to work at all for me:
$ chromium-bsu
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 153 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Serial number of failed request: 25
Current serial number in output stream: 26
$ grep -E '\((WW|EE)' /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 56.252] (WW) intel(0): Textured video not supported on this hardware
[ 56.273] (WW) intel(0): loading DRI2 whilst the GPU is wedged.
Both SNA and UXA hang the GPU pretty fast, unless I'm using
Option "NoAccel" "true"
Edit:
Correction: SNA doesn't work even with NoAccel enabled. I get a wedged GPU almost instantly. I have the same issues with the stock Arch drivers, so it's not the -git version's fault.
Last edited by karol (2012-12-14 03:00:00)
Offline
I doesn't seem to work at all for me:
$ chromium-bsu X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Serial number of failed request: 25 Current serial number in output stream: 26
It's a bug in mesa: https://bugs.archlinux.org/task/32666
Downgrading libgl and intel-dri to version 8.0.4 solves the problem.
$ grep -E '\((WW|EE)' /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 56.252] (WW) intel(0): Textured video not supported on this hardware [ 56.273] (WW) intel(0): loading DRI2 whilst the GPU is wedged.
Both SNA and UXA hang the GPU pretty fast, unless I'm using
Option "NoAccel" "true"
Edit:
Correction: SNA doesn't work even with NoAccel enabled. I get a wedged GPU almost instantly. I have the same issues with the stock Arch drivers, so it's not the -git version's fault.
I didn't get any GPU hang in GNOME Fallback mode yet. Maybe it's a fault in your system?
Offline
After the downgrade I now get
[ 124.481] (WW) intel(0): Textured video not supported on this hardware
in the X log, but otherwise stuff seems to be working with SNA. I've tested it with chromium-bsu for over an hour, but I think I should play some more games do some more testing ;P
Thanks a lot, City-busz!
Offline
After the downgrade I now get
[ 124.481] (WW) intel(0): Textured video not supported on this hardware
I get that without downgrading. but I can run Xfce4 ok with SNA.
in the X log, but otherwise stuff seems to be working with SNA. I've tested it with chromium-bsu for over an hour, but I think I should play some more games do some more testing ;P
Thanks a lot, City-busz!
I have the same issue with chromium-bsu so I'm going to give the downgrade a go.
Last edited by snoxu (2012-12-14 21:07:58)
Offline