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
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
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
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..
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
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.
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
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
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)
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.
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
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
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
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
14 matches
Mail list logo
