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
