LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 04-18-2011, 06:26 PM   #496
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138

Quote:
Originally Posted by volkerdi View Post
Is this driver _better_ for anyone than 2.14.0? Speak now, because it is about to be reverted. I have not heard anything positive so far.
It fix several KDE relatated issues and I tested successfully on 17 i915 video / G31 based machines, with different mem/proc configuration. Of course, all desktops.

Technically, it's just a bug-fixes release, no serious enhancements.

Code:
Release 2.15.0 (2011-04-14)
==============================
We are pleased to announce this major release of the xf86-video-intel
driver, roughly on schedule at 3 months since 2.14.0. With the many bug
fixes in this release, we encourage everyone to upgrade to 2.14.

The priority for this quarter has been simply to be unexciting and stabilise
the driver further, seeking to capitalise upon the improvements elsewhere
in the stack.

Bugs fixed in this snapshot (compared to 2.14.903)
--------------------------------------------------

* Turn off relaxed fencing by default for older chipsets
  This was continuing to destabilize those system, so for the release
  we disabled the feature. If you wish to help us debug this, you can
  re-enable the optimisation with Option "RelaxedFencing" "True".
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36147 <-- Not tested. Everything works fine.

* Build fix for xserver-1.7.7

* KDE glitches on SNB
  [Technically fixed in the previous snapshot, but I'm really pleased
   that this got fixed in time for the release!]
  https://bugs.freedesktop.org/show_bug.cgi?id=35808 <-- personaly I experienced a crash in the past! KDM works fine again.


Snapshot 2.14.903 (2011-04-11)
==============================
This is the third release candidate in preparation for the upcoming
2.15.0 release. We will appreciate any feedback we can get from
testing of this snapshot.

There was a bit of churn since 2.14.902 as a potential fix for a
performance regression was tried but had to reverted when it was found to
cause glitches running Compiz on SandyBridge. Otherwise, there were just a
couple of fixes for building against old xservers and running on an
obscure chipset.

Bugs fixed in this snapshot (compared to 2.14.902)
--------------------------------------------------

* Prevent issuing an invalid scanline wait command
  https://bugs.freedesktop.org/show_bug.cgi?id=35576 <-- possible crash, not personally experienced

* The 946GZ in not a 945, but a 965.
  https://bugs.freedesktop.org/show_bug.cgi?id=35854 <-- possible crash, not personally experienced

* Fix tile sizes for gen2 (finally). <-- possible strange 'pictures' 

* Allow building of recent dri2 changes against old xservers.


Snapshot 2.14.902 (2011-03-29)
==============================
This is the second release candidate in preparation for the upcoming
2.15.0 release. We will appreciate any feedback we can get from
testing of this snapshot.

As befits testing of release candidates, no major regression was found and
a couple more bugs have been fixed.

Bugs fixed in this snapshot (compared to 2.14.901)
--------------------------------------------------

* Clients disappearing with pending swaps

* Incorrect clipping of Xv output on i915 across extended desktops
  https://bugs.freedesktop.org/show_bug.cgi?id=35346

* Introduction of a LinearFramebuffer option. (Defaults to tiled for
  performance and power saving.)


Snapshot 2.14.901 (2011-03-02)
==============================
This is the first release candidate in preparation for the upcoming
2.15.0 release. We will appreciate any feedback we can get from
testing of this snapshot.

Still no further along my grandiose plans to improve Render performance,
aside from the performance tuning lower in the stack, instead we have had
a steady stream of bug fixes.

Bugs fixed in this snapshot (compared to 2.14.0)
------------------------------------------------

* Green pixels within partially off-screen video playback
  https://bugs.freedesktop.org/show_bug.cgi?id=24767 <-- bad 'pictures'

* Defer creation of the glyph cache to generation startup
  https://bugs.freedesktop.org/show_bug.cgi?id=33412 <-- personally, I experienced a crash in the past.


* Incorrect maximum addresses for video decoder state
  https://bugs.freedesktop.org/show_bug.cgi?id=34017

* Failure to handle oversized temporary surfaces
  https://bugs.freedesktop.org/show_bug.cgi?id=34399 <-- personally, I experienced a crash in the past.

* Relaxed tiling corruption on gen2

* Crash when destroying a foreign DRI drawable
  https://bugs.freedesktop.org/show_bug.cgi?id=34787 <-- personally, I experienced a crash in the past.
As rest of used graphical stack for Intel target:

libdrm-2.4.25
Mesa-7.10.2

Last edited by Darth Vader; 04-18-2011 at 06:38 PM.
 
1 members found this post helpful.
Old 04-18-2011, 06:41 PM   #497
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Quote:
Originally Posted by Darth Vader View Post
It fix several KDE relatated issues and I tested successfully on 17 i915 video / G31 based machines, with different mem/proc configuration. Of course, all desktops.

Technically, it's just a bug-fixes release, no serious enhancements.
Yes, that's the upstream story. So, are you saying that the previous Intel driver crashed FOR YOU, and this one does not? I'm just looking for some data here. Both the new driver and the old driver work fine for me. However, I was not getting crash reports on the previous driver, but there are some on the new one. Either way, these are the two drivers that will ship. I'm just wondering which one is the better default.
 
1 members found this post helpful.
Old 04-18-2011, 06:48 PM   #498
brixtoncalling
Member
 
Registered: Jul 2008
Location: British Columbia
Distribution: Slackware current
Posts: 403

Rep: Reputation: 67
Quote:
Originally Posted by volkerdi View Post
Yes, that's the upstream story. So, are you saying that the previous Intel driver crashed FOR YOU, and this one does not? I'm just looking for some data here. Both the new driver and the old driver work fine for me. However, I was not getting crash reports on the previous driver, but there are some on the new one. Either way, these are the two drivers that will ship. I'm just wondering which one is the better default.
For what it is worth, my experience is that the old driver is slightly less problematic although I experienced X crashes with both drivers. The difference is that I knew how to avoid the crash with the old Intel driver: don't run GL Xscreensavers when compositing is enabled. With the new driver, crashes are frequent, although not as predictable. Xscreensavers seem to cause a hard lock sometimes, but most of the time it runs fine (GL screensavers included). Other times, X crashes and dumps me at the console but I have seen no pattern for when.
 
2 members found this post helpful.
Old 04-18-2011, 07:12 PM   #499
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
Quote:
Originally Posted by volkerdi View Post
Yes, that's the upstream story. So, are you saying that the previous Intel driver crashed FOR YOU, and this one does not? I'm just looking for some data here. Both the new driver and the old driver work fine for me. However, I was not getting crash reports on the previous driver, but there are some on the new one. Either way, these are the two drivers that will ship. I'm just wondering which one is the better default.
Yes, I experienced (some) problems with 2.14.0, avoided by 2.15.0. This driver version looks to work fine into i915 target.

Still, we talk about some typical 'company' computers, then a typical installation with no fancy graphics beyond these offered by KDE4, but very important, a functional KDM with no crashes.

As bottom line, give me one day, and I will watch especially these Intel computers. I will report again, tomorrow, any observed problem.

BTW, this is the testing motherboard for all systems on Intel target.
 
1 members found this post helpful.
Old 04-18-2011, 07:33 PM   #500
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 223Reputation: 223Reputation: 223
Quote:
Originally Posted by volkerdi View Post
Is this driver _better_ for anyone than 2.14.0? Speak now, because it is about to be reverted. I have not heard anything positive so far.
Revert that sucker

GMA 3150 (Pineview), GMA950 and GMA X4500 (i915 driver), with 2.14 and mesa 7.10 work great in KDE with effects on for us. I've experienced the same window redraw hesitation with 2.15 as reported in another thread, with either version of Mesa and libdrm. The hesitation is far more profound on the 3150 and 950.

I did have to modify /etc/kde/kdm/kdmrc and set TerminateServer=True to avoid a KDM segfault on logout. Not sure what that's about - but seems to be common enough with Intel GPUs that Google was able to point me in the right direction.

---edit---
I should note - both drivers are stable. It just seems (to me) that 2.14 gives better performance. Wouldn't bother me if I had to install a different driver from testing. Not the first time this has happened with Intel

Last edited by disturbed1; 04-18-2011 at 07:47 PM.
 
2 members found this post helpful.
Old 04-18-2011, 08:19 PM   #501
ThomasAdam
Member
 
Registered: Apr 2011
Posts: 30

Rep: Reputation: 9
Quote:
Originally Posted by volkerdi View Post
I thought that new development features would be going into the 2.7.x branch... no?
No -- that won't be the case -- there's several things I (we) will be doing:

* Baselining 2.6.1 as "stable"
* Moving to Git
* NO MORE 2.7.X as "unstable"
* Incremental updates/topics developed on different branches
* Preview releases of proposed features/bugs.
* Code merged -- releases happen 2.6.2, 2.6.3, etc... 2.7.0

There'll be no longer this gulf between stable/unstable -- it's all going to be incremental from now on.

I only updated 2.7.0 as the unstable version wasn't still at 2.5.32.

-- Thomas Adam
 
Old 04-18-2011, 08:19 PM   #502
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
Quote:
Originally Posted by disturbed1 View Post
I should note - both drivers are stable. It just seems (to me) that 2.14 gives better performance.
I believe, the both drivers will be at same performance if you chose to add into xorg.conf:

Code:
Option "RelaxedFencing" "True"
PS. This is just required to be added for new chipsets, to ensure stability on some old chipsets, nothing more. Just add this line in your video driver section and you'll be happy.

Last edited by Darth Vader; 04-18-2011 at 08:23 PM.
 
0 members found this post helpful.
Old 04-18-2011, 08:24 PM   #503
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 223Reputation: 223Reputation: 223
Quote:
Originally Posted by Darth Vader View Post
I belive, the both drivers will be at same performance if you chose to add into xorg.conf:

Code:
Option "RelaxedFencing" "True"
PS. This is just required to be added for new chipsets, to ensure stability on some old chipsets, nothing more. Just add this line in your video driver section and you'll be happy.
Ummm no -
Relaxed Fencing in enabled by default for Pineview + already, and disabled for older chipsets because it is buggy.

Quote:
Turn relaxed-fencing off by default for older (pre-G33) chipsets
There are still too many unresolved bugs, typically GPU hangs, that are related to using relaxed fencing (i.e. only allocating the minimal amount of memory required for a buffer) on older hardware, so turn off the feature by default for the release.
http://cgit.freedesktop.org/xorg/dri...13e6a8ac013f26
 
Old 04-18-2011, 08:31 PM   #504
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
Quote:
Originally Posted by disturbed1 View Post
Ummm no -
Relaxed Fencing in enabled by default for Pineview + already, and disabled for older chipsets because it is buggy.


http://cgit.freedesktop.org/xorg/dri...13e6a8ac013f26
Sorry! It's 03.28 AM for me. Looks like it's time to end the transmission, before to say funny things ...

Yeah, you are right. This option is just required for me, because I use the G31 chipsets.
 
Old 04-18-2011, 08:36 PM   #505
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 223Reputation: 223Reputation: 223
Quote:
Originally Posted by Darth Vader View Post
Sorry! It's 03.28 AM for me. Looks like it's time to end the transmission, before to say funny things ...

Yeah, you are right. This option is just required for me, because I use the G31 chipsets.
You don't need sleep -- just drink more coffee
 
Old 04-19-2011, 02:52 AM   #506
rouvas
Member
 
Registered: Aug 2006
Location: Greece
Distribution: Slackware.12.2
Posts: 85
Blog Entries: 2

Rep: Reputation: 6
Quote:
Originally Posted by volkerdi View Post
Well, considering how quickly 4^H2.6.1 was released, I think it's at least fair to say that 4^H2.6.0 was bleeding edge. If we see 4^H2.6.2 within a month, it's probably fair to say that about 4^H2.6.1, too.
Although I understand the reasoning, I'm not quite sure it applies to FVWM.
I've been running various "unstable" FVWM versions for the last 13.37 years or so, on Slackware versions 10.0, 10.2, and 12.2 with not a single issue.
In fact a lot of more active projects have often left me in the cold. KDE and mplayer pop in mind (but I'd hate to see them left out) and other more obscure software has found its way in Bob's den (e.g.virtuoso).

Anyway, 13.37 should be so close now, that it wouldn't be wise to delay it any longer, barring security issues.

-Stathis
 
Old 04-19-2011, 02:31 PM   #507
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
As promised, I will do a comparative test between Intel video driver, version 2.14.0 and 2.15.0.

The 'victim' for tests:

Motherboard: G31TM-P35
CPU: 'Intel Pentium Dual E2180@2.00GHz
Memory: 2GB DDR2 800MHz
Harddrive: WD3200AAKS, 320GB

Current configuration:

Slackware current, kernel-2.6.38.3-smp, AlienBob's KDE-4.6.2, Mesa-7.10.2, libdrm-2.4.25 and a custom xf86-video-intel-2.15.0, compiled against libdrm-2.4.25.

Notable Configurations:

In /etc/kde/kdm/kdmrc a line is added:

Code:
[X-:*-Core]
AllowNullPasswd=true
AllowShutdown=All
NoPassEnable=false
NoPassUsers=
ServerArgsLocal=-nolisten tcp
ServerCmd=/usr/bin/X -br -novtswitch -quiet
ServerTimeout=45
TerminateServer=true

[X-:*-Greeter]
AllowClose=false
Last night, very late, I forgot to mention that we use this option. I know, I know, in a Perfect World you do not need it, but the graphics stack is not perfect.

However, now I know that 'something strange will happen' without it.

Let me continue...

Another change, which is somewhat strange, is in /usr/bin/startkde:

Code:
#!/bin/sh
#
#  DEFAULT KDE STARTUP SCRIPT ( 4.6.2 (4.6.2) )
#

# KWIN workaround
export KWIN_DIRECT_GL=1

if test "x$1" = x--failsafe; then
    KDE_FAILSAFE=1 # General failsafe flag
    KWIN_COMPOSE=N # Disable KWin's compositing
    export KWIN_COMPOSE KDE_FAILSAFE
fi

# When the X server dies we get a HUP signal from xinit. We must ignore it
A rational explanation:

KWin uses OpenGL renderer string to get some information. But these happy lads from Mesa have decided to change the structure of this information.

With this parameter, we say to KWin, as it has direct rendering.

KWin with KWIN_DIRECT_GL parameter:

Code:
OpenGL vendor string:                   Tungsten Graphics, Inc
OpenGL renderer string:                 Mesa DRI Intel(R) G33  x86/MMX/SSE2
OpenGL version string:                  1.4 Mesa 7.10.2
Driver:                                 Intel
GPU class:                              i915/i945
OpenGL version:                         1.4
Mesa version:                           7.10.2
X server version:                       1.9.5
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           no
Texture NPOT support:                   yes
KWin without KWIN_DIRECT_GL parameter:

Code:
OpenGL vendor string:                   Tungsten Graphics, Inc
OpenGL renderer string:                 Mesa DRI Intel(R) G33  x86/MMX/SSE2
OpenGL version string:                  1.4 Mesa 7.10.2
Driver:                                 Intel
GPU class:                              i915/i945
OpenGL version:                         1.4
Mesa version:                           7.10.2
X server version:                       1.9.5
Linux kernel version:                   2.6.38
Direct rendering:                       no
Requires strict binding:                yes
GLSL shaders:                           no
Texture NPOT support:                   limited
Why do we need to properly inform KWin? For proper management of crisis situations. Read: crash.

And, mysteriously, the blur effect works again.

The third important element of our configuration is:

System Settings -> Desktop Effects -> Advanced -> Scale method: Smooth.

Then, no Lanczos filter for you, if you have a G31 'video-card'!

So, Scale method: Accurate is glorious about transforming your G31 system into something slooooooow, and, anyways, will not work ...

And last but not least, we have flashplayer 10.3 Beta, version 10.3.180.65.

---------------

Finally, the system looks responsive, everything works. Let's try to ruin it!

We use three methods to break the system:

1. We watch a clip on Youtube in 720p HD format. Full-screen and back, is efficient enough 'to see the console'.
2. The glorious OpenGL screensaver. You can be sure that something bad will happen. Here, our favorite will be Atlantis.
3. Logout into KDM screen. But here we already know, 'we have problems'.

Phase 1.
Initial system.

1. The video runs smoothly, full screen and back.
2. We test Atlantis. The first test works, then, KWin crack, and he comes back, without 3D effects. The system is still perfectly functional, but KWin's effects are not enabled.
3. Logout works.

This is exactly the behavior you expect. KWin has to disable the OpenGL effects of a crash.

Phase 2.
We install the stock 2.15.0 video driver, and we comment TerminateServer. Reboot.

1. The video runs smoothly, full screen and back. But it has moments of stuttering when we get into full-screen.
2. No major changes on Atlantis. KWin crash on first shoot and it comes back without effects.
3. Logout fails and we see the console. Goodbye, KDM!

Overall, the system feels a bit slower.

Phase 3.
We install Mesa-7.9.2 and libdrm-2.4.23. Reboot.

1. No major changes.
2. No major changes.
3. No major changes.

Overall, the system feels yet slower.

Phase 4.
We install the stock 2.14.0 video driver. Reboot.

1. No major changes.
2. X server freeze! But console switching works. We go on first virtual console and we comment the KWIN_DIRECT_GL, then reboot.
3. Can not be tested.

Phase 5.
No changes after reboot.

1. No major changes.
3. Logout into KDM screen works again. Login again.
2. X server crash. We see the console.

Overall, the system not feels slower or faster.

Phase 6.
We activate the default Scale method: Accurate.

1. The clip sees framed.
2. No changes.
3. No changes.

Overall, the system feels slooooooow.

--------------
That's it. It's time to repair this system.

Last edited by Darth Vader; 04-19-2011 at 02:53 PM. Reason: Messed with libdrm version on Phase 3
 
5 members found this post helpful.
Old 04-21-2011, 06:09 AM   #508
Dinithion
Member
 
Registered: Oct 2007
Location: Norway
Distribution: Slackware 14.1
Posts: 443

Rep: Reputation: 56
Does anyone know what version of wicd is included in the next release?
There is a pretty wicked bug in 1.6x that makes it hard (some times imposible?) to connect to networks with hidden SSID. Also some networks with visible SSID showes as <hidden> and makes them difficult to connect to.

I haven't experienced any problems with wicd 1.7.

Last edited by Dinithion; 04-21-2011 at 06:14 AM. Reason: Had to exploit the wicked pun.
 
Old 04-21-2011, 06:23 AM   #509
narz
Member
 
Registered: May 2007
Location: US
Distribution: slackware
Posts: 184

Rep: Reputation: 35
Wicd 1.7 is the one in current extra right now.
 
2 members found this post helpful.
Old 04-21-2011, 06:44 AM   #510
caduqued
Member
 
Registered: Apr 2008
Location: Coventry, United Kingdom
Distribution: Slackware64, Slackware64 13.37, linuxslackware
Posts: 81

Rep: Reputation: 19
I am so anxious, I can't resist to check at the News page in Slackware site for the announce... every 20 min.... and so in the ChangeLogs.

Will be Pat waiting for 25/05/11 ?

In any case, I have already ordered the DVD for 13.37.... hehehe
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Making Slackware and Slackware Derivative Linux Distros Speak Your Language LXer Syndicated Linux News 0 01-29-2009 01:30 AM
About Slackware 9.1 boot disk?? ftp://ftp.kpn.be/pub/linux/slackware/slackware-9.1-is AL3OMDAH Slackware 4 04-18-2007 10:54 AM


All times are GMT -5. The time now is 07:19 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration