You are not logged in.
I know there is some sort of transition going on with graphics stuff (take that as your cue that this is nowhere near an area of expertise for me...). I can put up with lack of games but last night I hooked my laptop up to my TV to watch some video and it was all choppy. So, I was trying to improve this....
So this is what I have:
Intel 945GM Integrated Graphics Chipset
xorg-server-1.6.0-1
With kernel26-2.6.28.8-1 I tried EXA and UXA. EXA gave me the issues with video play back and chromium-bsu is really slow.
Some not benchmarks from glxgears:
EXA - ~320FPS
UXA - ~640FPS
XAA = crash...
Switching to UXA gave me good chromium-bsu performance. Yeah!
Then I read that kernel 2.6.29 was supposed to make things better. So I built the rc8-git4 snapshot.
More not benchmarks from glxgears with the snapshot kernel:
EXA ~310FPS
UXA ~550FPS
chromuim-bsu runs at a low frame rate under both.
So it appears kernel 2.6.29 makes things worse... Is there something else I should build along with it? Or some config option I missed?
Offline
Are you using the 2.4.3 driver? If so, you won't be really using any of the last improvements. Anyway, even running the latest kernel and drivers things are still far from getting back to the old i810 driver performance. Check on the forums and you'll see there's even a repo with the old driver!
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
I assume you used xf86-video-intel 2.7RC1 from [testing]? Did you use Kernel Mode Setting with 2.6.29? Glxgears is expected to run slower under KMS, and here's why: http://qa-rockstar.livejournal.com/7869.html . If you did not, Intel is probably curious about any regressions, I am going to do post some reports for my hardware soon (915GM).
Also, I do not know how to put this tactfully, but if we all acknowledge that glxgears/gtkperf is not really a benchmark, why do we keep relying on it? Perhaps someone could make a mesa-demos AUR package?
Offline
Are you using the 2.4.3 driver?
Nope. I use all [testing], so I have xf86-video-intel 2.6.99.902-1. I know this is going to take a while for old time performance levels but thought 2.6.29 was going to be a big leap in the right direction. It appears to be a step back.
Offline
I assume you used xf86-video-intel 2.7RC1 from [testing]? Did you use Kernel Mode Setting with 2.6.29? Glxgears is expected to run slower under KMS
Absolutely, no idea. I use the current Arch kernel config and then just held down Enter for all the new config options (not a kernel hacker!). I will look into this.
Also, I do not know how to put this tactfully, but if we all acknowledge that glxgears/gtkperf is not really a benchmark, why do we keep relying on it? Perhaps someone could make a mesa-demos AUR package?
Well, my main testing is to run chromium-bsu and extreme-tux-racer (etracer). Under kernel 2.6.28, I can run both nicely. Under 2.6.29-rc8-git4, etracer is jerky and chromium-bsu runs at about ~10FPS compared fo ~50FPS.
Offline
I have this card and really sucks under Linux. I tested performance under Windows Vista and is a lot faster...
I have all packages from testing repo. UXA is a lot faster than EXA but still slow, and yes, with Kernel 2.6.29 is working worse
Excuse my poor English.
Offline
I assumed chromium-bsu is a variation of the Google's creation and immediately neglected it, pardon my ignorance (yeah, why would it have low framerate)
IIRC video tearing in EXA exists due to some design choices and one of the reasons UXA was created was to solve this issue.
Do you see any errors in the logs, especially regarding fence buffers, drm or hardware states? I sometimes do. Even though intel released 2.6.99.902 as RC1 there are still some substantial changes being made in the code. I think the most constructive approach right now is to monitor the performance and post regressions/errors to intel-gfx ML. Yeah, I know.
Last edited by fijam (2009-03-19 12:07:41)
Offline
After reading this topic, I am giving a try to the drivers on the testing repo. The performance is still not great, much much better than with the 2.4 series though. I can seem to run my KDE 4.2.1 desktop with the effects turned on. The system is pretty smooth
And this is running on UXA, on EXA/XAA the performance with kwin was terribly horrible although in glxgears was better. It becomes obvious to me that glxgears is *not* a valid test
Just my two cents
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
@ Allan: Have you tried removing the xorg.conf file completely (clearly only possible with 2.6.29 and KMS activated)?
Offline
No, but my config is fairly minimal... It still defaults to EXA anyway. I am still looking into the kernel 2.6.29 config to see if I missed something and then I will give this a spin with no conf file.
Edit: confirmed removing everything apart from AccelMethod line/section makes no difference to performance.
Edit: Does defaulting to EXA means I don't have KMS activated?
Another Edit: In my config file I have:
CONFIG_DRM_I915_KMS=y
So, I should have KMS enabled and UXA should automatically be selected and I now have no idea what is going on!
Offline
Have you checked /var/log/Xorg.0.log for errors or warnings?
Regarding uxa / exa you should also look into the same log... In my case (no xorg.conf, kernel 2.6.29-rc8 taken from kernel.org) UXA is selected by default.
Btw: Have you removed any framebuffer driver from the kernel .config (framebuffer support needs to be activated though)?
Offline
I haven't removed any framebuffer driver from the kernel config. But you put me onto the idea that I need to specify something like this in my kernel line
kernel /vmlinuz26-snapshot root=/dev/sda2 i915.modeset=1 ro 5
I didn't have "i915.modeset=1" in it before...
But that causes X to fail with this message:
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
Offline
Edit: Does defaulting to EXA means I don't have KMS activated?
Yes, since KMS depends on GEM. Or DRI2, I am not actually sure. In either case, that means UXA is required.
Last edited by fijam (2009-03-20 06:46:18)
Offline
Then it could be possible, that you hadn't enabled kms before specifying i915.modeset=1 in the menu.lst. And... I truely don't know how to activate kms using the Arch kernel, because afaik and as you can read in the xorg-server 1.6 thread it should only be possible without any framebuffer kernel driver...
One last idea: If you have installed xf86-video-fbdev you could try to remove it before starting x.
Offline
I'm almost given up on getting this working for now. 2.6.29 should be released soon so I will let the kernel maintainers fix this for me! But I will accept any working configs for kernel 2.6.29...
Offline
I have too given up trying to get any decent performance from my 965GM Intel-based graphics system. I'll just wait until they figure all this out, and keep using 2.6.3 which at least boots and has decent 2D performance (3D performance is horrible). And the new driver from testing doesn't even boot X.
Offline
Hmm... That's strange I'm using xf86-video-intel 2.6.1 and the last xorg-server 1.6 RC (1.5.9xx.xxx.xxx) and I have really nice 3D performance - for first time since I bought my notebook I was able to play Frozen Throne just fine, even some maps of UT 2k4. Has performance degraded in later xf86-video-intel?
My victim you are meant to be
No, you cannot hide nor flee
You know what I'm looking for
Pleasure your torture, I will endure...
Offline
@ triton: I also have an Intel 965GM graphics adapter in my notebook.
@ Dheart: Well... no, not afaik. But the thing is: I started gaming with Linux as soon as the xorg-server 1.5 came out, which indeed was the worst idea I've ever had. Then I made a wrong decision: to wait until the intel driver 2.6 and xorg-server 1.6 would come out, which took way too much time...
I had installed the Intel driver 2.6.0 and xorg-server 1.6 RC only one time, because it was unstable as hell... freezes over freezes... With my current setup (every newest package of testing and a custom built 2.6.29-rc8 kernel) I got zero problems at all and with outstanding performance when I compare it to the previous setups.
EDIT: Corrected typos. And I'm using the x86_64 version of Arch.
Last edited by Dr4go (2009-03-22 12:21:43)
Offline
As long as this kind of stuff keeps happening Linux can't dream of increasing it's market share, I'll even say that it doesn't deserve the market share it already has...
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
--------------------------------------------------------------------------------------------------------------
But if they tell you that I've lost my mind, maybe it's not gone just a little hard to find...
Offline
As long as this kind of stuff keeps happening Linux can't dream of increasing it's market share, I'll even say that it doesn't deserve the market share it already has...
Big words to say!
Although I totally disagree and I'd like to discuss this, let's focus on the topic
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
I'm actually trying the same thing here: dri2 + uxa + 2.6.29 w/ kms.
However, I'm not sure the kms bit is working properly. Under Fedora 11, e.g., when the mode is set, my laptop's display is set to something that looks like a native resolution, not the standard 80x25. With my own 2.6.29 under arch this doesn't happen. Would be great if we could get this working.
EDIT: Right. I wasn't aware of the fact that KMS needed some other stuff to work properly (I think vesa related stuff, not sure). I copied the relevant parts from the fedora 11 kernel config, and now everything KMS seems to work fine. Instant VT switching, pretty good performance from kwin composited effects, etc. I haven't tested it very long (as I'm not primarily using arch at the moment), but everything seems to work as expected except one thing: After a suspend/resume cycle, X leaves me at the kdm screen. Intel's KMS, dri2, and the whole new stack is really interesting and, above all, much needed, bits of technology. Looking forward to see how things will evolve from here.
Last edited by nightfrost (2009-03-22 20:38:08)
Offline
I copied the relevant parts from the fedora 11 kernel config, and now everything KMS seems to work fine.
Would you mind sharing your kernel config?
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
nightfrost wrote:I copied the relevant parts from the fedora 11 kernel config, and now everything KMS seems to work fine.
Would you mind sharing your kernel config?
+1 - please!
Offline
Hm. I had forgotten to subscribe to this thread :-p
I'm not exactly sure what the relevant part is. I would guess it's the framebuffer stuff, and that the vesa stuff could be deselected. Here's the full config for "Graphics support" and "Framebuffer hardware drivers" that I'm using:
#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=m
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_LTV350QV is not set
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_TDO24M is not set
# CONFIG_LCD_VGG2432A4 is not set
CONFIG_LCD_PLATFORM=m
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PROGEAR=m
# CONFIG_BACKLIGHT_MBP_NVIDIA is not set
# CONFIG_BACKLIGHT_SAHARA is not set
Offline
Thanks, with that config I can get this "working"...
So, I remove my Xorg config completely, boot with "i915.modeset=1" on the kernel line and things seem to go well. When boot gets to the udev line, the resolution in all my vt/x increases. Go, go, framebuffer. Then X actually works.
From my xorg log, I can see UXA is activated by default so KMS appears to work. glxgears still ~520 FPS, which is slower than with UXA and no KMS. The games I use to test (chromium-bsu and extreme-tux-racer) still run badly.
Offline