On Sun, 2010-03-21 at 03:06 -0700, Garrett Cooper wrote: > On Sun, Mar 21, 2010 at 2:42 AM, jhell <jh...@dataix.net> wrote: > > > > On Sun, 14 Mar 2010 23:57, Robert Noland wrote: > > In Message-Id: <1268625423.2608.348.ca...@balrog.2hip.net> > > > >> On Sun, 2010-03-14 at 15:02 -0600, Warren Block wrote: > >>> > >>> On Sat, 13 Mar 2010, Robert Noland wrote: > >>> > >>>> Ok, now that agp seems to be working... I have created a port for the > >>>> 2.9.1 version of the Intel driver. You will need to uninstall the > >>>> existing intel driver and install this one. You still won't have drm, > >>>> but should be a good bit better than vesa... > >>>> > >>>> http://people.freebsd.org/~rnoland/xf86-video-intel29.tar.gz > >>> > >>> Problem: after switching away from X with ctrl-alt-f4, on switching back > >>> the screen is corrupted. Stuff that's drawn on top of it after that > >>> point is usually correct. The clear areas on this image were caused by > >>> GIMP redrawing them; before opening it, they were the same as the strip > >>> on the right edge. > >> > >> Ok, I'm not surprised... I spent a little time playing with the 2.9.1 > >> driver on my g45 today. Basically... It is horrid... > >> > > > > Damn! I rely on this driver for my main machine that has a i845G in it. This > > thing tends to keep getting more shitty with every release. Or I suppose I > > could cough it up to ancient hardware to... ;) > > > > The last Intel driver I remember working seamlessly with my i845G with no > > known side effects and without HAL was 2.3*. After that it somehow became > > very dependent on HAL and if compiled without HAL would pretty much disable > > you(being me) from switching from X to the console and back again resulting > > in a reboot after a borked screen. > > > > Now that I see the following I sort of understand whats happening with this. > > And eventually this hardware will have to be replaced :( > > > >> When Intel chose to remove all non-GEM support for the 2.8 series > >> driver, what is actually going on is that it is calling into > >> libdrm_intel's fake buffer manager and doing ton's of memcpy's. It > >> seems to be sort of ok as long as it is just basic 2d, but enable > >> composite in metacity and it falls on it's face... Granted all of my > >> machines run with WITNESS and INVARIANTS, but you can almost count the > >> pixels as they are drawn... > >> > >> I was thinking that Intel had actually killed the fake buffer manager as > >> well, but it looks like it does still exist in libdrm git. Perhaps it > >> was that they removed it from mesa. At any rate, they don't deny that > >> it is broken, nor do they test it or have any intention of fixing it... > >> > >> The only reason for using the 2.9.1 driver that I can think of is if you > >> have an Ironlake chipset, which isn't supported in 2.7.1. I now have to > >> decide whether to spend time back porting Ironlake support to 2.7.1 or > >> spend time on GEM. > > Intel's killing off non-GEM support slowly and surely, so we have > to port GEM or die a slow and painful death on Intel accelerated > hardware: http://www.phoronix.com/scan.php?page=news_item&px=Njc2NA , > http://software.intel.com/sites/oss/project_spotlight.htm . Kind of > sad now that anholt is no longer really a contributing member to > FreeBSD.
Yes, the 2.8+ driver requires GEM for drm and the 2.10+ driver requires KMS. They keep removing code and making it that much more difficult to keep things going. The situation that I generally find myself in, is that in order to give radeon users newer/better code, I have to break Intel. Intel tends to take up an unreasonable amount of time for me to keep it functional. robert. > Thanks, > -Garrett -- Robert Noland <rnol...@freebsd.org> FreeBSD _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
