[Bug 4574] New: mach64: libGL error: XF86DRIQueryDirectRenderingCapable returned false
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4574 Summary: mach64: libGL error: XF86DRIQueryDirectRenderingCapable returned false Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: blocker Priority: P2 Component: libGL AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Since some time ago, direct rendering does not work anymore in my system. Startx otput: (EE) ATI(0): [drm] Failed to map DMA buffers list glxinfo: name of display: :0.0 libGL error: XF86DRIQueryDirectRenderingCapable returned false display: :0 screen: 0 direct rendering: No Xorg.0.log: (--) ATI(0): 8192 kB of SDRAM (1:1) detected (using 8191 kB). (WW) ATI(0): Cannot shadow an accelerated frame buffer. (...) (**) ATI(0): [agp] Using AGP 2x Mode (**) ATI(0): [agp] Using 64 MB AGP aperture (II) ATI(0): [agp] Mode 0x1f000203 [AGP 0x8086/0x7190; Card 0x1002/0x4c4d] (II) ATI(0): [agp] 65536 kB allocated with handle 0x0001 (II) ATI(0): [agp] Using 16 kB for DMA descriptor ring (**) ATI(0): [agp] Using 2 MB for DMA buffers (II) ATI(0): [agp] Using 62464 kB for AGP textures (II) ATI(0): [agp] ring handle = 0xf400 (II) ATI(0): [agp] Ring mapped at 0x40d47000 (II) ATI(0): [agp] vertex buffers handle = 0xf4004000 (II) ATI(0): [agp] Vertex buffers mapped at 0x40d4b000 (II) ATI(0): [agp] AGP texture region handle = 0xf4204000 (II) ATI(0): [agp] AGP Texture region mapped at 0x454fa000 (II) ATI(0): [drm] register handle = 0xfcfff000 (II) ATI(0): [dri] Visual configs initialized (II) ATI(0): [dri] Block 0 base at 0xfcfff400 (II) ATI(0): Memory manager initialized to (0,0) (1024,4095) (II) ATI(0): Largest offscreen area available: 1024 x 3327 (II) ATI(0): Will use 3583 kB of offscreen memory for XAA (II) ATI(0): Will use back buffer at offset 0x4ff800 (II) ATI(0): Will use depth buffer at offset 0x67f800 (II) ATI(0): Using XFree86 Acceleration Architecture (XAA) (...) (II) ATI(0): [drm] installed DRM signal handler (II) ATI(0): [DRI] installation complete (II) ATI(0): [drm] Added 128 16384 byte DMA buffers (EE) ATI(0): [drm] Failed to map DMA buffers list (II) ATI(0): [drm] removed 1 reserved context for kernel (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd4be8000 at 0x40d45000 (II) ATI(0): Direct rendering disabled ldd /usr/X11R6/bin/glxinfo: linux-gate.so.1 => (0xe000) libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x4001b000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x42a4) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x42973000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4d021000) libm.so.6 => /lib/tls/libm.so.6 (0x4cdff000) libc.so.6 => /lib/tls/libc.so.6 (0x4ccde000) libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0x4009) libdl.so.2 => /lib/libdl.so.2 (0x4ce24000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4ccc7000) dmesg: PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 agpgart: AGP aperture is 64M @ 0xf400 agpgart: Found an AGP 1.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 2x mode agpgart: Putting AGP V2 device at :01:00.0 into 2x mode [drm] Initialized drm 1.0.0 20040925 [drm] Initialized mach64 1.0.0 20020904 on minor 0: [drm] Used old pci detect: framebuffer loaded [drm] descriptor ring: cpu addr d4c24000, bus addr: 0xf400 [drm] DMA test succeeded, using asynchronous DMA mode The report written above are the outputs got when setting "agp_size" "64". With this setting I got direct rendering before. Then, I tried to set "agp_size" "128" and the outputs were quite different: Startx otput: (EE) ATI(0): [agp] Could not bind glxinfo: name of display: :0.0 libGL: XF86DRIGetClientDriverName: 6.5.6 mach64 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/mach64_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 display: :0 screen: 0 direct rendering: Yes Xorg.0.log: (--) ATI(0): 8192 kB of SDRAM (1:1) detected (using 8191 kB). (WW) ATI(0): Cannot shadow an accelerated frame buffer. (...) (**) ATI(0): [agp] Using AGP 2x Mode (**) ATI(0): [agp] Using 128 MB AGP aperture (II) ATI(0): [agp] Mode 0x1f000203 [AGP 0x8086/0x7190; Card 0x1002/0x4c4d] (II) ATI(0): [agp] 131072 kB allocated with handle 0x0001 (
[Bug 982] Resolution switching broken on ATI IGP3xx
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=982 [EMAIL PROTECTED] changed: What|Removed |Added Severity|critical|major -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 982] Resolution switching broken on ATI IGP3xx
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=982 --- Additional Comments From [EMAIL PROTECTED] 2005-09-23 09:25 --- (In reply to comment #0) > I'm currently running XOrg-6.7.0 with DRI-CVS under a 2.6.6 linux kernel. > If I try to run another application fullscreen I need to use the same > resolution as my startup X one (1024x768). If I use any other resolution the > screen goes blank. > > This does not appear to affect the stability of the system as I can still > quit > out of the running application. I only have a IGP340M - but have seen the > same > problem reported on other ATI IGP3xx chips. > > I have previously mentioned this on DRI-Devel. Id love to try and fix it, but > wouldn't know the first place to start looking > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg17392.html > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg17706.html Please post your xorg.conf and log. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
In the savage DRM driver I added some code that uses knowledge about adjacent address ranges and BAR sizes (as opposed to the actual VRAM size) to allocate the minimum number of MTRRs. This was the only way to cover the frame buffer and additional frame buffer apertures without wasting too many MTRRs. It still relies on the automatic MTRR setup on some hardware where it does the right thing. See savage_bci.c function savage_driver_firstopen for details. Regards, Felix Am Freitag, den 23.09.2005, 12:42 +0100 schrieb Alan Hourihane: > On Fri, 2005-09-23 at 12:30 +0100, Alan Hourihane wrote: > > Has anyone any objections to me removing the MTRR code from the DRM. > > > > It doesn't have the intimate knowledge needed to properly configure > > MTRR's and fails in many cases. > > > > There are two cases currently, one for the framebuffer and a second for > > the entire AGP space. > > > > Certainly in Intel hardware this is the same memory space and you always > > get bogus error messages in your kernel logs as things fail due to lack > > of boundary checks. > > > > I'm more of the opinion that it should be left up to userspace to > > configure MTRR's if it indeed wants them and we shouldn't force them > > within the DRM. > > > > Additionally, the Xserver (for user-space) already sets up the MTRR's, > > as should Xgl (Xegl) or other user space apps. > > > > What makes the situation a little worse is that vesafb (and other *fb > > drivers) also setup an mtrr which frequently stops subsequent processes > > from adding a new one that overlaps an existing write-combining range. > > But the *fb drivers do provide a nomtrr option in many cases. (But I'd > > like to remove it from them too :-) or at least default those to off) > > > > Comments ?? > > One thing to add, is that I did initially look at just removing > DRIVER_USE_MTRR from the intel DRM, but it really doesn't satisfy other > use cases for the other chipsets. Again, inline with the fact there may > already be existing mtrr's setup and the DRM fails to honour proper > checking. > > But I'm interested in others comments on this. > > Alan. > > > --- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > > -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
Alan Hourihane wrote: > Has anyone any objections to me removing the MTRR code from the DRM. > > It doesn't have the intimate knowledge needed to properly configure > MTRR's and fails in many cases. > > There are two cases currently, one for the framebuffer and a second for > the entire AGP space. > > Certainly in Intel hardware this is the same memory space and you always > get bogus error messages in your kernel logs as things fail due to lack > of boundary checks. > > I'm more of the opinion that it should be left up to userspace to > configure MTRR's if it indeed wants them and we shouldn't force them > within the DRM. > > Additionally, the Xserver (for user-space) already sets up the MTRR's, > as should Xgl (Xegl) or other user space apps. > > What makes the situation a little worse is that vesafb (and other *fb > drivers) also setup an mtrr which frequently stops subsequent processes > from adding a new one that overlaps an existing write-combining range. > But the *fb drivers do provide a nomtrr option in many cases. (But I'd > like to remove it from them too :-) or at least default those to off) I don't know the repercussions of defaulting to nomtrr. But I would surmise that a large percentage of users gives more importance to X/DRI performance than console performance (majority of vesafb users still use redraw for scrolling where ypan is magnitudes faster, so I'm pretty sure defaulting vesafb to nomtrr will not be noticeable to most users, they probably go straight to X anyway :-) I cannot decide on this alone, so I'm going to CC the fbdev-devel list. Perhaps I can submit a patch that defaults all drivers to nomtrr and a big warning about mtrr not being set in dmesg. If I don't get any backlash for a few patch cycles, I can make this permanent. Tony --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
> > > But the *fb drivers do provide a nomtrr option in many cases. (But I'd > > like to remove it from them too :-) or at least default those to off) > > Sounds sane. Nvidia posted some patches a while ago that seem to be > getting kicked around a bit again to add support for PAT (per page > attributes) on PII Xeon and higher which will help no end These patches really need someone with some VM experience, the aliasing issues with having cacheable and non-cacheable mappings for one physical memory area was beyond my experience and time constraints at this stage.. Dave. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
On Fri, 2005-09-23 at 13:28 +0100, Dave Airlie wrote: > > > I don't think we can really just nuke support for them, maybe we should > > > fix the support if we can... the problem I have is removing them will > > > signiciantly slow down a lot of working systems.. if the X server doesn't > > > do the correct thing.. > > > > Problem here Dave is that there are probably a lot of systems that use > > the *fb drivers are already slower. In an *fb model in that the user > > hasn't explicitly turned off the mtrr then there's only a small range > > that will actually get configured for video memory. The DRM will already > > fail to add the correct range as the kernel will refuse to overwrite an > > existing range. You may find things speed up in many cases if we remove > > it from the DRM. > > > Looking at X it sets up the framebuffer mtrr for most cards, but nothing > for AGP, mtrr for AGP is as far as I know a big win as we can't cache the > aperture so write combining is needed... maybe we can stop the DRM from > allocating MTRRs for framebuffers in the DRM but leave the code in for the > AGP space... then the i915 can just turn it off in the drm and let X do > it... Right, that's what I mention in my previous email. But remember that AGP space in Intel hardware is where the framebuffer comes from so X is already doing this for us. So there's no point in the i915 drm doing it for AGP & framebuffer memory as it's the same thing. I'll just remove DRIVER_USE_MTRR from the i915 setup for now. > We can add an option for DRM to turn on mtrr for framebuffer.. or maybe we > can check for an pre-existing and if there is one we can just do nothing, > or add one if not .. or a drm driver option to enable/disable it.. My other point here is that some hardware requires MTRR's to be aligned and the DRM doesn't know how to do that it just ships off the current region to mtrr and doesn't look back. So it needs more intimate knowledge if it's going to continue to do it - regardless of driver. Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
> > > > Not sure what to do there.. have to ask the fb devel guys.. > > Ben ? I'm not sure if Antonio Daplas is on this list.. they are all on [EMAIL PROTECTED] Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
> > I don't think we can really just nuke support for them, maybe we should > > fix the support if we can... the problem I have is removing them will > > signiciantly slow down a lot of working systems.. if the X server doesn't > > do the correct thing.. > > Problem here Dave is that there are probably a lot of systems that use > the *fb drivers are already slower. In an *fb model in that the user > hasn't explicitly turned off the mtrr then there's only a small range > that will actually get configured for video memory. The DRM will already > fail to add the correct range as the kernel will refuse to overwrite an > existing range. You may find things speed up in many cases if we remove > it from the DRM. Looking at X it sets up the framebuffer mtrr for most cards, but nothing for AGP, mtrr for AGP is as far as I know a big win as we can't cache the aperture so write combining is needed... maybe we can stop the DRM from allocating MTRRs for framebuffers in the DRM but leave the code in for the AGP space... then the i915 can just turn it off in the drm and let X do it... We can add an option for DRM to turn on mtrr for framebuffer.. or maybe we can check for an pre-existing and if there is one we can just do nothing, or add one if not .. or a drm driver option to enable/disable it.. > > Well EGL would need to set it up, not the X server itself, or I suppose in > > the case I'd like to get designed is to have the mode-setting/DRM initing > > process to do it.. > > My point here, being user space needs to set these up, not the kernel. sorry was jjust me thinking out loud :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
On Fri, 2005-09-23 at 12:46 +0100, Dave Airlie wrote: > acceptable.. some way to perhaps have the X server tell the DRM driver to > not bother with them... In the interests of backwards compatibility I suppose this may be a reasonable option though. Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
On Fri, 2005-09-23 at 12:46 +0100, Dave Airlie wrote: > > It doesn't have the intimate knowledge needed to properly configure > > MTRR's and fails in many cases. > > I don't think we can really just nuke support for them, maybe we should > fix the support if we can... the problem I have is removing them will > signiciantly slow down a lot of working systems.. if the X server doesn't > do the correct thing.. Problem here Dave is that there are probably a lot of systems that use the *fb drivers are already slower. In an *fb model in that the user hasn't explicitly turned off the mtrr then there's only a small range that will actually get configured for video memory. The DRM will already fail to add the correct range as the kernel will refuse to overwrite an existing range. You may find things speed up in many cases if we remove it from the DRM. AGP space is a different matter for those non-integrated systems where the DRM setting the MTRR will probably be just fine at the moment. > You can remove the DRIVER_USE_MTRR from the i915 driver, but I'd be > worried about any regressions, regressing the kernel is very rarely > acceptable.. some way to perhaps have the X server tell the DRM driver to > not bother with them... The Xserver does set the range correctly on Intel hardware. I'm not sure about the others, so removing DRIVER_USE_MTRR on i915 hardware is reasonable for now. But anything outside of the Xserver would need to explicitly turn them on. > For Radeon IGP chipsets I would expect us to have similiar issues but I'm > not sure how they do the mapping.. Right. > > There are two cases currently, one for the framebuffer and a second for > > the entire AGP space. > > > > Certainly in Intel hardware this is the same memory space and you always > > get bogus error messages in your kernel logs as things fail due to lack > > of boundary checks. > > > > I'm more of the opinion that it should be left up to userspace to > > configure MTRR's if it indeed wants them and we shouldn't force them > > within the DRM. > > > > Additionally, the Xserver (for user-space) already sets up the MTRR's, > > as should Xgl (Xegl) or other user space apps. > > Well EGL would need to set it up, not the X server itself, or I suppose in > the case I'd like to get designed is to have the mode-setting/DRM initing > process to do it.. My point here, being user space needs to set these up, not the kernel. > > What makes the situation a little worse is that vesafb (and other *fb > > drivers) also setup an mtrr which frequently stops subsequent processes > > from adding a new one that overlaps an existing write-combining range. > > But the *fb drivers do provide a nomtrr option in many cases. (But I'd > > like to remove it from them too :-) or at least default those to off > > Not sure what to do there.. have to ask the fb devel guys.. Ben ? Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
> It doesn't have the intimate knowledge needed to properly configure > MTRR's and fails in many cases. I don't think we can really just nuke support for them, maybe we should fix the support if we can... the problem I have is removing them will signiciantly slow down a lot of working systems.. if the X server doesn't do the correct thing.. You can remove the DRIVER_USE_MTRR from the i915 driver, but I'd be worried about any regressions, regressing the kernel is very rarely acceptable.. some way to perhaps have the X server tell the DRM driver to not bother with them... For Radeon IGP chipsets I would expect us to have similiar issues but I'm not sure how they do the mapping.. > There are two cases currently, one for the framebuffer and a second for > the entire AGP space. > > Certainly in Intel hardware this is the same memory space and you always > get bogus error messages in your kernel logs as things fail due to lack > of boundary checks. > > I'm more of the opinion that it should be left up to userspace to > configure MTRR's if it indeed wants them and we shouldn't force them > within the DRM. > > Additionally, the Xserver (for user-space) already sets up the MTRR's, > as should Xgl (Xegl) or other user space apps. Well EGL would need to set it up, not the X server itself, or I suppose in the case I'd like to get designed is to have the mode-setting/DRM initing process to do it.. > What makes the situation a little worse is that vesafb (and other *fb > drivers) also setup an mtrr which frequently stops subsequent processes > from adding a new one that overlaps an existing write-combining range. > But the *fb drivers do provide a nomtrr option in many cases. (But I'd > like to remove it from them too :-) or at least default those to off Not sure what to do there.. have to ask the fb devel guys.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
On Gwe, 2005-09-23 at 12:30 +0100, Alan Hourihane wrote: > drivers) also setup an mtrr which frequently stops subsequent processes > from adding a new one that overlaps an existing write-combining range. It expects the other users to have the brains to add non-overlapping ones 8) > But the *fb drivers do provide a nomtrr option in many cases. (But I'd > like to remove it from them too :-) or at least default those to off) Sounds sane. Nvidia posted some patches a while ago that seem to be getting kicked around a bit again to add support for PAT (per page attributes) on PII Xeon and higher which will help no end --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & MTRR's
On Fri, 2005-09-23 at 12:30 +0100, Alan Hourihane wrote: > Has anyone any objections to me removing the MTRR code from the DRM. > > It doesn't have the intimate knowledge needed to properly configure > MTRR's and fails in many cases. > > There are two cases currently, one for the framebuffer and a second for > the entire AGP space. > > Certainly in Intel hardware this is the same memory space and you always > get bogus error messages in your kernel logs as things fail due to lack > of boundary checks. > > I'm more of the opinion that it should be left up to userspace to > configure MTRR's if it indeed wants them and we shouldn't force them > within the DRM. > > Additionally, the Xserver (for user-space) already sets up the MTRR's, > as should Xgl (Xegl) or other user space apps. > > What makes the situation a little worse is that vesafb (and other *fb > drivers) also setup an mtrr which frequently stops subsequent processes > from adding a new one that overlaps an existing write-combining range. > But the *fb drivers do provide a nomtrr option in many cases. (But I'd > like to remove it from them too :-) or at least default those to off) > > Comments ?? One thing to add, is that I did initially look at just removing DRIVER_USE_MTRR from the intel DRM, but it really doesn't satisfy other use cases for the other chipsets. Again, inline with the fact there may already be existing mtrr's setup and the DRM fails to honour proper checking. But I'm interested in others comments on this. Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM & MTRR's
Has anyone any objections to me removing the MTRR code from the DRM. It doesn't have the intimate knowledge needed to properly configure MTRR's and fails in many cases. There are two cases currently, one for the framebuffer and a second for the entire AGP space. Certainly in Intel hardware this is the same memory space and you always get bogus error messages in your kernel logs as things fail due to lack of boundary checks. I'm more of the opinion that it should be left up to userspace to configure MTRR's if it indeed wants them and we shouldn't force them within the DRM. Additionally, the Xserver (for user-space) already sets up the MTRR's, as should Xgl (Xegl) or other user space apps. What makes the situation a little worse is that vesafb (and other *fb drivers) also setup an mtrr which frequently stops subsequent processes from adding a new one that overlaps an existing write-combining range. But the *fb drivers do provide a nomtrr option in many cases. (But I'd like to remove it from them too :-) or at least default those to off) Comments ?? Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
